Linux 6.7.7

 
accel/ivpu/40xx: Stop passing SKU boot parameters to FW [+ + +]
Author: Krystian Pradzynski <krystian.pradzynski@intel.com>
Date:   Fri Jan 26 13:28:03 2024 +0100

    accel/ivpu/40xx: Stop passing SKU boot parameters to FW
    
    [ Upstream commit 553099da45397914a995dce6307d6c26523c2567 ]
    
    This parameter was never used by the 40xx FW.
    
    Signed-off-by: Krystian Pradzynski <krystian.pradzynski@intel.com>
    Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240126122804.2169129-7-jacek.lawrynowicz@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
accel/ivpu: Disable d3hot_delay on all NPU generations [+ + +]
Author: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Date:   Fri Jan 26 13:28:00 2024 +0100

    accel/ivpu: Disable d3hot_delay on all NPU generations
    
    [ Upstream commit a7f31091ddf457352e3dd7ac183fdbd26b4dcd04 ]
    
    NPU does not require this delay regardless of the generation.
    All generations are integrated into the SOC.
    
    Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240126122804.2169129-4-jacek.lawrynowicz@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

accel/ivpu: Don't enable any tiles by default on VPU40xx [+ + +]
Author: Andrzej Kacprowski <Andrzej.Kacprowski@intel.com>
Date:   Tue Feb 20 14:16:24 2024 +0100

    accel/ivpu: Don't enable any tiles by default on VPU40xx
    
    commit eb0d253ff9c74dee30aa92fe460b825eb28acd73 upstream.
    
    There is no point in requesting 1 tile on VPU40xx as the FW will
    probably need more tiles to run workloads, so it will have to
    reconfigure PLL anyway. Don't enable any tiles and allow the FW to
    perform initial tile configuration.
    
    This improves NPU boot stability as the tiles are always enabled only
    by the FW from the same initial state.
    
    Fixes: 79cdc56c4a54 ("accel/ivpu: Add initial support for VPU 4")
    Cc: stable@vger.kernel.org
    Signed-off-by: Andrzej Kacprowski <Andrzej.Kacprowski@intel.com>
    Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240220131624.1447813-1-jacek.lawrynowicz@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

accel/ivpu: Force snooping for MMU writes [+ + +]
Author: Wachowski, Karol <karol.wachowski@intel.com>
Date:   Fri Jan 26 13:27:58 2024 +0100

    accel/ivpu: Force snooping for MMU writes
    
    [ Upstream commit c9da9a1f17bf4fa96b115950fd389c917b583c1c ]
    
    Set AW_SNOOP_OVERRIDE bit in VPU_37/40XX_HOST_IF_TCU_PTW_OVERRIDES
    to force snooping for MMU write accesses (setting event queue events).
    
    MMU event queue buffer is the only buffer written by MMU and
    mapped as write-back which break cache coherency. Force write
    transactions to be snooped solving the problem.
    
    Signed-off-by: Wachowski, Karol <karol.wachowski@intel.com>
    Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240126122804.2169129-2-jacek.lawrynowicz@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

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

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

ahci: Extend ASM1061 43-bit DMA address quirk to other ASM106x parts [+ + +]
Author: Lennert Buytenhek <kernel@wantstofly.org>
Date:   Tue Jan 30 15:21:51 2024 +0200

    ahci: Extend ASM1061 43-bit DMA address quirk to other ASM106x parts
    
    commit 51af8f255bdaca6d501afc0d085b808f67b44d91 upstream.
    
    ASMedia have confirmed that all ASM106x parts currently listed in
    ahci_pci_tbl[] suffer from the 43-bit DMA address limitation that we ran
    into on the ASM1061, and therefore, we need to apply the quirk added by
    commit 20730e9b2778 ("ahci: add 43-bit DMA address quirk for ASMedia
    ASM1061 controllers") to the other supported ASM106x parts as well.
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/linux-ide/ZbopwKZJAKQRA4Xv@x1-carbon/
    Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
    [cassel: add link to ASMedia confirmation email]
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ALSA: hda: cs35l41: Support additional ASUS Zenbook UX3402VA [+ + +]
Author: Kenzo Gomez <kenzo.sgomez@gmail.com>
Date:   Sat Jan 27 17:46:21 2024 +0100

    ALSA: hda: cs35l41: Support additional ASUS Zenbook UX3402VA
    
    [ Upstream commit c16dfab33f99fc3ff43d48253bc2784ccb84c1de ]
    
    Add new model entry into configuration table.
    
    Signed-off-by: Kenzo Gomez <kenzo.sgomez@gmail.com>
    Link: https://lore.kernel.org/r/20240127164621.26431-1-kenzo.sgomez@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda: cs35l41: Support ASUS Zenbook UM3402YAR [+ + +]
Author: Chhayly Leang <clw.leang@gmail.com>
Date:   Fri Jan 26 15:09:12 2024 +0700

    ALSA: hda: cs35l41: Support ASUS Zenbook UM3402YAR
    
    [ Upstream commit be220d2e5544ff094142d263db5cf94d034b5e39 ]
    
    Adds sound support for ASUS Zenbook UM3402YAR with missing DSD
    
    Signed-off-by: Chhayly Leang <clw.leang@gmail.com>
    Link: https://lore.kernel.org/r/20240126080912.87422-1-clw.leang@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda: Increase default bdl_pos_adj for Apollo Lake [+ + +]
Author: Rui Salvaterra <rsalvaterra@gmail.com>
Date:   Mon Jan 22 11:45:13 2024 +0000

    ALSA: hda: Increase default bdl_pos_adj for Apollo Lake
    
    [ Upstream commit 56beedc88405fd8022edfd1c2e63d1bc6c95efcb ]
    
    Apollo Lake seems to also suffer from IRQ timing issues. After being up for ~4
    minutes, a Pentium N4200 system ends up falling back to workqueue-based IRQ
    handling:
    
    [  208.019906] snd_hda_intel 0000:00:0e.0: IRQ timing workaround is activated
    for card #0. Suggest a bigger bdl_pos_adj.
    
    Unfortunately, the Baytrail and Braswell workaround value of 32 samples isn't
    enough to fix the issue here. Default to 64 samples.
    
    Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
    Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Link: https://lore.kernel.org/r/20240122114512.55808-3-rsalvaterra@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda: Replace numeric device IDs with constant values [+ + +]
Author: Rui Salvaterra <rsalvaterra@gmail.com>
Date:   Mon Jan 22 11:45:12 2024 +0000

    ALSA: hda: Replace numeric device IDs with constant values
    
    [ Upstream commit 3526860f26febbe46960f9b37f5dbd5ccc109ea8 ]
    
    We have self-explanatory constants for Intel HDA devices, let's use them instead
    of magic numbers and code comments.
    
    Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
    Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Link: https://lore.kernel.org/r/20240122114512.55808-2-rsalvaterra@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

 
aoe: avoid potential deadlock at set_capacity [+ + +]
Author: Maksim Kiselev <bigunclemax@gmail.com>
Date:   Wed Jan 24 10:24:36 2024 +0300

    aoe: avoid potential deadlock at set_capacity
    
    [ Upstream commit e169bd4fb2b36c4b2bee63c35c740c85daeb2e86 ]
    
    Move set_capacity() outside of the section procected by (&d->lock).
    To avoid possible interrupt unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
    [1] lock(&bdev->bd_size_lock);
                                    local_irq_disable();
                                [2] lock(&d->lock);
                                [3] lock(&bdev->bd_size_lock);
       <Interrupt>
    [4]  lock(&d->lock);
    
      *** DEADLOCK ***
    
    Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity().
    [2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc()
    is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call.
    In this situation an attempt to acquire [4]lock(&d->lock) from
    aoecmd_cfg_rsp() will lead to deadlock.
    
    So the simplest solution is breaking lock dependency
    [2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity()
    outside.
    
    Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20240124072436.3745720-2-bigunclemax@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64/sme: Restore SMCR_EL1.EZT0 on exit from suspend [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Tue Feb 13 23:06:33 2024 +0000

    arm64/sme: Restore SMCR_EL1.EZT0 on exit from suspend
    
    [ Upstream commit d7b77a0d565b048cb0808fa8a4fb031352b22a01 ]
    
    The fields in SMCR_EL1 reset to an architecturally UNKNOWN value. Since we
    do not otherwise manage the traps configured in this register at runtime we
    need to reconfigure them after a suspend in case nothing else was kind
    enough to preserve them for us. Do so for SMCR_EL1.EZT0.
    
    Fixes: d4913eee152d ("arm64/sme: Add basic enumeration for SME2")
    Reported-by: Jackson Cooper-Driver <Jackson.Cooper-Driver@arm.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20240213-arm64-sme-resume-v3-2-17e05e493471@kernel.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64/sme: Restore SME registers on exit from suspend [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Tue Feb 13 23:06:32 2024 +0000

    arm64/sme: Restore SME registers on exit from suspend
    
    [ Upstream commit 9533864816fb4a6207c63b7a98396351ce1a9fae ]
    
    The fields in SMCR_EL1 and SMPRI_EL1 reset to an architecturally UNKNOWN
    value. Since we do not otherwise manage the traps configured in this
    register at runtime we need to reconfigure them after a suspend in case
    nothing else was kind enough to preserve them for us.
    
    The vector length will be restored as part of restoring the SME state for
    the next SME using task.
    
    Fixes: a1f4ccd25cc2 ("arm64/sme: Provide Kconfig for SME")
    Reported-by: Jackson Cooper-Driver <Jackson.Cooper-Driver@arm.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20240213-arm64-sme-resume-v3-1-17e05e493471@kernel.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: imx8mp: Disable UART4 by default on Data Modul i.MX8M Plus eDM SBC [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Wed Dec 20 01:02:42 2023 +0100

    arm64: dts: imx8mp: Disable UART4 by default on Data Modul i.MX8M Plus eDM SBC
    
    [ Upstream commit f03869698bc3bd6d9d2d9f216b20da08a8c2508a ]
    
    UART4 is used as CM7 coprocessor debug UART and may not be accessible from
    Linux in case it is protected by RDC. The RDC protection is set up by the
    platform firmware. UART4 is not used on this platform by Linux. Disable
    UART4 by default to prevent boot hangs, which occur when the RDC protection
    is in place.
    
    Fixes: 562d222f23f0 ("arm64: dts: imx8mp: Add support for Data Modul i.MX8M Plus eDM SBC")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: Correct Indiedroid Nova GPIO Names [+ + +]
Author: Chris Morgan <macromorgan@hotmail.com>
Date:   Thu Jan 25 14:19:42 2024 -0600

    arm64: dts: rockchip: Correct Indiedroid Nova GPIO Names
    
    [ Upstream commit c22d03a95b0d815cd186302fdd93f74d99f1c914 ]
    
    Correct the names given to a few of the GPIO pins. The original names
    were unknowingly based on the header from a pre-production board. The
    production board has a slightly different pin assignment for the 40-pin
    GPIO header.
    
    Fixes: 3900160e164b ("arm64: dts: rockchip: Add Indiedroid Nova board")
    Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
    Link: https://lore.kernel.org/r/20240125201943.90476-2-macroalpha82@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

arm64: dts: tqma8mpql: fix audio codec iov-supply [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Wed Jan 10 10:08:49 2024 +0100

    arm64: dts: tqma8mpql: fix audio codec iov-supply
    
    [ Upstream commit a620a7f2ae8b08c5beea6369f61e87064ee222dc ]
    
    IOVDD is supplied by 1.8V, fix the referenced regulator.
    
    Fixes: d8f9d8126582d ("arm64: dts: imx8mp: Add analog audio output on i.MX8MP TQMa8MPxL/MBa8MPxL")
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: dts: Fix TPM schema violations [+ + +]
Author: Lukas Wunner <lukas@wunner.de>
Date:   Sat Jan 13 10:03:51 2024 +0100

    ARM: dts: Fix TPM schema violations
    
    [ Upstream commit 8412c47d68436b9f9a260039a4a773daa6824925 ]
    
    Since commit 26c9d152ebf3 ("dt-bindings: tpm: Consolidate TCG TIS
    bindings"), several issues are reported by "make dtbs_check" for ARM
    devicetrees:
    
    The nodename needs to be "tpm@0" rather than "tpmdev@0" and the
    compatible property needs to contain the chip's name in addition to the
    generic "tcg,tpm_tis-spi" or "tcg,tpm-tis-i2c":
    
      tpmdev@0: $nodename:0: 'tpmdev@0' does not match '^tpm(@[0-9a-f]+)?$'
            from schema $id: http://devicetree.org/schemas/tpm/tcg,tpm_tis-spi.yaml#
    
      tpm@2e: compatible: 'oneOf' conditional failed, one must be fixed:
            ['tcg,tpm-tis-i2c'] is too short
            from schema $id: http://devicetree.org/schemas/tpm/tcg,tpm-tis-i2c.yaml#
    
    Fix these schema violations.
    
    Aspeed Facebook BMCs use an Infineon SLB9670:
    https://lore.kernel.org/all/ZZSmMJ%2F%2Fl972Qbxu@fedora/
    https://lore.kernel.org/all/ZZT4%2Fw2eVzMhtsPx@fedora/
    https://lore.kernel.org/all/ZZTS0p1hdAchIbKp@heinlein.vulture-banana.ts.net/
    
    Aspeed Tacoma uses a Nuvoton NPCT75X per commit 39d8a73c53a2 ("ARM: dts:
    aspeed: tacoma: Add TPM").
    
    phyGATE-Tauri uses an Infineon SLB9670:
    https://lore.kernel.org/all/ab45c82485fa272f74adf560cbb58ee60cc42689.camel@phytec.de/
    
    A single schema violation remains in am335x-moxa-uc-2100-common.dtsi
    because it is unknown which chip is used on the board.  The devicetree's
    author has been asked for clarification but has not responded so far:
    https://lore.kernel.org/all/20231220090910.GA32182@wunner.de/
    
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Reviewed-by: Patrick Williams <patrick@stwcx.xyz>
    Reviewed-by: Tao Ren <rentao.bupt@gmail.com>
    Reviewed-by: Bruno Thomsen <bruno.thomsen@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

    arp: Prevent overflow in arp_req_get().
    
    [ Upstream commit a7d6027790acea24446ddd6632d394096c0f4667 ]
    
    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: Sasha Levin <sashal@kernel.org>

 
ASoC: amd: acp: Add check for cpu dai link initialization [+ + +]
Author: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Date:   Thu Jan 18 20:00:21 2024 +0530

    ASoC: amd: acp: Add check for cpu dai link initialization
    
    [ Upstream commit 6cc2aa9a75f2397d42b78d4c159bc06722183c78 ]
    
    Add condition check for cpu dai link initialization for amplifier
    codec path, as same pcm id uses for both headset and speaker path
    for RENOIR platforms.
    
    Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
    Link: https://msgid.link/r/20240118143023.1903984-3-venkataprasad.potturu@amd.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>

ASoC: wm_adsp: Don't overwrite fwf_name with the default [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Mon Jan 29 16:27:21 2024 +0000

    ASoC: wm_adsp: Don't overwrite fwf_name with the default
    
    [ Upstream commit daf3f0f99cde93a066240462b7a87cdfeedc04c0 ]
    
    There's no need to overwrite fwf_name with a kstrdup() of the cs_dsp part
    name. It is trivial to select either fwf_name or cs_dsp.part as the string
    to use when building the filename in wm_adsp_request_firmware_file().
    
    This leaves fwf_name entirely owned by the codec driver.
    
    It also avoids problems with freeing the pointer. With the original code
    fwf_name was either a pointer owned by the codec driver, or a kstrdup()
    created by wm_adsp. This meant wm_adsp must free it if it set it, but not
    if the codec driver set it. The code was handling this by using
    devm_kstrdup().
    But there is no absolute requirement that wm_adsp_common_init() must be
    called from probe(), so this was a pseudo-memory leak - each new call to
    wm_adsp_common_init() would allocate another block of memory but these
    would only be freed if the owning codec driver was removed.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://msgid.link/r/20240129162737.497-3-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

ata: libata-core: Do not call ata_dev_power_set_standby() twice [+ + +]
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Mon Feb 19 16:44:30 2024 +0100

    ata: libata-core: Do not call ata_dev_power_set_standby() twice
    
    commit 9cec467d0502b24660f413a0e8fc782903b46d5b upstream.
    
    For regular system shutdown, ata_dev_power_set_standby() will be
    executed twice: once the scsi device is removed and another when
    ata_pci_shutdown_one() executes and EH completes unloading the devices.
    
    Make the second call to ata_dev_power_set_standby() do nothing by using
    ata_dev_power_is_active() and return if the device is already in
    standby.
    
    Fixes: 2da4c5e24e86 ("ata: libata-core: Improve ata_dev_power_set_active()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ata: libata-core: Do not try to set sleeping devices to standby [+ + +]
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Thu Jan 11 20:51:22 2024 +0900

    ata: libata-core: Do not try to set sleeping devices to standby
    
    commit 4b085736e44dbbe69b5eea1a8a294f404678a1f4 upstream.
    
    In ata ata_dev_power_set_standby(), check that the target device is not
    sleeping. If it is, there is no need to do anything.
    
    Fixes: aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
block: Fix WARNING in _copy_from_iter [+ + +]
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Sun Jan 21 21:26:34 2024 +0100

    block: Fix WARNING in _copy_from_iter
    
    [ Upstream commit 13f3956eb5681a4045a8dfdef48df5dc4d9f58a6 ]
    
    Syzkaller reports a warning in _copy_from_iter because an
    iov_iter is supposedly used in the wrong direction. The reason
    is that syzcaller managed to generate a request with
    a transfer direction of SG_DXFER_TO_FROM_DEV. This instructs
    the kernel to copy user buffers into the kernel, read into
    the copied buffers and then copy the data back to user space.
    
    Thus the iovec is used in both directions.
    
    Detect this situation in the block layer and construct a new
    iterator with the correct direction for the copy-in.
    
    Reported-by: syzbot+a532b03fdfee2c137666@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/lkml/0000000000009b92c10604d7a5e9@google.com/t/
    Reported-by: syzbot+63dec323ac56c28e644f@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/lkml/0000000000003faaa105f6e7c658@google.com/T/
    Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20240121202634.275068-1-lk@c--e.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready() [+ + +]
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Mon Feb 19 00:09:33 2024 +0900

    bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()
    
    [ Upstream commit 4cd12c6065dfcdeba10f49949bffcf383b3952d8 ]
    
    syzbot reported the following NULL pointer dereference issue [1]:
    
      BUG: kernel NULL pointer dereference, address: 0000000000000000
      [...]
      RIP: 0010:0x0
      [...]
      Call Trace:
       <TASK>
       sk_psock_verdict_data_ready+0x232/0x340 net/core/skmsg.c:1230
       unix_stream_sendmsg+0x9b4/0x1230 net/unix/af_unix.c:2293
       sock_sendmsg_nosec net/socket.c:730 [inline]
       __sock_sendmsg+0x221/0x270 net/socket.c:745
       ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
       ___sys_sendmsg net/socket.c:2638 [inline]
       __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
       do_syscall_64+0xf9/0x240
       entry_SYSCALL_64_after_hwframe+0x6f/0x77
    
    If sk_psock_verdict_data_ready() and sk_psock_stop_verdict() are called
    concurrently, psock->saved_data_ready can be NULL, causing the above issue.
    
    This patch fixes this issue by calling the appropriate data ready function
    using the sk_psock_data_ready() helper and protecting it from concurrency
    with sk->sk_callback_lock.
    
    Fixes: 6df7f764cd3c ("bpf, sockmap: Wake up polling after data copy")
    Reported-by: syzbot+fd7b34375c1c8ce29c93@syzkaller.appspotmail.com
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: syzbot+fd7b34375c1c8ce29c93@syzkaller.appspotmail.com
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=fd7b34375c1c8ce29c93 [1]
    Link: https://lore.kernel.org/bpf/20240218150933.6004-1-syoshida@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
btrfs: defrag: avoid unnecessary defrag caused by incorrect extent size [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Wed Feb 7 10:00:42 2024 +1030

    btrfs: defrag: avoid unnecessary defrag caused by incorrect extent size
    
    commit e42b9d8b9ea2672811285e6a7654887ff64d23f3 upstream.
    
    [BUG]
    With the following file extent layout, defrag would do unnecessary IO
    and result more on-disk space usage.
    
      # mkfs.btrfs -f $dev
      # mount $dev $mnt
      # xfs_io -f -c "pwrite 0 40m" $mnt/foobar
      # sync
      # xfs_io -f -c "pwrite 40m 16k" $mnt/foobar
      # sync
    
    Above command would lead to the following file extent layout:
    
            item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53
                    generation 7 type 1 (regular)
                    extent data disk byte 298844160 nr 41943040
                    extent data offset 0 nr 41943040 ram 41943040
                    extent compression 0 (none)
            item 7 key (257 EXTENT_DATA 41943040) itemoff 15763 itemsize 53
                    generation 8 type 1 (regular)
                    extent data disk byte 13631488 nr 16384
                    extent data offset 0 nr 16384 ram 16384
                    extent compression 0 (none)
    
    Which is mostly fine. We can allow the final 16K to be merged with the
    previous 40M, but it's upon the end users' preference.
    
    But if we defrag the file using the default parameters, it would result
    worse file layout:
    
     # btrfs filesystem defrag $mnt/foobar
     # sync
    
            item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53
                    generation 7 type 1 (regular)
                    extent data disk byte 298844160 nr 41943040
                    extent data offset 0 nr 8650752 ram 41943040
                    extent compression 0 (none)
            item 7 key (257 EXTENT_DATA 8650752) itemoff 15763 itemsize 53
                    generation 9 type 1 (regular)
                    extent data disk byte 340787200 nr 33292288
                    extent data offset 0 nr 33292288 ram 33292288
                    extent compression 0 (none)
            item 8 key (257 EXTENT_DATA 41943040) itemoff 15710 itemsize 53
                    generation 8 type 1 (regular)
                    extent data disk byte 13631488 nr 16384
                    extent data offset 0 nr 16384 ram 16384
                    extent compression 0 (none)
    
    Note the original 40M extent is still there, but a new 32M extent is
    created for no benefit at all.
    
    [CAUSE]
    There is an existing check to make sure we won't defrag a large enough
    extent (the threshold is by default 32M).
    
    But the check is using the length to the end of the extent:
    
            range_len = em->len - (cur - em->start);
    
            /* Skip too large extent */
            if (range_len >= extent_thresh)
                    goto next;
    
    This means, for the first 8MiB of the extent, the range_len is always
    smaller than the default threshold, and would not be defragged.
    But after the first 8MiB, the remaining part would fit the requirement,
    and be defragged.
    
    Such different behavior inside the same extent caused the above problem,
    and we should avoid different defrag decision inside the same extent.
    
    [FIX]
    Instead of using @range_len, just use @em->len, so that we have a
    consistent decision among the same file extent.
    
    Now with this fix, we won't touch the extent, thus not making it any
    worse.
    
    Reported-by: Filipe Manana <fdmanana@suse.com>
    Fixes: 0cb5950f3f3b ("btrfs: fix deadlock when reserving space during defrag")
    CC: stable@vger.kernel.org # 6.1+
    Reviewed-by: Boris Burkov <boris@bur.io>
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bus: imx-weim: fix valid range check [+ + +]
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Jan 19 19:50:26 2024 +0100

    bus: imx-weim: fix valid range check
    
    [ Upstream commit 7bca405c986075c99b9f729d3587b5c45db39d01 ]
    
    When the range parsing was open-coded the number of u32 entries to
    parse had to be a multiple of 4 and the driver checks this. With
    the range parsing converted to the range parser the counting changes
    from individual u32 entries to a complete range, so the check must
    not reject counts not divisible by 4.
    
    Fixes: 2a88e4792c6d ("bus: imx-weim: Remove open coded "ranges" parsing")
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cache: ax45mp_cache: Align end size to cache boundary in ax45mp_dma_cache_wback() [+ + +]
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date:   Sat Feb 3 21:26:40 2024 +0000

    cache: ax45mp_cache: Align end size to cache boundary in ax45mp_dma_cache_wback()
    
    [ Upstream commit 9bd405c48b0ac4de087c0c4440fd79597201b8a7 ]
    
    Align the end size to cache boundary size in ax45mp_dma_cache_wback()
    callback likewise done in ax45mp_dma_cache_inv() callback.
    
    Additionally return early in case of start == end.
    
    Fixes: d34599bcd2e4 ("cache: Add L2 cache management for Andes AX45MP RISC-V core")
    Reported-by: Pavel Machek <pavel@denx.de>
    Link: https://lore.kernel.org/cip-dev/ZYsdKDiw7G+kxQ3m@duo.ucw.cz/
    Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cachefiles: fix memory leak in cachefiles_add_cache() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Sat Feb 17 16:14:31 2024 +0800

    cachefiles: fix memory leak in cachefiles_add_cache()
    
    commit e21a2f17566cbd64926fb8f16323972f7a064444 upstream.
    
    The following memory leak was reported after unbinding /dev/cachefiles:
    
    ==================================================================
    unreferenced object 0xffff9b674176e3c0 (size 192):
      comm "cachefilesd2", pid 680, jiffies 4294881224
      hex dump (first 32 bytes):
        01 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 ea38a44b):
        [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
        [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
        [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
        [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
        [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
        [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
        [<ffffffff8ebc5069>] ksys_write+0x69/0xf0
        [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
        [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
    ==================================================================
    
    Put the reference count of cache_cred in cachefiles_daemon_unbind() to
    fix the problem. And also put cache_cred in cachefiles_add_cache() error
    branch to avoid memory leaks.
    
    Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem")
    CC: stable@vger.kernel.org
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Link: https://lore.kernel.org/r/20240217081431.796809-1-libaokun1@huawei.com
    Acked-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ceph: always check dir caps asynchronously [+ + +]
Author: Xiubo Li <xiubli@redhat.com>
Date:   Thu Jan 4 09:21:30 2024 +0800

    ceph: always check dir caps asynchronously
    
    [ Upstream commit 07045648c07c5632e0dfd5ce084d3cd0cec0258a ]
    
    The MDS will issue the 'Fr' caps for async dirop, while there is
    buggy in kclient and it could miss releasing the async dirop caps,
    which is 'Fsxr'. And then the MDS will complain with:
    
    "[WRN] client.xxx isn't responding to mclientcaps(revoke) ..."
    
    So when releasing the dirop async requests or when they fail we
    should always make sure that being revoked caps could be released.
    
    Link: https://tracker.ceph.com/issues/50223
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Milind Changire <mchangir@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cifs: change tcon status when need_reconnect is set on it [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Tue Feb 6 15:00:46 2024 +0000

    cifs: change tcon status when need_reconnect is set on it
    
    [ Upstream commit c6e02eefd6ace3da3369c764f15429f5647056af ]
    
    When a tcon is marked for need_reconnect, the intention
    is to have it reconnected.
    
    This change adjusts tcon->status in cifs_tree_connect
    when need_reconnect is set. Also, this change has a minor
    correction in resetting need_reconnect on success. It makes
    sure that it is done with tc_lock held.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: cifs_pick_channel should try selecting active channels [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Sun Jan 21 03:32:43 2024 +0000

    cifs: cifs_pick_channel should try selecting active channels
    
    [ Upstream commit fc43a8ac396d302ced1e991e4913827cf72c8eb9 ]
    
    cifs_pick_channel today just selects a channel based
    on the policy of least loaded channel. However, it
    does not take into account if the channel needs
    reconnect. As a result, we can have failures in send
    that can be completely avoided.
    
    This change doesn't make a channel a candidate for
    this selection if it needs reconnect.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: do not search for channel if server is terminating [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Thu Feb 1 11:15:28 2024 +0000

    cifs: do not search for channel if server is terminating
    
    [ Upstream commit 88675b22d34e6e815ad4bde09c590ccb2d50c59d ]
    
    In order to scale down the channels, the following sequence
    of operations happen:
    1. server struct is marked for terminate
    2. the channel is deallocated in the ses->chans array
    3. at a later point the cifsd thread actually terminates the server
    
    Between 2 and 3, there can be calls to find the channel for
    a server struct. When that happens, there can be an ugly warning
    that's logged. But this is expected.
    
    So this change does two things:
    1. in cifs_ses_get_chan_index, if server->terminate is set, return
    2. always make sure server->terminate is set with chan_lock held
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: handle cases where multiple sessions share connection [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Tue Feb 6 15:00:47 2024 +0000

    cifs: handle cases where multiple sessions share connection
    
    [ Upstream commit a39c757bf0596b17482a507f31c3ef0af0d1d2b4 ]
    
    Based on our implementation of multichannel, it is entirely
    possible that a server struct may not be found in any channel
    of an SMB session.
    
    In such cases, we should be prepared to move on and search for
    the server struct in the next session.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: helper function to check replayable error codes [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Sun Jan 21 03:32:46 2024 +0000

    cifs: helper function to check replayable error codes
    
    [ Upstream commit 64cc377b7628b81ffdbdb1c6bacfba895dcac3f8 ]
    
    The code to check for replay is not just -EAGAIN. In some
    cases, the send request or receive response may result in
    network errors, which we're now mapping to -ECONNABORTED.
    
    This change introduces a helper function which checks
    if the error returned in one of the above two errors.
    And all checks for replays will now use this helper.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: make sure that channel scaling is done only once [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Mon Jan 29 13:58:13 2024 +0000

    cifs: make sure that channel scaling is done only once
    
    [ Upstream commit ee36a3b345c433a846effcdcfba437c2298eeda5 ]
    
    Following a successful cifs_tree_connect, we have the code
    to scale up/down the number of channels in the session.
    However, it is not protected by a lock today.
    
    As a result, this code can be executed by several processes
    that select the same channel. The core functions handle this
    well, as they pick chan_lock. However, we've seen cases where
    smb2_reconnect throws some warnings.
    
    To fix that, this change introduces a flags bitmap inside the
    cifs_ses structure. A new flag type is used to ensure that
    only one process enters this section at any time.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: open_cached_dir should not rely on primary channel [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Wed Jan 17 05:55:39 2024 +0000

    cifs: open_cached_dir should not rely on primary channel
    
    [ Upstream commit 936eba9cfb5cfbf6a2c762cd163605f2b784e03e ]
    
    open_cached_dir today selects ses->server a.k.a primary channel
    to send requests. When multichannel is used, the primary
    channel maybe down. So it does not make sense to rely only
    on that channel.
    
    This fix makes this function pick a channel with the standard
    helper function cifs_pick_channel.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: translate network errors on send to -ECONNABORTED [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Sun Jan 21 03:32:45 2024 +0000

    cifs: translate network errors on send to -ECONNABORTED
    
    [ Upstream commit a68106a6928e0a6680f12bcc7338c0dddcfe4d11 ]
    
    When the network stack returns various errors, we today bubble
    up the error to the user (in case of soft mounts).
    
    This change translates all network errors except -EINTR and
    -EAGAIN to -ECONNABORTED. A similar approach is taken when
    we receive network errors when reading from the socket.
    
    The change also forces the cifsd thread to reconnect during
    it's next activity.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
crypto: virtio/akcipher - Fix stack overflow on memcpy [+ + +]
Author: zhenwei pi <pizhenwei@bytedance.com>
Date:   Tue Jan 30 19:27:40 2024 +0800

    crypto: virtio/akcipher - Fix stack overflow on memcpy
    
    commit c0ec2a712daf133d9996a8a1b7ee2d4996080363 upstream.
    
    sizeof(struct virtio_crypto_akcipher_session_para) is less than
    sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from
    stack variable leads stack overflow. Clang reports this issue by
    commands:
    make -j CC=clang-14 mrproper >/dev/null 2>&1
    make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1
    make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/
      virtio_crypto_akcipher_algs.o
    
    Fixes: 59ca6c93387d ("virtio-crypto: implement RSA algorithm")
    Link: https://lore.kernel.org/all/0a194a79-e3a3-45e7-be98-83abd3e1cb7e@roeck-us.net/
    Cc: <stable@vger.kernel.org>
    Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
    Tested-by: Nathan Chancellor <nathan@kernel.org> # build
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cxl/acpi: Fix load failures due to single window creation failure [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Feb 16 19:11:34 2024 -0800

    cxl/acpi: Fix load failures due to single window creation failure
    
    commit 5c6224bfabbf7f3e491c51ab50fd2c6f92ba1141 upstream.
    
    The expectation is that cxl_parse_cfwms() continues in the face the of
    failure as evidenced by code like:
    
        cxlrd = cxl_root_decoder_alloc(root_port, ways, cxl_calc_hb);
        if (IS_ERR(cxlrd))
            return 0;
    
    There are other error paths in that function which mistakenly follow
    idiomatic expectations and return an error when they should not. Most of
    those mistakes are innocuous checks that hardly ever fail in practice.
    However, a recent change succeed in making the implementation more
    fragile by applying an idiomatic, but still wrong "fix" [1]. In this
    failure case the kernel reports:
    
        cxl root0: Failed to populate active decoder targets
        cxl_acpi ACPI0017:00: Failed to add decode range: [mem 0x00000000-0x7fffffff flags 0x200]
    
    ...which is a real issue with that one window (to be fixed separately),
    but ends up failing the entirety of cxl_acpi_probe().
    
    Undo that recent breakage while also removing the confusion about
    ignoring errors. Update all exits paths to return an error per typical
    expectations and let an outer wrapper function handle dropping the
    error.
    
    Fixes: 91019b5bc7c2 ("cxl/acpi: Return 'rc' instead of '0' in cxl_parse_cfmws()") [1]
    Cc: <stable@vger.kernel.org>
    Cc: Breno Leitao <leitao@debian.org>
    Cc: Alison Schofield <alison.schofield@intel.com>
    Cc: Vishal Verma <vishal.l.verma@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window [+ + +]
Author: Robert Richter <rrichter@amd.com>
Date:   Fri Feb 16 17:01:13 2024 +0100

    cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window
    
    commit 0cab687205986491302cd2e440ef1d253031c221 upstream.
    
    The Linux CXL subsystem is built on the assumption that HPA == SPA.
    That is, the host physical address (HPA) the HDM decoder registers are
    programmed with are system physical addresses (SPA).
    
    During HDM decoder setup, the DVSEC CXL range registers (cxl-3.1,
    8.1.3.8) are checked if the memory is enabled and the CXL range is in
    a HPA window that is described in a CFMWS structure of the CXL host
    bridge (cxl-3.1, 9.18.1.3).
    
    Now, if the HPA is not an SPA, the CXL range does not match a CFMWS
    window and the CXL memory range will be disabled then. The HDM decoder
    stops working which causes system memory being disabled and further a
    system hang during HDM decoder initialization, typically when a CXL
    enabled kernel boots.
    
    Prevent a system hang and do not disable the HDM decoder if the
    decoder's CXL range is not found in a CFMWS window.
    
    Note the change only fixes a hardware hang, but does not implement
    HPA/SPA translation. Support for this can be added in a follow on
    patch series.
    
    Signed-off-by: Robert Richter <rrichter@amd.com>
    Fixes: 34e37b4c432c ("cxl/port: Enable HDM Capability after validating DVSEC Ranges")
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240216160113.407141-1-rrichter@amd.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cxl/pci: Skip to handle RAS errors if CXL.mem device is detached [+ + +]
Author: Li Ming <ming4.li@intel.com>
Date:   Mon Jan 29 13:18:56 2024 +0000

    cxl/pci: Skip to handle RAS errors if CXL.mem device is detached
    
    commit eef5c7b28dbecd6b141987a96db6c54e49828102 upstream.
    
    The PCI AER model is an awkward fit for CXL error handling. While the
    expectation is that a PCI device can escalate to link reset to recover
    from an AER event, the same reset on CXL amounts to a surprise memory
    hotplug of massive amounts of memory.
    
    At present, the CXL error handler attempts some optimistic error
    handling to unbind the device from the cxl_mem driver after reaping some
    RAS register values. This results in a "hopeful" attempt to unplug the
    memory, but there is no guarantee that will succeed.
    
    A subsequent AER notification after the memdev unbind event can no
    longer assume the registers are mapped. Check for memdev bind before
    reaping status register values to avoid crashes of the form:
    
     BUG: unable to handle page fault for address: ffa00000195e9100
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     [...]
     RIP: 0010:__cxl_handle_ras+0x30/0x110 [cxl_core]
     [...]
     Call Trace:
      <TASK>
      ? __die+0x24/0x70
      ? page_fault_oops+0x82/0x160
      ? kernelmode_fixup_or_oops+0x84/0x110
      ? exc_page_fault+0x113/0x170
      ? asm_exc_page_fault+0x26/0x30
      ? __pfx_dpc_reset_link+0x10/0x10
      ? __cxl_handle_ras+0x30/0x110 [cxl_core]
      ? find_cxl_port+0x59/0x80 [cxl_core]
      cxl_handle_rp_ras+0xbc/0xd0 [cxl_core]
      cxl_error_detected+0x6c/0xf0 [cxl_core]
      report_error_detected+0xc7/0x1c0
      pci_walk_bus+0x73/0x90
      pcie_do_recovery+0x23f/0x330
    
    Longer term, the unbind and PCI_ERS_RESULT_DISCONNECT behavior might
    need to be replaced with a new PCI_ERS_RESULT_PANIC.
    
    Fixes: 6ac07883dbb5 ("cxl/pci: Add RCH downstream port error logging")
    Cc: stable@vger.kernel.org
    Suggested-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Li Ming <ming4.li@intel.com>
    Link: https://lore.kernel.org/r/20240129131856.2458980-1-ming4.li@intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Wed Feb 14 11:13:08 2024 -0800

    dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished().
    
    [ Upstream commit 66b60b0c8c4a163b022a9f0ad6769b0fd3dc662f ]
    
    syzkaller reported a warning [0] in inet_csk_destroy_sock() with no
    repro.
    
      WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash);
    
    However, the syzkaller's log hinted that connect() failed just before
    the warning due to FAULT_INJECTION.  [1]
    
    When connect() is called for an unbound socket, we search for an
    available ephemeral port.  If a bhash bucket exists for the port, we
    call __inet_check_established() or __inet6_check_established() to check
    if the bucket is reusable.
    
    If reusable, we add the socket into ehash and set inet_sk(sk)->inet_num.
    
    Later, we look up the corresponding bhash2 bucket and try to allocate
    it if it does not exist.
    
    Although it rarely occurs in real use, if the allocation fails, we must
    revert the changes by check_established().  Otherwise, an unconnected
    socket could illegally occupy an ehash entry.
    
    Note that we do not put tw back into ehash because sk might have
    already responded to a packet for tw and it would be better to free
    tw earlier under such memory presure.
    
    [0]:
    WARNING: CPU: 0 PID: 350830 at net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
    Modules linked in:
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
    Code: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd <0f> 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e7 be 03 00 00 00 e8 05
    RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40
    RDX: ffff88806e46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8
    RBP: ffff88811755c880 R08: 0000000000000003 R09: 0000000000000000
    R10: 0000000000009e78 R11: 0000000000000000 R12: ffff88811755c8e0
    R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000
    FS:  00007f03e5243800(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
     dccp_close (net/dccp/proto.c:1078)
     inet_release (net/ipv4/af_inet.c:434)
     __sock_release (net/socket.c:660)
     sock_close (net/socket.c:1423)
     __fput (fs/file_table.c:377)
     __fput_sync (fs/file_table.c:462)
     __x64_sys_close (fs/open.c:1557 fs/open.c:1539 fs/open.c:1539)
     do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
    RIP: 0033:0x7f03e53852bb
    Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 43 c9 f5 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 c9 f5 ff 8b 44
    RSP: 002b:00000000005dfba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
    RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f03e53852bb
    RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000003
    RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000167c
    R10: 0000000008a79680 R11: 0000000000000293 R12: 00007f03e4e43000
    R13: 00007f03e4e43170 R14: 00007f03e4e43178 R15: 00007f03e4e43170
     </TASK>
    
    [1]:
    FAULT_INJECTION: forcing a failure.
    name failslab, interval 1, probability 0, space 0, times 0
    CPU: 0 PID: 350833 Comm: syz-executor.1 Not tainted 6.7.0-12272-g2121c43f88f5 #9
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
     should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)
     should_failslab (mm/slub.c:3748)
     kmem_cache_alloc (mm/slub.c:3763 mm/slub.c:3842 mm/slub.c:3867)
     inet_bind2_bucket_create (net/ipv4/inet_hashtables.c:135)
     __inet_hash_connect (net/ipv4/inet_hashtables.c:1100)
     dccp_v4_connect (net/dccp/ipv4.c:116)
     __inet_stream_connect (net/ipv4/af_inet.c:676)
     inet_stream_connect (net/ipv4/af_inet.c:747)
     __sys_connect_file (net/socket.c:2048 (discriminator 2))
     __sys_connect (net/socket.c:2065)
     __x64_sys_connect (net/socket.c:2072)
     do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
    RIP: 0033:0x7f03e5284e5d
    Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
    RSP: 002b:00007f03e4641cc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
    RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f03e5284e5d
    RDX: 0000000000000010 RSI: 0000000020000000 RDI: 0000000000000003
    RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
    R13: 000000000000000b R14: 00007f03e52e5530 R15: 0000000000000000
     </TASK>
    
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Fixes: 28044fc1d495 ("net: Add a bhash2 table hashed by port and address")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
devlink: fix port dump cmd type [+ + +]
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Tue Feb 20 08:52:45 2024 +0100

    devlink: fix port dump cmd type
    
    [ Upstream commit 61c43780e9444123410cd48c2483e01d2b8f75e8 ]
    
    Unlike other commands, due to a c&p error, port dump fills-up cmd with
    wrong value, different from port-get request cmd, port-get doit reply
    and port notification.
    
    Fix it by filling cmd with value DEVLINK_CMD_PORT_NEW.
    
    Skimmed through devlink userspace implementations, none of them cares
    about this cmd value. Only ynl, for which, this is actually a fix, as it
    expects doit and dumpit ops rsp_value to be the same.
    
    Omit the fixes tag, even thought this is fix, better to target this for
    next release.
    
    Fixes: bfcd3a466172 ("Introduce devlink infrastructure")
    Signed-off-by: Jiri Pirko <jiri@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Jakub Kicinski <kuba@kernel.org>
    Link: https://lore.kernel.org/r/20240220075245.75416-1-jiri@resnulli.us
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

devlink: fix possible use-after-free and memory leaks in devlink_init() [+ + +]
Author: Vasiliy Kovalev <kovalev@altlinux.org>
Date:   Thu Feb 15 23:34:00 2024 +0300

    devlink: fix possible use-after-free and memory leaks in devlink_init()
    
    [ Upstream commit def689fc26b9a9622d2e2cb0c4933dd3b1c8071c ]
    
    The pernet operations structure for the subsystem must be registered
    before registering the generic netlink family.
    
    Make an unregister in case of unsuccessful registration.
    
    Fixes: 687125b5799c ("devlink: split out core code")
    Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
    Link: https://lore.kernel.org/r/20240215203400.29976-1-kovalev@altlinux.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.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>

dm-crypt: recheck the integrity tag after a failure [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Feb 19 21:31:11 2024 +0100

    dm-crypt: recheck the integrity tag after a failure
    
    commit 42e15d12070b4ff9af2b980f1b65774c2dab0507 upstream.
    
    If a userspace process reads (with O_DIRECT) multiple blocks into the same
    buffer, dm-crypt reports an authentication error [1]. The error is
    reported in a log and it may cause RAID leg being kicked out of the
    array.
    
    This commit fixes dm-crypt, so that if integrity verification fails, the
    data is read again into a kernel buffer (where userspace can't modify it)
    and the integrity tag is rechecked. If the recheck succeeds, the content
    of the kernel buffer is copied into the user buffer; if the recheck fails,
    an integrity error is reported.
    
    [1] https://people.redhat.com/~mpatocka/testcases/blk-auth-modify/read2.c
    
    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>

 
dm-integrity, dm-verity: reduce stack usage for recheck [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sat Feb 24 14:48:03 2024 +0100

    dm-integrity, dm-verity: reduce stack usage for recheck
    
    commit 66ad2fbcdbeab0edfd40c5d94f32f053b98c2320 upstream.
    
    The newly added integrity_recheck() function has another larger stack
    allocation, just like its caller integrity_metadata(). When it gets
    inlined, the combination of the two exceeds the warning limit for 32-bit
    architectures and possibly risks an overflow when this is called from
    a deep call chain through a file system:
    
    drivers/md/dm-integrity.c:1767:13: error: stack frame size (1048) exceeds limit (1024) in 'integrity_metadata' [-Werror,-Wframe-larger-than]
     1767 | static void integrity_metadata(struct work_struct *w)
    
    Since the caller at this point is done using its checksum buffer,
    just reuse the same buffer in the new function to avoid the double
    allocation.
    
    [Mikulas: add "noinline" to integrity_recheck and verity_recheck.
    These functions are only called on error, so they shouldn't bloat the
    stack frame or code size of the caller.]
    
    Fixes: c88f5e553fe3 ("dm-integrity: recheck the integrity tag after a failure")
    Fixes: 9177f3c0dea6 ("dm-verity: recheck the hash after a failure")
    Cc: stable@vger.kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm-integrity: recheck the integrity tag after a failure [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Feb 19 21:27:39 2024 +0100

    dm-integrity: recheck the integrity tag after a failure
    
    commit c88f5e553fe38b2ffc4c33d08654e5281b297677 upstream.
    
    If a userspace process reads (with O_DIRECT) multiple blocks into the same
    buffer, dm-integrity reports an error [1]. The error is reported in a log
    and it may cause RAID leg being kicked out of the array.
    
    This commit fixes dm-integrity, so that if integrity verification fails,
    the data is read again into a kernel buffer (where userspace can't modify
    it) and the integrity tag is rechecked. If the recheck succeeds, the
    content of the kernel buffer is copied into the user buffer; if the
    recheck fails, an integrity error is reported.
    
    [1] https://people.redhat.com/~mpatocka/testcases/blk-auth-modify/read2.c
    
    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>

 
dm-verity: recheck the hash after a failure [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Feb 19 21:28:09 2024 +0100

    dm-verity: recheck the hash after a failure
    
    commit 9177f3c0dea6143d05cac1bbd28668fd0e216d11 upstream.
    
    If a userspace process reads (with O_DIRECT) multiple blocks into the same
    buffer, dm-verity reports an error [1].
    
    This commit fixes dm-verity, so that if hash verification fails, the data
    is read again into a kernel buffer (where userspace can't modify it) and
    the hash is rechecked. If the recheck succeeds, the content of the kernel
    buffer is copied into the user buffer; if the recheck fails, an error is
    reported.
    
    [1] https://people.redhat.com/~mpatocka/testcases/blk-auth-modify/read2.c
    
    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: apple-admac: Keep upper bits of REG_BUS_WIDTH [+ + +]
Author: Hector Martin <marcan@marcan.st>
Date:   Sun Oct 29 18:07:04 2023 +0100

    dmaengine: apple-admac: Keep upper bits of REG_BUS_WIDTH
    
    [ Upstream commit 306f5df81fcc89b462fbeb9dbe26d9a8ad7c7582 ]
    
    For RX channels, REG_BUS_WIDTH seems to default to a value of 0xf00, and
    macOS preserves the upper bits when setting the configuration in the
    lower ones. If we reset the upper bits to 0, this causes framing errors
    on suspend/resume (the data stream "tears" and channels get swapped
    around). Keeping the upper bits untouched, like the macOS driver does,
    fixes this issue.
    
    Signed-off-by: Hector Martin <marcan@marcan.st>
    Reviewed-by: Martin Povišer <povik+lin@cutebit.org>
    Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
    Link: https://lore.kernel.org/r/20231029170704.82238-1-povik+lin@cutebit.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: dw-edma: increase size of 'name' in debugfs code [+ + +]
Author: Vinod Koul <vkoul@kernel.org>
Date:   Fri Jan 19 18:10:44 2024 +0530

    dmaengine: dw-edma: increase size of 'name' in debugfs code
    
    [ Upstream commit cb95a4fa50bbc1262bfb7fea482388a50b12948f ]
    
    We seem to have hit warnings of 'output may be truncated' which is fixed
    by increasing the size of 'name'
    
    drivers/dma/dw-edma/dw-hdma-v0-debugfs.c: In function ‘dw_hdma_v0_debugfs_on’:
    drivers/dma/dw-edma/dw-hdma-v0-debugfs.c:125:50: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 8 [-Werror=format-truncation=]
      125 |                 snprintf(name, sizeof(name), "%s:%d", CHANNEL_STR, i);
          |                                                  ^~
    
    drivers/dma/dw-edma/dw-hdma-v0-debugfs.c: In function ‘dw_hdma_v0_debugfs_on’:
    drivers/dma/dw-edma/dw-hdma-v0-debugfs.c:142:50: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 8 [-Werror=format-truncation=]
      142 |                 snprintf(name, sizeof(name), "%s:%d", CHANNEL_STR, i);
          |                                                  ^~
    drivers/dma/dw-edma/dw-edma-v0-debugfs.c: In function ‘dw_edma_debugfs_regs_wr’:
    drivers/dma/dw-edma/dw-edma-v0-debugfs.c:193:50: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 8 [-Werror=format-truncation=]
      193 |                 snprintf(name, sizeof(name), "%s:%d", CHANNEL_STR, i);
          |                                                  ^~
    
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
docs: Instruct LaTeX to cope with deeper nesting [+ + +]
Author: Jonathan Corbet <corbet@lwn.net>
Date:   Mon Feb 19 09:05:38 2024 -0700

    docs: Instruct LaTeX to cope with deeper nesting
    
    commit 0df8669f69a8638f04c6a3d1f3b7056c2c18f62c upstream.
    
    The addition of the XFS online fsck documentation starting with
    commit a8f6c2e54ddc ("xfs: document the motivation for online fsck design")
    added a deeper level of nesting than LaTeX is prepared to deal with.  That
    caused a pdfdocs build failure with the helpful "Too deeply nested" error
    message buried deeply in Documentation/output/filesystems.log.
    
    Increase the "maxlistdepth" parameter to instruct LaTeX that it needs to
    deal with the deeper nesting whether it wants to or not.
    
    Suggested-by: Akira Yokosawa <akiyks@gmail.com>
    Tested-by: Akira Yokosawa <akiyks@gmail.com>
    Cc: stable@vger.kernel.org # v6.4+
    Link: https://lore.kernel.org/linux-doc/67f6ac60-7957-4b92-9d72-a08fbad0e028@gmail.com/
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Add dpia display mode validation logic [+ + +]
Author: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com>
Date:   Tue Dec 5 00:01:15 2023 -0500

    drm/amd/display: Add dpia display mode validation logic
    
    [ Upstream commit 59f1622a5f05d948a7c665a458a3dd76ba73015e ]
    
    [Why]
    If bandwidth allocation feature is enabled, connection manager wont
    limit the dp tunnel bandwidth. So, need to do display mode validation
    for streams on dpia links to avoid oversubscription of dp tunnel
    bandwidth.
    
    [How]
    - To read non reduced link rate and lane count and update
      reported link capability.
    - To calculate the bandwidth required for streams of dpia links
      per host router and validate against the allocated bandwidth for
      the host router.
    
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Reviewed-by: PeiChen Huang <peichen.huang@amd.com>
    Reviewed-by: Aric Cyr <aric.cyr@amd.com>
    Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
    Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: 0484e05d048b ("drm/amd/display: fixed integer types and null check locations")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: adjust few initialization order in dm [+ + +]
Author: Wayne Lin <wayne.lin@amd.com>
Date:   Fri Feb 2 17:34:11 2024 +0800

    drm/amd/display: adjust few initialization order in dm
    
    commit 22e1dc4b2fec17af70f297a4295c5f19a0f3fbeb upstream.
    
    [Why]
    Observe error message "Can't retrieve aconnector in hpd_rx_irq_offload_work"
    when boot up with a mst tbt4 dock connected. After analyzing, there are few
    parts needed to be adjusted:
    
    1. hpd_rx_offload_wq[].aconnector is not initialzed before the dmub outbox
    hpd_irq handler get registered which causes the error message.
    
    2. registeration of hpd and hpd_rx_irq event for usb4 dp tunneling is not
    aligned with legacy interface sequence
    
    [How]
    Put DMUB_NOTIFICATION_HPD and DMUB_NOTIFICATION_HPD_IRQ handler
    registration into register_hpd_handlers() to align other interfaces and
    get hpd_rx_offload_wq[].aconnector initialized earlier than that.
    
    Leave DMUB_NOTIFICATION_AUX_REPLY registered as it was since we need that
    while calling dc_link_detect(). USB4 connection status will be proactively
    detected by dc_link_detect_connection_type() in amdgpu_dm_initialize_drm_device()
    
    Cc: Stable <stable@vger.kernel.org>
    Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Avoid enum conversion warning [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Jan 10 13:46:47 2024 -0700

    drm/amd/display: Avoid enum conversion warning
    
    commit d7643fe6fb76edb1f2f1497bf5e8b8f4774b5129 upstream.
    
    Clang warns (or errors with CONFIG_WERROR=y) when performing arithmetic
    with different enumerated types, which is usually a bug:
    
        drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_dpia_bw.c:548:24: error: arithmetic between different enumeration types ('const enum dc_link_rate' and 'const enum dc_lane_count') [-Werror,-Wenum-enum-conversion]
          548 |                         link_cap->link_rate * link_cap->lane_count * LINK_RATE_REF_FREQ_IN_KHZ * 8;
              |                         ~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~
        1 error generated.
    
    In this case, there is not a problem because the enumerated types are
    basically treated as '#define' values. Add an explicit cast to an
    integral type to silence the warning.
    
    Closes: https://github.com/ClangBuiltLinux/linux/issues/1976
    Fixes: 5f3bce13266e ("drm/amd/display: Request usb4 bw for mst streams")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Disable ips before dc interrupt setting [+ + +]
Author: Roman Li <Roman.Li@amd.com>
Date:   Mon Jan 22 17:45:41 2024 -0500

    drm/amd/display: Disable ips before dc interrupt setting
    
    [ Upstream commit 8894b9283afd35b8d22ae07a0c118eb5f7d2e78b ]
    
    [Why]
    While in IPS2 an access to dcn registers is not allowed.
    If interrupt results in dc call, we should disable IPS.
    
    [How]
    Safeguard register access in IPS2 by disabling idle optimization
    before calling dc interrupt setting api.
    
    Signed-off-by: Roman Li <Roman.Li@amd.com>
    Tested-by: Mark Broadworth <mark.broadworth@amd.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Fix buffer overflow in 'get_host_router_total_dp_tunnel_bw()' [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Mon Jan 29 21:17:09 2024 +0530

    drm/amd/display: Fix buffer overflow in 'get_host_router_total_dp_tunnel_bw()'
    
    commit 97cba232549b9fe7e491fb60a69cf93075015f29 upstream.
    
    The error message buffer overflow 'dc->links' 12 <= 12 suggests that the
    code is trying to access an element of the dc->links array that is
    beyond its bounds. In C, arrays are zero-indexed, so an array with 12
    elements has valid indices from 0 to 11. Trying to access dc->links[12]
    would be an attempt to access the 13th element of a 12-element array,
    which is a buffer overflow.
    
    To fix this, ensure that the loop does not go beyond the last valid
    index when accessing dc->links[i + 1] by subtracting 1 from the loop
    condition.
    
    This would ensure that i + 1 is always a valid index in the array.
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_dpia_bw.c:208 get_host_router_total_dp_tunnel_bw() error: buffer overflow 'dc->links' 12 <= 12
    
    Fixes: 59f1622a5f05 ("drm/amd/display: Add dpia display mode validation logic")
    Cc: PeiChen Huang <peichen.huang@amd.com>
    Cc: Aric Cyr <aric.cyr@amd.com>
    Cc: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
    Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Cc: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Fix DPSTREAM CLK on and off sequence [+ + +]
Author: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
Date:   Wed Jan 17 16:46:02 2024 -0500

    drm/amd/display: Fix DPSTREAM CLK on and off sequence
    
    [ Upstream commit 31c2bf25eaf51c2d45f092284a28e97f43b54c15 ]
    
    [Why]
    Secondary DP2 display fails to light up in some instances
    
    [How]
    Clock needs to be on when DPSTREAMCLK*_EN =1. This change
    moves dtbclk_p enable/disable point to make sure this is
    the case
    
    Reviewed-by: Charlene Liu <charlene.liu@amd.com>
    Reviewed-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Daniel Miess <daniel.miess@amd.com>
    Signed-off-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    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/amd/display: fix null-pointer dereference on edid reading [+ + +]
Author: Melissa Wen <mwen@igalia.com>
Date:   Fri Feb 16 09:23:19 2024 -0300

    drm/amd/display: fix null-pointer dereference on edid reading
    
    [ Upstream commit 9671761792156f2339627918bafcd713a8a6f777 ]
    
    Use i2c adapter when there isn't aux_mode in dc_link to fix a
    null-pointer derefence that happens when running
    igt@kms_force_connector_basic in a system with DCN2.1 and HDMI connector
    detected as below:
    
    [  +0.178146] BUG: kernel NULL pointer dereference, address: 00000000000004c0
    [  +0.000010] #PF: supervisor read access in kernel mode
    [  +0.000005] #PF: error_code(0x0000) - not-present page
    [  +0.000004] PGD 0 P4D 0
    [  +0.000006] Oops: 0000 [#1] PREEMPT SMP NOPTI
    [  +0.000006] CPU: 15 PID: 2368 Comm: kms_force_conne Not tainted 6.5.0-asdn+ #152
    [  +0.000005] Hardware name: HP HP ENVY x360 Convertible 13-ay1xxx/8929, BIOS F.01 07/14/2021
    [  +0.000004] RIP: 0010:i2c_transfer+0xd/0x100
    [  +0.000011] Code: ea fc ff ff 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 55 53 <48> 8b 47 10 48 89 fb 48 83 38 00 0f 84 b3 00 00 00 83 3d 2f 80 16
    [  +0.000004] RSP: 0018:ffff9c4f89c0fad0 EFLAGS: 00010246
    [  +0.000005] RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000080
    [  +0.000003] RDX: 0000000000000002 RSI: ffff9c4f89c0fb20 RDI: 00000000000004b0
    [  +0.000003] RBP: ffff9c4f89c0fb80 R08: 0000000000000080 R09: ffff8d8e0b15b980
    [  +0.000003] R10: 00000000000380e0 R11: 0000000000000000 R12: 0000000000000080
    [  +0.000002] R13: 0000000000000002 R14: ffff9c4f89c0fb0e R15: ffff9c4f89c0fb0f
    [  +0.000004] FS:  00007f9ad2176c40(0000) GS:ffff8d90fe9c0000(0000) knlGS:0000000000000000
    [  +0.000003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  +0.000004] CR2: 00000000000004c0 CR3: 0000000121bc4000 CR4: 0000000000750ee0
    [  +0.000003] PKRU: 55555554
    [  +0.000003] Call Trace:
    [  +0.000006]  <TASK>
    [  +0.000006]  ? __die+0x23/0x70
    [  +0.000011]  ? page_fault_oops+0x17d/0x4c0
    [  +0.000008]  ? preempt_count_add+0x6e/0xa0
    [  +0.000008]  ? srso_alias_return_thunk+0x5/0x7f
    [  +0.000011]  ? exc_page_fault+0x7f/0x180
    [  +0.000009]  ? asm_exc_page_fault+0x26/0x30
    [  +0.000013]  ? i2c_transfer+0xd/0x100
    [  +0.000010]  drm_do_probe_ddc_edid+0xc2/0x140 [drm]
    [  +0.000067]  ? srso_alias_return_thunk+0x5/0x7f
    [  +0.000006]  ? _drm_do_get_edid+0x97/0x3c0 [drm]
    [  +0.000043]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
    [  +0.000042]  edid_block_read+0x3b/0xd0 [drm]
    [  +0.000043]  _drm_do_get_edid+0xb6/0x3c0 [drm]
    [  +0.000041]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
    [  +0.000043]  drm_edid_read_custom+0x37/0xd0 [drm]
    [  +0.000044]  amdgpu_dm_connector_mode_valid+0x129/0x1d0 [amdgpu]
    [  +0.000153]  drm_connector_mode_valid+0x3b/0x60 [drm_kms_helper]
    [  +0.000000]  __drm_helper_update_and_validate+0xfe/0x3c0 [drm_kms_helper]
    [  +0.000000]  ? amdgpu_dm_connector_get_modes+0xb6/0x520 [amdgpu]
    [  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
    [  +0.000000]  drm_helper_probe_single_connector_modes+0x2ab/0x540 [drm_kms_helper]
    [  +0.000000]  status_store+0xb2/0x1f0 [drm]
    [  +0.000000]  kernfs_fop_write_iter+0x136/0x1d0
    [  +0.000000]  vfs_write+0x24d/0x440
    [  +0.000000]  ksys_write+0x6f/0xf0
    [  +0.000000]  do_syscall_64+0x60/0xc0
    [  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
    [  +0.000000]  ? syscall_exit_to_user_mode+0x2b/0x40
    [  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
    [  +0.000000]  ? do_syscall_64+0x6c/0xc0
    [  +0.000000]  ? do_syscall_64+0x6c/0xc0
    [  +0.000000]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    [  +0.000000] RIP: 0033:0x7f9ad46b4b00
    [  +0.000000] Code: 40 00 48 8b 15 19 b3 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d e1 3a 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89
    [  +0.000000] RSP: 002b:00007ffcbd3bd6d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
    [  +0.000000] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9ad46b4b00
    [  +0.000000] RDX: 0000000000000002 RSI: 00007f9ad48a7417 RDI: 0000000000000009
    [  +0.000000] RBP: 0000000000000002 R08: 0000000000000064 R09: 0000000000000000
    [  +0.000000] R10: 0000000000000000 R11: 0000000000000202 R12: 00007f9ad48a7417
    [  +0.000000] R13: 0000000000000009 R14: 00007ffcbd3bd760 R15: 0000000000000001
    [  +0.000000]  </TASK>
    [  +0.000000] Modules linked in: ctr ccm rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel btmtk bluetooth uvcvideo videobuf2_vmalloc sha3_generic videobuf2_memops uvc jitterentropy_rng videobuf2_v4l2 videodev drbg videobuf2_common ansi_cprng mc ecdh_generic ecc qrtr binfmt_misc hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio snd_ctl_led joydev hid_sensor_iio_common rtw89_8852ae rtw89_8852a rtw89_pci snd_hda_codec_realtek rtw89_core snd_hda_codec_generic intel_rapl_msr ledtrig_audio intel_rapl_common snd_hda_codec_hdmi mac80211 snd_hda_intel snd_intel_dspcfg kvm_amd snd_hda_codec snd_soc_dmic snd_acp3x_rn snd_acp3x_pdm_dma libarc4 snd_hwdep snd_soc_core kvm snd_hda_core cfg80211 snd_pci_acp6x snd_pcm nls_ascii snd_timer hp_wmi snd_pci_acp5x nls_cp437 snd_rn_pci_acp3x ucsi_acpi sparse_keymap ccp snd platform_profile snd_acp_config typec_ucsi irqbypass vfat sp5100_tco
    [  +0.000000]  snd_soc_acpi fat rapl pcspkr wmi_bmof roles rfkill rng_core snd_pci_acp3x soundcore k10temp watchdog typec battery ac amd_pmc acpi_tad button hid_sensor_hub hid_multitouch evdev serio_raw msr parport_pc ppdev lp parport fuse loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic dm_crypt dm_mod efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c crc32c_generic xor raid6_pq raid1 raid0 multipath linear md_mod amdgpu amdxcp i2c_algo_bit drm_ttm_helper ttm crc32_pclmul crc32c_intel drm_exec gpu_sched drm_suballoc_helper nvme ghash_clmulni_intel drm_buddy drm_display_helper sha512_ssse3 nvme_core ahci xhci_pci sha512_generic hid_generic xhci_hcd libahci rtsx_pci_sdmmc t10_pi i2c_hid_acpi drm_kms_helper i2c_hid mmc_core libata aesni_intel crc64_rocksoft_generic crypto_simd amd_sfh crc64_rocksoft scsi_mod usbcore cryptd crc_t10dif cec drm crct10dif_generic hid rtsx_pci crct10dif_pclmul scsi_common rc_core crc64 i2c_piix4
    [  +0.000000]  usb_common crct10dif_common video wmi
    [  +0.000000] CR2: 00000000000004c0
    [  +0.000000] ---[ end trace 0000000000000000 ]---
    
    Fixes: 0e859faf8670 ("drm/amd/display: Remove unwanted drm edid references")
    Signed-off-by: Melissa Wen <mwen@igalia.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Fix potential null pointer dereference in dc_dmub_srv [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Mon Feb 19 11:43:16 2024 +0530

    drm/amd/display: Fix potential null pointer dereference in dc_dmub_srv
    
    [ Upstream commit d2b48f340d9e4a8fbeb1cdc84cd8da6ad143a907 ]
    
    Fixes potential null pointer dereference warnings in the
    dc_dmub_srv_cmd_list_queue_execute() and dc_dmub_srv_is_hw_pwr_up()
    functions.
    
    In both functions, the 'dc_dmub_srv' variable was being dereferenced
    before it was checked for null. This could lead to a null pointer
    dereference if 'dc_dmub_srv' is null. The fix is to check if
    'dc_dmub_srv' is null before dereferencing it.
    
    Thus moving the null checks for 'dc_dmub_srv' to the beginning of the
    functions to ensure that 'dc_dmub_srv' is not null when it is
    dereferenced.
    
    Found by smatch & thus fixing the below:
    drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:133 dc_dmub_srv_cmd_list_queue_execute() warn: variable dereferenced before check 'dc_dmub_srv' (see line 128)
    drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_is_hw_pwr_up() warn: variable dereferenced before check 'dc_dmub_srv' (see line 1164)
    
    Fixes: 028bac583449 ("drm/amd/display: decouple dmcub execution to reduce lock granularity")
    Fixes: 65138eb72e1f ("drm/amd/display: Add DCN35 DMUB")
    Cc: JinZe.Xu <jinze.xu@amd.com>
    Cc: Hersen Wu <hersenxs.wu@amd.com>
    Cc: Josip Pavic <josip.pavic@amd.com>
    Cc: Roman Li <roman.li@amd.com>
    Cc: Qingqing Zhuo <Qingqing.Zhuo@amd.com>
    Cc: Harry Wentland <Harry.Wentland@amd.com>
    Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Cc: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: fix USB-C flag update after enc10 feature init [+ + +]
Author: Charlene Liu <charlene.liu@amd.com>
Date:   Tue Jan 16 19:54:15 2024 -0500

    drm/amd/display: fix USB-C flag update after enc10 feature init
    
    [ Upstream commit b5abd7f983e14054593dc91d6df2aa5f8cc67652 ]
    
    [why]
    BIOS's integration info table not following the original order
    which is phy instance is ext_displaypath's array index.
    
    [how]
    Move them to follow the original order.
    
    Reviewed-by: Muhammad Ahmed <ahmed.ahmed@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Charlene Liu <charlene.liu@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: fixed integer types and null check locations [+ + +]
Author: Sohaib Nadeem <sohaib.nadeem@amd.com>
Date:   Wed Jan 31 16:40:37 2024 -0500

    drm/amd/display: fixed integer types and null check locations
    
    [ Upstream commit 0484e05d048b66d01d1f3c1d2306010bb57d8738 ]
    
    [why]:
    issues fixed:
    - comparison with wider integer type in loop condition which can cause
    infinite loops
    - pointer dereference before null check
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Josip Pavic <josip.pavic@amd.com>
    Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Sohaib Nadeem <sohaib.nadeem@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: increased min_dcfclk_mhz and min_fclk_mhz [+ + +]
Author: Sohaib Nadeem <sohaib.nadeem@amd.com>
Date:   Tue Jan 16 11:00:00 2024 -0500

    drm/amd/display: increased min_dcfclk_mhz and min_fclk_mhz
    
    [ Upstream commit 2ff33c759a4247c84ec0b7815f1f223e155ba82a ]
    
    [why]
    Originally, PMFW said min FCLK is 300Mhz, but min DCFCLK can be increased
    to 400Mhz because min FCLK is now 600Mhz so FCLK >= 1.5 * DCFCLK hardware
    requirement will still be satisfied. Increasing min DCFCLK addresses
    underflow issues (underflow occurs when phantom pipe is turned on for some
    Sub-Viewport configs).
    
    [how]
    Increasing DCFCLK by raising the min_dcfclk_mhz
    
    Reviewed-by: Chaitanya Dhere <chaitanya.dhere@amd.com>
    Reviewed-by: Alvin Lee <alvin.lee2@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Sohaib Nadeem <sohaib.nadeem@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Only allow dig mapping to pwrseq in new asic [+ + +]
Author: Lewis Huang <lewis.huang@amd.com>
Date:   Wed Jan 31 17:20:17 2024 +0800

    drm/amd/display: Only allow dig mapping to pwrseq in new asic
    
    commit 4e73826089ce899357580bbf6e0afe4e6f9900b7 upstream.
    
    [Why]
    The old asic only have 1 pwrseq hw.
    We don't need to map the diginst to pwrseq inst in old asic.
    
    [How]
    1. Only mapping dig to pwrseq for new asic.
    2. Move mapping function into dcn specific panel control component
    
    Cc: Stable <stable@vger.kernel.org> # v6.6+
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3122
    Reviewed-by: Anthony Koo <anthony.koo@amd.com>
    Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Lewis Huang <lewis.huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Request usb4 bw for mst streams [+ + +]
Author: Peichen Huang <peichen.huang@amd.com>
Date:   Thu Dec 14 23:16:34 2023 +0800

    drm/amd/display: Request usb4 bw for mst streams
    
    [ Upstream commit 5f3bce13266e6fe2f7a46f94d8bc94d5274e276b ]
    
    [WHY]
    When usb4 bandwidth allocation mode is enabled, driver need to request
    bandwidth from connection manager. For mst link,  the requested
    bandwidth should be big enough for all remote streams.
    
    [HOW]
    - If mst link, the requested bandwidth should be the sum of all mst
      streams bandwidth added with dp MTPH overhead.
    - Allocate/deallcate usb4 bandwidth when setting dpms on/off.
    - When doing display mode validation, driver also need to consider total
      bandwidth of all mst streams for mst link.
    
    Reviewed-by: Cruise Hung <cruise.hung@amd.com>
    Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
    Signed-off-by: Peichen Huang <peichen.huang@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: 0484e05d048b ("drm/amd/display: fixed integer types and null check locations")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd: Stop evicting resources on APUs in suspend [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed Feb 7 23:52:55 2024 -0600

    drm/amd: Stop evicting resources on APUs in suspend
    
    commit 3a9626c816db901def438dc2513622e281186d39 upstream.
    
    commit 5095d5418193 ("drm/amd: Evict resources during PM ops prepare()
    callback") intentionally moved the eviction of resources to earlier in
    the suspend process, but this introduced a subtle change that it occurs
    before adev->in_s0ix or adev->in_s3 are set. This meant that APUs
    actually started to evict resources at suspend time as well.
    
    Explicitly set s0ix or s3 in the prepare() stage, and unset them if the
    prepare() stage failed.
    
    v2: squash in warning fix from Stephen Rothwell
    
    Reported-by: Jürg Billeter <j@bitron.ch>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3132#note_2271038
    Fixes: 5095d5418193 ("drm/amd: Evict resources during PM ops prepare() callback")
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
drm/amdgpu: Fix HDP flush for VFs on nbio v7.9 [+ + +]
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Fri Dec 8 13:48:22 2023 +0530

    drm/amdgpu: Fix HDP flush for VFs on nbio v7.9
    
    [ Upstream commit 534c8a5b9d5d41d30cdcac93cfa1bca5e17be009 ]
    
    HDP flush remapping is not done for VFs. Keep the original offsets in VF
    environment.
    
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Fix shared buff copy to user [+ + +]
Author: Stanley.Yang <Stanley.Yang@amd.com>
Date:   Mon Feb 5 15:55:48 2024 +0800

    drm/amdgpu: Fix shared buff copy to user
    
    [ Upstream commit 2dcf82a8e8dc930655787797ef8a3692b527c7a9 ]
    
    ta if invoke node buffer
    |-------- ta type ----------|
    |--------  ta id  ----------|
    |-------- cmd  id ----------|
    |------ shared buf len -----|
    |------ shared buffer ------|
    
    ta if invoke node buffer is as above, copy shared buffer data to correct location
    
    Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Fix the runtime resume failure issue [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Wed Feb 21 17:16:49 2024 +0800

    drm/amdgpu: Fix the runtime resume failure issue
    
    commit bbfaf2aea7164db59739728d62d9cc91d64ff856 upstream.
    
    Don't set power state flag when system enter runtime suspend,
    or it may cause runtime resume failure issue.
    
    Fixes: 3a9626c816db ("drm/amd: Stop evicting resources on APUs in suspend")
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

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

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

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

 
drm/amdkfd: Use correct drm device for cgroup permission check [+ + +]
Author: Mukul Joshi <mukul.joshi@amd.com>
Date:   Fri Jan 26 15:14:50 2024 -0500

    drm/amdkfd: Use correct drm device for cgroup permission check
    
    [ Upstream commit 4119734e06a7f30e7e8eb666692a58b85dca0269 ]
    
    On GFX 9.4.3, for a given KFD node, fetch the correct drm device from
    XCP manager when checking for cgroup permissions.
    
    Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
    Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/buddy: Modify duplicate list_splice_tail call [+ + +]
Author: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Date:   Fri Feb 16 15:30:48 2024 +0530

    drm/buddy: Modify duplicate list_splice_tail call
    
    commit 02f76a9cd4494719600baf1ab278930df39431ab upstream.
    
    Remove the duplicate list_splice_tail call when the
    total_allocated < size condition is true.
    
    Cc: <stable@vger.kernel.org> # 6.7+
    Fixes: 8746c6c9dfa3 ("drm/buddy: Fix alloc_range() error handling code")
    Reported-by: Bert Karwatzki <spasswolf@web.de>
    Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
    Reviewed-by: Matthew Auld <matthew.auld@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240216100048.4101-1-Arunpravin.PaneerSelvam@amd.com
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915/tv: Fix TV mode [+ + +]
Author: Maxime Ripard <mripard@kernel.org>
Date:   Tue Feb 20 14:12:51 2024 +0100

    drm/i915/tv: Fix TV mode
    
    [ Upstream commit fb1e881273f432e593f8789f99e725b09304cc97 ]
    
    Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
    to update all the users of the struct drm_tv_connector_state mode field,
    which resulted in a build failure in i915.
    
    However, a subsequent commit in the same series reintroduced a mode
    field in that structure, with a different semantic but the same type,
    with the assumption that all previous users were updated.
    
    Since that didn't happen, the i915 driver now compiles, but mixes
    accesses to the legacy_mode field and the newer mode field, but with the
    previous semantics.
    
    This obviously doesn't work very well, so we need to update the accesses
    that weren't in the legacy renaming commit.
    
    Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
    Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240220131251.453060-1-mripard@kernel.org
    (cherry picked from commit bf7626f19d6ff14b9722273e23700400cc4d78ba)
    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/meson: Don't remove bridges which are created by other drivers [+ + +]
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Thu Feb 15 23:04:42 2024 +0100

    drm/meson: Don't remove bridges which are created by other drivers
    
    commit bd915ae73a2d78559b376ad2caf5e4ef51de2455 upstream.
    
    Stop calling drm_bridge_remove() for bridges allocated/managed by other
    drivers in the remove paths of meson_encoder_{cvbs,dsi,hdmi}.
    drm_bridge_remove() unregisters the bridge so it cannot be used
    anymore. Doing so for bridges we don't own can lead to the video
    pipeline not being able to come up after -EPROBE_DEFER of the VPU
    because we're unregistering a bridge that's managed by another driver.
    The other driver doesn't know that we have unregistered it's bridge
    and on subsequent .probe() we're not able to find those bridges anymore
    (since nobody re-creates them).
    
    This fixes probe errors on Meson8b boards with the CVBS outputs enabled.
    
    Fixes: 09847723c12f ("drm/meson: remove drm bridges at aggregate driver unbind time")
    Fixes: 42dcf15f901c ("drm/meson: add DSI encoder")
    Cc:  <stable@vger.kernel.org>
    Reported-by: Steve Morvai <stevemorvai@hotmail.com>
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Tested-by: Steve Morvai <stevemorvai@hotmail.com>
    Link: https://lore.kernel.org/r/20240215220442.1343152-1-martin.blumenstingl@googlemail.com
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240215220442.1343152-1-martin.blumenstingl@googlemail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/nouveau/mmu/r535: uninitialized variable in r535_bar_new_() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Tue Feb 13 21:09:57 2024 +0300

    drm/nouveau/mmu/r535: uninitialized variable in r535_bar_new_()
    
    [ Upstream commit 65323796debe49a1922ba507020f7530a4b3f9af ]
    
    If gf100_bar_new_() fails then "bar" is not initialized.
    
    Fixes: 5bf0257136a2 ("drm/nouveau/mmu/r535: initial support")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/dab21df7-4d90-4479-97d8-97e5d228c714@moroto.mountain
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/nouveau: nvkm_gsp_radix3_sg() should use nvkm_gsp_mem_ctor() [+ + +]
Author: Timur Tabi <ttabi@nvidia.com>
Date:   Fri Feb 2 17:06:08 2024 -0600

    drm/nouveau: nvkm_gsp_radix3_sg() should use nvkm_gsp_mem_ctor()
    
    [ Upstream commit 34e659f34a7559ecfd9c1f5b24d4c291f3f54711 ]
    
    Function nvkm_gsp_radix3_sg() uses nvkm_gsp_mem objects to allocate the
    radix3 tables, but it unnecessarily creates those objects manually
    instead of using the standard nvkm_gsp_mem_ctor() function like the
    rest of the code does.
    
    Signed-off-by: Timur Tabi <ttabi@nvidia.com>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240202230608.1981026-2-ttabi@nvidia.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: handle NULL fence in syncobj_eventfd_entry_func [+ + +]
Author: Erik Kurzinger <ekurzinger@nvidia.com>
Date:   Wed Feb 21 10:44:28 2024 -0800

    drm/syncobj: handle NULL fence in syncobj_eventfd_entry_func
    
    [ Upstream commit 2aa6f5b0fd052e363bb9d4b547189f0bf6b3d6d3 ]
    
    During syncobj_eventfd_entry_func, dma_fence_chain_find_seqno may set
    the fence to NULL if the given seqno is signaled and a later seqno has
    already been submitted. In that case, the eventfd should be signaled
    immediately which currently does not happen.
    
    This is a similar issue to the one addressed by commit b19926d4f3a6
    ("drm/syncobj: Deal with signalled fences in drm_syncobj_find_fence.").
    
    As a fix, if the return value of dma_fence_chain_find_seqno indicates
    success but it sets the fence to NULL, we will assign a stub fence to
    ensure the following code still signals the eventfd.
    
    v1 -> v2: assign a stub fence instead of signaling the eventfd
    
    Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
    Fixes: c7a472297169 ("drm/syncobj: add IOCTL to register an eventfd")
    Signed-off-by: Simon Ser <contact@emersion.fr>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240221184527.37667-1-ekurzinger@nvidia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
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 refcount on the metabuf used for inode lookup [+ + +]
Author: Sandeep Dhavale <dhavale@google.com>
Date:   Wed Feb 21 13:03:47 2024 -0800

    erofs: fix refcount on the metabuf used for inode lookup
    
    commit 56ee7db31187dc36d501622cb5f1415e88e01c2a upstream.
    
    In erofs_find_target_block() when erofs_dirnamecmp() returns 0,
    we do not assign the target metabuf. This causes the caller
    erofs_namei()'s erofs_put_metabuf() at the end to be not effective
    leaving the refcount on the page.
    As the page from metabuf (buf->page) is never put, such page cannot be
    migrated or reclaimed. Fix it now by putting the metabuf from
    previous loop and assigning the current metabuf to target before
    returning so caller erofs_namei() can do the final put as it was
    intended.
    
    Fixes: 500edd095648 ("erofs: use meta buffers for inode lookup")
    Cc: <stable@vger.kernel.org> # 5.18+
    Signed-off-by: Sandeep Dhavale <dhavale@google.com>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Link: https://lore.kernel.org/r/20240221210348.3667795-1-dhavale@google.com
    Signed-off-by: Gao Xiang <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: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:37 2024 +0800

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

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

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

 
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>

 
Linux: Fix write to cloned skb in ipv6_hop_ioam() [+ + +]
Author: Justin Iurman <justin.iurman@uliege.be>
Date:   Mon Feb 19 14:52:54 2024 +0100

    Fix write to cloned skb in ipv6_hop_ioam()
    
    [ Upstream commit f198d933c2e4f8f89e0620fbaf1ea7eac384a0eb ]
    
    ioam6_fill_trace_data() writes inside the skb payload without ensuring
    it's writeable (e.g., not cloned). This function is called both from the
    input and output path. The output path (ioam6_iptunnel) already does the
    check. This commit provides a fix for the input path, inside
    ipv6_hop_ioam(). It also updates ip6_parse_tlv() to refresh the network
    header pointer ("nh") when returning from ipv6_hop_ioam().
    
    Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace")
    Reported-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Justin Iurman <justin.iurman@uliege.be>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fs/ntfs3: Add and fix comments [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Tue Nov 28 11:08:00 2023 +0300

    fs/ntfs3: Add and fix comments
    
    [ Upstream commit d6ca2d253900b9b0a3a1ad77541d606010f5e5eb ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Add file_modified [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 12:16:49 2023 +0300

    fs/ntfs3: Add file_modified
    
    [ Upstream commit 4dea9cd522424d3002894c20b729c6fbfb6fc22b ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

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

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

fs/ntfs3: Correct use bh_read [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 12:08:36 2023 +0300

    fs/ntfs3: Correct use bh_read
    
    [ Upstream commit a40b73f608e7de2120fdb9ddc8970421b3c50bc9 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

fs/ntfs3: Drop suid and sgid bits as a part of fpunch [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 12:17:46 2023 +0300

    fs/ntfs3: Drop suid and sgid bits as a part of fpunch
    
    [ Upstream commit e50f9560b8168a625703a3e7fe1fde9fa53f0837 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Fix c/mtime typo [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Tue Nov 28 11:17:20 2023 +0300

    fs/ntfs3: Fix c/mtime typo
    
    [ Upstream commit 652483bfbc45137e8dce556c9ddbd4458dad4452 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

fs/ntfs3: Fix multithreaded stress test [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 11:46:16 2023 +0300

    fs/ntfs3: Fix multithreaded stress test
    
    [ Upstream commit a8b0c9fc3a2dba07f697ef7825e04363ff12f071 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

fs/ntfs3: Fixed overflow check in mi_enum_attr() [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Jan 26 11:14:31 2024 +0300

    fs/ntfs3: Fixed overflow check in mi_enum_attr()
    
    [ Upstream commit 652cfeb43d6b9aba5c7c4902bed7a7340df131fb ]
    
    Reported-by: Robert Morris <rtm@csail.mit.edu>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Implement super_operations::shutdown [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 12:19:37 2023 +0300

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

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

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

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

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

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

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

fs/ntfs3: ntfs3_forced_shutdown use int instead of bool [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 12:21:12 2023 +0300

    fs/ntfs3: ntfs3_forced_shutdown use int instead of bool
    
    [ Upstream commit 97ec56d390a3a0077b36cb38627f671c72dddce6 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

fs/ntfs3: Reduce stack usage [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 11:42:04 2023 +0300

    fs/ntfs3: Reduce stack usage
    
    [ Upstream commit 865e7a7700d930d34895a70f8af2eb4e778a5b0e ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

fs/ntfs3: Use i_size_read and i_size_write [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Jan 26 11:12:38 2024 +0300

    fs/ntfs3: Use i_size_read and i_size_write
    
    [ Upstream commit 4fd6c08a16d7f1ba10212c9ef7bc73218144b463 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Use kvfree to free memory allocated by kvmalloc [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Tue Jan 16 10:32:20 2024 +0300

    fs/ntfs3: Use kvfree to free memory allocated by kvmalloc
    
    [ Upstream commit ddb17dc880eeaac37b5a6e984de07b882de7d78d ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
gpiolib: Handle no pin_ranges in gpiochip_generic_config() [+ + +]
Author: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Date:   Mon Feb 19 18:25:13 2024 +0100

    gpiolib: Handle no pin_ranges in gpiochip_generic_config()
    
    [ Upstream commit ae366ba8576da0135d7d3db2dfa6304f3338d0c2 ]
    
    Similar to gpiochip_generic_request() and gpiochip_generic_free() the
    gpiochip_generic_config() function needs to handle the case where there
    are no pinctrl pins mapped to the GPIOs, usually through the gpio-ranges
    device tree property.
    
    Commit f34fd6ee1be8 ("gpio: dwapb: Use generic request, free and
    set_config") set the .set_config callback to gpiochip_generic_config()
    in the dwapb GPIO driver so the GPIO API can set pinctrl configuration
    for the corresponding pins. Most boards using the dwapb driver do not
    set the gpio-ranges device tree property though, and in this case
    gpiochip_generic_config() would return -EPROPE_DEFER rather than the
    previous -ENOTSUPP return value. This in turn makes
    gpio_set_config_with_argument_optional() fail and propagate the error to
    any driver requesting GPIOs.
    
    Fixes: 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips")
    Reported-by: Jisheng Zhang <jszhang@kernel.org>
    Closes: https://lore.kernel.org/linux-gpio/ZdC_g3U4l0CJIWzh@xhacker/
    Tested-by: Jisheng Zhang <jszhang@kernel.org>
    Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
HID: logitech-hidpp: add support for Logitech G Pro X Superlight 2 [+ + +]
Author: Jiri Kosina <jikos@kernel.org>
Date:   Mon Jan 22 21:32:01 2024 +0100

    HID: logitech-hidpp: add support for Logitech G Pro X Superlight 2
    
    [ Upstream commit afa6ac2690bb9904ff883c6e942281e1032a484d ]
    
    Let logitech-hidpp driver claim Logitech G Pro X Superlight 2.
    
    Reported-by: Marcus Rückert <darix@opensu.se>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: nvidia-shield: Add missing null pointer checks to LED initialization [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Fri Jan 19 14:07:14 2024 +0800

    HID: nvidia-shield: Add missing null pointer checks to LED initialization
    
    [ Upstream commit b6eda11c44dc89a681e1c105f0f4660e69b1e183 ]
    
    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.
    
    [jkosina@suse.com: tweak changelog a bit]
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Signed-off-by: Jiri Kosina <jkosina@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>

hwmon: (nct6775) Fix access to temperature configuration registers [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed Feb 21 06:01:20 2024 -0800

    hwmon: (nct6775) Fix access to temperature configuration registers
    
    [ Upstream commit d56e460e19ea8382f813eb489730248ec8d7eb73 ]
    
    The number of temperature configuration registers does
    not always match the total number of temperature registers.
    This can result in access errors reported if KASAN is enabled.
    
    BUG: KASAN: global-out-of-bounds in nct6775_probe+0x5654/0x6fe9 nct6775_core
    
    Reported-by: Erhard Furtner <erhard_f@mailbox.org>
    Closes: https://lore.kernel.org/linux-hwmon/d51181d1-d26b-42b2-b002-3f5a4037721f@roeck-us.net/
    Fixes: b7f1f7b2523a ("hwmon: (nct6775) Additional TEMP registers for nct6799")
    Cc: Ahmad Khalifa <ahmad@khalifa.ws>
    Tested-by: Ahmad Khalifa <ahmad@khalifa.ws>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

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

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

 
IB/mlx5: Don't expose debugfs entries for RRoCE general parameters if not supported [+ + +]
Author: Mark Zhang <markzhang@nvidia.com>
Date:   Sun Jan 28 11:29:12 2024 +0200

    IB/mlx5: Don't expose debugfs entries for RRoCE general parameters if not supported
    
    [ Upstream commit 43fdbd140238d44e7e847232719fef7d20f9d326 ]
    
    debugfs entries for RRoCE general CC parameters must be exposed only when
    they are supported, otherwise when accessing them there may be a syndrome
    error in kernel log, for example:
    
    $ cat /sys/kernel/debug/mlx5/0000:08:00.1/cc_params/rtt_resp_dscp
    cat: '/sys/kernel/debug/mlx5/0000:08:00.1/cc_params/rtt_resp_dscp': Invalid argument
    $ dmesg
     mlx5_core 0000:08:00.1: mlx5_cmd_out_err:805:(pid 1253): QUERY_CONG_PARAMS(0x824) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x325a82), err(-22)
    
    Fixes: 66fb1d5df6ac ("IB/mlx5: Extend debug control for CC parameters")
    Reviewed-by: Edward Srouji <edwards@nvidia.com>
    Signed-off-by: Mark Zhang <markzhang@nvidia.com>
    Link: https://lore.kernel.org/r/e7ade70bad52b7468bdb1de4d41d5fad70c8b71c.1706433934.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: goodix - accept ACPI resources with gpio_count == 3 && gpio_int_idx == 0 [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Dec 23 15:16:50 2023 +0100

    Input: goodix - accept ACPI resources with gpio_count == 3 && gpio_int_idx == 0
    
    [ Upstream commit 180a8f12c21f41740fee09ca7f7aa98ff5bb99f8 ]
    
    Some devices list 3 Gpio resources in the ACPI resource list for
    the touchscreen:
    
    1. GpioInt resource pointing to the GPIO used for the interrupt
    2. GpioIo resource pointing to the reset GPIO
    3. GpioIo resource pointing to the GPIO used for the interrupt
    
    Note how the third extra GpioIo resource really is a duplicate
    of the GpioInt provided info.
    
    Ignore this extra GPIO, treating this setup the same as gpio_count == 2 &&
    gpio_int_idx == 0 fixes the touchscreen not working on the Thunderbook
    Colossus W803 rugged tablet and likely also on the CyberBook_T116K.
    
    Reported-by: Maarten van der Schrieck
    Closes: https://gitlab.com/AdyaAdya/goodix-touchscreen-linux-driver/-/issues/22
    Suggested-by: Maarten van der Schrieck
    Tested-by: Maarten van der Schrieck
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231223141650.10679-1-hdegoede@redhat.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

 
iommu/arm-smmu-v3: Do not use GFP_KERNEL under as spinlock [+ + +]
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Wed Feb 21 20:27:02 2024 -0400

    iommu/arm-smmu-v3: Do not use GFP_KERNEL under as spinlock
    
    [ Upstream commit b5bf7778b722105d7a04b1d51e884497b542638b ]
    
    If the SMMU is configured to use a two level CD table then
    arm_smmu_write_ctx_desc() allocates a CD table leaf internally using
    GFP_KERNEL. Due to recent changes this is being done under a spinlock to
    iterate over the device list - thus it will trigger a sleeping while
    atomic warning:
    
      arm_smmu_sva_set_dev_pasid()
        mutex_lock(&sva_lock);
        __arm_smmu_sva_bind()
         arm_smmu_mmu_notifier_get()
          spin_lock_irqsave()
          arm_smmu_write_ctx_desc()
            arm_smmu_get_cd_ptr()
             arm_smmu_alloc_cd_leaf_table()
              dmam_alloc_coherent(GFP_KERNEL)
    
    This is a 64K high order allocation and really should not be done
    atomically.
    
    At the moment the rework of the SVA to follow the new API is half
    finished. Recently the CD table memory was moved from the domain to the
    master, however we have the confusing situation where the SVA code is
    wrongly using the RID domains device's list to track which CD tables the
    SVA is installed in.
    
    Remove the logic to replicate the CD across all the domain's masters
    during attach. We know which master and which CD table the PASID should be
    installed in.
    
    Right now SVA only works when dma-iommu.c is in control of the RID
    translation, which means we have a single iommu_domain shared across the
    entire group and that iommu_domain is not shared outside the group.
    
    Critically this means that the iommu_group->devices list and RID's
    smmu_domain->devices list describe the same set of masters.
    
    For PCI cases the core code also insists on singleton groups so there is
    only one entry in the smmu_domain->devices list that is equal to the
    master being passed in to arm_smmu_sva_set_dev_pasid().
    
    Only non-PCI cases may have multi-device groups. However, the core code
    will repeat the calls to arm_smmu_sva_set_dev_pasid() across the entire
    iommu_group->devices list.
    
    Instead of having arm_smmu_mmu_notifier_get() indirectly loop over all the
    devices in the group via the RID's smmu_domain, rely on
    __arm_smmu_sva_bind() to be called for each device in the group and
    install the repeated CD entry that way.
    
    This avoids taking the spinlock to access the devices list and permits the
    arm_smmu_write_ctx_desc() to use a sleeping allocation. Leave the
    arm_smmu_mm_release() as a confusing situation, this requires tracking
    attached masters inside the SVA domain.
    
    Removing the loop allows arm_smmu_write_ctx_desc() to be called outside
    the spinlock and thus is safe to use GFP_KERNEL.
    
    Move the clearing of the CD into arm_smmu_sva_remove_dev_pasid() so that
    arm_smmu_mmu_notifier_get/put() remain paired functions.
    
    Fixes: 24503148c545 ("iommu/arm-smmu-v3: Refactor write_ctx_desc")
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/all/4e25d161-0cf8-4050-9aa3-dfa21cd63e56@moroto.mountain/
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Reviewed-by: Michael Shavit <mshavit@google.com>
    Link: https://lore.kernel.org/r/0-v3-11978fc67151+112-smmu_cd_atomic_jgg@nvidia.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/vt-d: Add missing dirty tracking set for parent domain [+ + +]
Author: Yi Liu <yi.l.liu@intel.com>
Date:   Mon Feb 19 19:15:59 2024 +0800

    iommu/vt-d: Add missing dirty tracking set for parent domain
    
    [ Upstream commit f1e1610950eac0af5e40f6ee02315952f78192f7 ]
    
    Setting dirty tracking for a s2 domain requires to loop all the related
    devices and set the dirty tracking enable bit in the PASID table entry.
    This includes the devices that are attached to the nested domains of a
    s2 domain if this s2 domain is used as parent. However, the existing dirty
    tracking set only loops s2 domain's own devices. It will miss dirty page
    logs in the parent domain.
    
    Now, the parent domain tracks the nested domains, so it can loop the
    nested domains and the devices attached to the nested domains to ensure
    dirty tracking on the parent is set completely.
    
    Fixes: b41e38e22539 ("iommu/vt-d: Add nested domain allocation")
    Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
    Signed-off-by: Yi Liu <yi.l.liu@intel.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Link: https://lore.kernel.org/r/20240208082307.15759-9-yi.l.liu@intel.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommu/vt-d: Remove domain parameter for intel_pasid_setup_dirty_tracking() [+ + +]
Author: Yi Liu <yi.l.liu@intel.com>
Date:   Mon Feb 19 19:15:57 2024 +0800

    iommu/vt-d: Remove domain parameter for intel_pasid_setup_dirty_tracking()
    
    [ Upstream commit 56ecaf6c5834ace14941d7f13dceb48bc3327111 ]
    
    The only usage of input @domain is to get the domain id (DID) to flush
    cache after setting dirty tracking. However, DID can be obtained from
    the pasid entry. So no need to pass in domain. This can make this helper
    cleaner when adding the missing dirty tracking for the parent domain,
    which needs to use the DID of nested domain.
    
    Signed-off-by: Yi Liu <yi.l.liu@intel.com>
    Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Link: https://lore.kernel.org/r/20240208082307.15759-7-yi.l.liu@intel.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Stable-dep-of: f1e1610950ea ("iommu/vt-d: Add missing dirty tracking set for parent domain")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommu/vt-d: Set SSADE when attaching to a parent with dirty tracking [+ + +]
Author: Yi Liu <yi.l.liu@intel.com>
Date:   Mon Feb 19 19:16:00 2024 +0800

    iommu/vt-d: Set SSADE when attaching to a parent with dirty tracking
    
    [ Upstream commit 1f0198fce68340e0da2d438f4ea9fc20d2c958da ]
    
    Should set the SSADE (Second Stage Access/Dirty bit Enable) bit of the
    pasid entry when attaching a device to a nested domain if its parent
    has already enabled dirty tracking.
    
    Fixes: 111bf85c68f6 ("iommu/vt-d: Add helper to setup pasid nested translation")
    Signed-off-by: Yi Liu <yi.l.liu@intel.com>
    Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
    Link: https://lore.kernel.org/r/20240208091414.28133-1-yi.l.liu@intel.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommu/vt-d: Track nested domains in parent [+ + +]
Author: Yi Liu <yi.l.liu@intel.com>
Date:   Mon Feb 19 19:15:52 2024 +0800

    iommu/vt-d: Track nested domains in parent
    
    [ Upstream commit 85ce8e1d6d73e8d54cb244d10dd4021771231746 ]
    
    Today the parent domain (s2_domain) is unaware of which DID's are
    used by and which devices are attached to nested domains (s1_domain)
    nested on it. This leads to a problem that some operations (flush
    iotlb/devtlb and enable dirty tracking) on parent domain only apply to
    DID's and devices directly tracked in the parent domain hence are
    incomplete.
    
    This tracks the nested domains in list in parent domain. With this,
    operations on parent domain can loop the nested domains and refer to
    the devices and iommu_array to ensure the operations on parent domain
    take effect on all the affected devices and iommus.
    
    Signed-off-by: Yi Liu <yi.l.liu@intel.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Link: https://lore.kernel.org/r/20240208082307.15759-2-yi.l.liu@intel.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Stable-dep-of: f1e1610950ea ("iommu/vt-d: Add missing dirty tracking set for parent domain")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommu/vt-d: Update iotlb in nested domain attach [+ + +]
Author: Yi Liu <yi.l.liu@intel.com>
Date:   Mon Feb 19 19:15:55 2024 +0800

    iommu/vt-d: Update iotlb in nested domain attach
    
    [ Upstream commit 29e10487d6df050afeee886b7c1da208f389cb5b ]
    
    Should call domain_update_iotlb() to update the has_iotlb_device flag
    of the domain after attaching device to nested domain. Without it, this
    flag is not set properly and would result in missing device TLB flush.
    
    Fixes: 9838f2bb6b6b ("iommu/vt-d: Set the nested domain to a device")
    Signed-off-by: Yi Liu <yi.l.liu@intel.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Link: https://lore.kernel.org/r/20240208082307.15759-5-yi.l.liu@intel.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommu/vt-d: Wrap the dirty tracking loop to be a helper [+ + +]
Author: Yi Liu <yi.l.liu@intel.com>
Date:   Mon Feb 19 19:15:58 2024 +0800

    iommu/vt-d: Wrap the dirty tracking loop to be a helper
    
    [ Upstream commit 0c7f2497b39da44253d7bcf2b41f52b0048859ad ]
    
    Add device_set_dirty_tracking() to loop all the devices and set the dirty
    tracking per the @enable parameter.
    
    Signed-off-by: Yi Liu <yi.l.liu@intel.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
    Link: https://lore.kernel.org/r/20240208082307.15759-8-yi.l.liu@intel.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Stable-dep-of: f1e1610950ea ("iommu/vt-d: Add missing dirty tracking set for parent domain")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu: Add mm_get_enqcmd_pasid() helper function [+ + +]
Author: Tina Zhang <tina.zhang@intel.com>
Date:   Fri Oct 27 08:05:22 2023 +0800

    iommu: Add mm_get_enqcmd_pasid() helper function
    
    [ Upstream commit 2396046d75d3c0b2cfead852a77efd023f8539dc ]
    
    mm_get_enqcmd_pasid() should be used by architecture code and closely
    related to learn the PASID value that the x86 ENQCMD operation should
    use for the mm.
    
    For the moment SMMUv3 uses this without any connection to ENQCMD, it
    will be cleaned up similar to how the prior patch made VT-d use the
    PASID argument of set_dev_pasid().
    
    The motivation is to replace mm->pasid with an iommu private data
    structure that is introduced in a later patch.
    
    Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Tested-by: Nicolin Chen <nicolinc@nvidia.com>
    Signed-off-by: Tina Zhang <tina.zhang@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Link: https://lore.kernel.org/r/20231027000525.1278806-4-tina.zhang@intel.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Stable-dep-of: b5bf7778b722 ("iommu/arm-smmu-v3: Do not use GFP_KERNEL under as spinlock")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommufd/iova_bitmap: Bounds check mapped::pages access [+ + +]
Author: Joao Martins <joao.m.martins@oracle.com>
Date:   Fri Feb 2 13:34:07 2024 +0000

    iommufd/iova_bitmap: Bounds check mapped::pages access
    
    [ Upstream commit a4ab7dedaee0e39b15653c5fd0367e420739f7ef ]
    
    Dirty IOMMU hugepages reported on a base page page-size granularity can
    lead to an attempt to set dirty pages in the bitmap beyond the limits that
    are pinned.
    
    Bounds check the page index of the array we are trying to access is within
    the limits before we kmap() and return otherwise.
    
    While it is also a defensive check, this is also in preparation to defer
    setting bits (outside the mapped range) to the next iteration(s) when the
    pages become available.
    
    Fixes: b058ea3ab5af ("vfio/iova_bitmap: refactor iova_bitmap_set() to better handle page boundaries")
    Link: https://lore.kernel.org/r/20240202133415.23819-2-joao.m.martins@oracle.com
    Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
    Tested-by: Avihai Horon <avihaih@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommufd/iova_bitmap: Consider page offset for the pages to be pinned [+ + +]
Author: Joao Martins <joao.m.martins@oracle.com>
Date:   Fri Feb 2 13:34:15 2024 +0000

    iommufd/iova_bitmap: Consider page offset for the pages to be pinned
    
    [ Upstream commit 4bbcbc6ea2fa379632a24c14cfb47aa603816ac6 ]
    
    For small bitmaps that aren't PAGE_SIZE aligned *and* that are less than
    512 pages in bitmap length, use an extra page to be able to cover the
    entire range e.g. [1M..3G] which would be iterated more efficiently in a
    single iteration, rather than two.
    
    Fixes: b058ea3ab5af ("vfio/iova_bitmap: refactor iova_bitmap_set() to better handle page boundaries")
    Link: https://lore.kernel.org/r/20240202133415.23819-10-joao.m.martins@oracle.com
    Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
    Tested-by: Avihai Horon <avihaih@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommufd/iova_bitmap: Handle recording beyond the mapped pages [+ + +]
Author: Joao Martins <joao.m.martins@oracle.com>
Date:   Fri Feb 2 13:34:10 2024 +0000

    iommufd/iova_bitmap: Handle recording beyond the mapped pages
    
    [ Upstream commit 2780025e01e2e1c92f83ee7da91d9727c2e58a3e ]
    
    IOVA bitmap is a zero-copy scheme of recording dirty bits that iterate the
    different bitmap user pages at chunks of a maximum of
    PAGE_SIZE/sizeof(struct page*) pages.
    
    When the iterations are split up into 64G, the end of the range may be
    broken up in a way that's aligned with a non base page PTE size. This
    leads to only part of the huge page being recorded in the bitmap. Note
    that in pratice this is only a problem for IOMMU dirty tracking i.e. when
    the backing PTEs are in IOMMU hugepages and the bitmap is in base page
    granularity. So far this not something that affects VF dirty trackers
    (which reports and records at the same granularity).
    
    To fix that, if there is a remainder of bits left to set in which the
    current IOVA bitmap doesn't cover, make a copy of the bitmap structure and
    iterate-and-set the rest of the bits remaining. Finally, when advancing
    the iterator, skip all the bits that were set ahead.
    
    Link: https://lore.kernel.org/r/20240202133415.23819-5-joao.m.martins@oracle.com
    Reported-by: Avihai Horon <avihaih@nvidia.com>
    Fixes: f35f22cc760e ("iommu/vt-d: Access/Dirty bit support for SS domains")
    Fixes: 421a511a293f ("iommu/amd: Access/Dirty bit support in IOPTEs")
    Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
    Tested-by: Avihai Horon <avihaih@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommufd/iova_bitmap: Switch iova_bitmap::bitmap to an u8 array [+ + +]
Author: Joao Martins <joao.m.martins@oracle.com>
Date:   Fri Feb 2 13:34:08 2024 +0000

    iommufd/iova_bitmap: Switch iova_bitmap::bitmap to an u8 array
    
    [ Upstream commit d18411ec305728c6371806c4fb09be07016aad0b ]
    
    iova_bitmap_mapped_length() don't deal correctly with the small bitmaps
    (< 2M bitmaps) when the starting address isn't u64 aligned, leading to
    skipping a tiny part of the IOVA range. This is materialized as not
    marking data dirty that should otherwise have been.
    
    Fix that by using a u8 * in the internal state of IOVA bitmap. Most of the
    data structures use the type of the bitmap to adjust its indexes, thus
    changing the type of the bitmap decreases the granularity of the bitmap
    indexes.
    
    Fixes: b058ea3ab5af ("vfio/iova_bitmap: refactor iova_bitmap_set() to better handle page boundaries")
    Link: https://lore.kernel.org/r/20240202133415.23819-3-joao.m.martins@oracle.com
    Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
    Tested-by: Avihai Horon <avihaih@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommufd: Reject non-zero data_type if no data_len is provided [+ + +]
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Tue Feb 20 14:43:54 2024 -0400

    iommufd: Reject non-zero data_type if no data_len is provided
    
    [ Upstream commit 7adc0c1cfa7732b81bf7bf2ed16ffb99719ceebf ]
    
    Since the current design doesn't forward the data_type to the driver to
    check unless there is a data_len/uptr for a driver specific struct we
    should check and ensure that data_type is 0 if data_len is 0. Otherwise
    any value is permitted.
    
    Fixes: bd529dbb661d ("iommufd: Add a nested HW pagetable object")
    Link: https://lore.kernel.org/r/0-v1-9b1ea6869554+110c60-iommufd_ck_data_type_jgg@nvidia.com
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.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/gic-v3-its: Do not assume vPE tables are preallocated [+ + +]
Author: Oliver Upton <oliver.upton@linux.dev>
Date:   Mon Feb 19 18:58:06 2024 +0000

    irqchip/gic-v3-its: Do not assume vPE tables are preallocated
    
    commit ec4308ecfc887128a468f03fb66b767559c57c23 upstream.
    
    The GIC/ITS code is designed to ensure to pick up any preallocated LPI
    tables on the redistributors, as enabling LPIs is a one-way switch. There
    is no such restriction for vLPIs, and for GICv4.1 it is expected to
    allocate a new vPE table at boot.
    
    This works as intended when initializing an ITS, however when setting up a
    redistributor in cpu_init_lpis() the early return for preallocated RD
    tables skips straight past the GICv4 setup. This all comes to a head when
    trying to kexec() into a new kernel, as the new kernel silently fails to
    set up GICv4, leading to a complete loss of SGIs and LPIs for KVM VMs.
    
    Slap a band-aid on the problem by ensuring its_cpu_init_lpis() always
    initializes GICv4 on the way out, even if the other RD tables were
    preallocated.
    
    Fixes: 6479450f72c1 ("irqchip/gic-v4: Fix occasional VLPI drop")
    Reported-by: George Cherian <gcherian@marvell.com>
    Co-developed-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240219185809.286724-2-oliver.upton@linux.dev
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
irqchip/mbigen: Don't use bus_get_dev_root() to find the parent [+ + +]
Author: Chen Jun <chenjun102@huawei.com>
Date:   Tue Feb 20 19:14:29 2024 +0800

    irqchip/mbigen: Don't use bus_get_dev_root() to find the parent
    
    commit fb33a46cd75e18773dd5a414744507d84ae90870 upstream.
    
    bus_get_dev_root() returns sp->dev_root which is set in subsys_register(),
    but subsys_register() is not called by platform_bus_init().
    
    Therefor for the platform_bus_type, bus_get_dev_root() always returns NULL.
    This makes mbigen_of_create_domain() always return -ENODEV.
    
    Don't try to retrieve the parent via bus_get_dev_root() and
    unconditionally hand a NULL pointer to of_platform_device_create() to
    fix this.
    
    Fixes: fea087fc291b ("irqchip/mbigen: move to use bus_get_dev_root()")
    Signed-off-by: Chen Jun <chenjun102@huawei.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240220111429.110666-1-chenjun102@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
irqchip/sifive-plic: Enable interrupt if needed before EOI [+ + +]
Author: Nam Cao <namcao@linutronix.de>
Date:   Wed Jan 31 09:19:33 2024 +0100

    irqchip/sifive-plic: Enable interrupt if needed before EOI
    
    commit 9c92006b896c767218aabe8947b62026a571cfd0 upstream.
    
    RISC-V PLIC cannot "end-of-interrupt" (EOI) disabled interrupts, as
    explained in the description of Interrupt Completion in the PLIC spec:
    
    "The PLIC signals it has completed executing an interrupt handler by
    writing the interrupt ID it received from the claim to the claim/complete
    register. The PLIC does not check whether the completion ID is the same
    as the last claim ID for that target. If the completion ID does not match
    an interrupt source that *is currently enabled* for the target, the
    completion is silently ignored."
    
    Commit 69ea463021be ("irqchip/sifive-plic: Fixup EOI failed when masked")
    ensured that EOI is successful by enabling interrupt first, before EOI.
    
    Commit a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask
    operations") removed the interrupt enabling code from the previous
    commit, because it assumes that interrupt should already be enabled at the
    point of EOI.
    
    However, this is incorrect: there is a window after a hart claiming an
    interrupt and before irq_desc->lock getting acquired, interrupt can be
    disabled during this window. Thus, EOI can be invoked while the interrupt
    is disabled, effectively nullify this EOI. This results in the interrupt
    never gets asserted again, and the device who uses this interrupt appears
    frozen.
    
    Make sure that interrupt is really enabled before EOI.
    
    Fixes: a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask operations")
    Signed-off-by: Nam Cao <namcao@linutronix.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Palmer Dabbelt <palmer@dabbelt.com>
    Cc: Paul Walmsley <paul.walmsley@sifive.com>
    Cc: Samuel Holland <samuel@sholland.org>
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: Guo Ren <guoren@kernel.org>
    Cc: linux-riscv@lists.infradead.org
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240131081933.144512-1-namcao@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kunit: Add a macro to wrap a deferred action function [+ + +]
Author: David Gow <davidgow@google.com>
Date:   Tue Nov 28 15:24:05 2023 +0800

    kunit: Add a macro to wrap a deferred action function
    
    commit 56778b49c9a2cbc32c6b0fbd3ba1a9d64192d3af upstream.
    
    KUnit's deferred action API accepts a void(*)(void *) function pointer
    which is called when the test is exited. However, we very frequently
    want to use existing functions which accept a single pointer, but which
    may not be of type void*. While this is probably dodgy enough to be on
    the wrong side of the C standard, it's been often used for similar
    callbacks, and gcc's -Wcast-function-type seems to ignore cases where
    the only difference is the type of the argument, assuming it's
    compatible (i.e., they're both pointers to data).
    
    However, clang 16 has introduced -Wcast-function-type-strict, which no
    longer permits any deviation in function pointer type. This seems to be
    because it'd break CFI, which validates the type of function calls.
    
    This rather ruins our attempts to cast functions to defer them, and
    leaves us with a few options. The one we've chosen is to implement a
    macro which will generate a wrapper function which accepts a void*, and
    casts the argument to the appropriate type.
    
    For example, if you were trying to wrap:
    void foo_close(struct foo *handle);
    you could use:
    KUNIT_DEFINE_ACTION_WRAPPER(kunit_action_foo_close,
                                foo_close,
                                struct foo *);
    
    This would create a new kunit_action_foo_close() function, of type
    kunit_action_t, which could be passed into kunit_add_action() and
    similar functions.
    
    In addition to defining this macro, update KUnit and its tests to use
    it.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1750
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Acked-by: Daniel Vetter <daniel@ffwll.ch>
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: David Gow <davidgow@google.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

KVM: PPC: Book3S HV: Fix L2 guest reboot failure due to empty 'arch_compat' [+ + +]
Author: Amit Machhiwal <amachhiw@linux.ibm.com>
Date:   Wed Feb 7 11:15:26 2024 +0530

    KVM: PPC: Book3S HV: Fix L2 guest reboot failure due to empty 'arch_compat'
    
    [ Upstream commit 20c8c4dafe93e82441583e93bd68c0d256d7bed4 ]
    
    Currently, rebooting a pseries nested qemu-kvm guest (L2) results in
    below error as L1 qemu sends PVR value 'arch_compat' == 0 via
    ppc_set_compat ioctl. This triggers a condition failure in
    kvmppc_set_arch_compat() resulting in an EINVAL.
    
    qemu-system-ppc64: Unable to set CPU compatibility mode in KVM: Invalid
    argument
    
    Also, a value of 0 for arch_compat generally refers the default
    compatibility of the host. But, arch_compat, being a Guest Wide Element
    in nested API v2, cannot be set to 0 in GSB as PowerVM (L0) expects a
    non-zero value. A value of 0 triggers a kernel trap during a reboot and
    consequently causes it to fail:
    
    [   22.106360] reboot: Restarting system
    KVM: unknown exit, hardware reason ffffffffffffffea
    NIP 0000000000000100   LR 000000000000fe44 CTR 0000000000000000 XER 0000000020040092 CPU#0
    MSR 0000000000001000 HID0 0000000000000000  HF 6c000000 iidx 3 didx 3
    TB 00000000 00000000 DECR 0
    GPR00 0000000000000000 0000000000000000 c000000002a8c300 000000007fe00000
    GPR04 0000000000000000 0000000000000000 0000000000001002 8000000002803033
    GPR08 000000000a000000 0000000000000000 0000000000000004 000000002fff0000
    GPR12 0000000000000000 c000000002e10000 0000000105639200 0000000000000004
    GPR16 0000000000000000 000000010563a090 0000000000000000 0000000000000000
    GPR20 0000000105639e20 00000001056399c8 00007fffe54abab0 0000000105639288
    GPR24 0000000000000000 0000000000000001 0000000000000001 0000000000000000
    GPR28 0000000000000000 0000000000000000 c000000002b30840 0000000000000000
    CR 00000000  [ -  -  -  -  -  -  -  -  ]     RES 000@ffffffffffffffff
     SRR0 0000000000000000  SRR1 0000000000000000    PVR 0000000000800200 VRSAVE 0000000000000000
    SPRG0 0000000000000000 SPRG1 0000000000000000  SPRG2 0000000000000000  SPRG3 0000000000000000
    SPRG4 0000000000000000 SPRG5 0000000000000000  SPRG6 0000000000000000  SPRG7 0000000000000000
    HSRR0 0000000000000000 HSRR1 0000000000000000
     CFAR 0000000000000000
     LPCR 0000000000020400
     PTCR 0000000000000000   DAR 0000000000000000  DSISR 0000000000000000
    
     kernel:trap=0xffffffea | pc=0x100 | msr=0x1000
    
    This patch updates kvmppc_set_arch_compat() to use the host PVR value if
    'compat_pvr' == 0 indicating that qemu doesn't want to enforce any
    specific PVR compat mode.
    
    The relevant part of the code might need a rework if PowerVM implements
    a support for `arch_compat == 0` in nestedv2 API.
    
    Fixes: 19d31c5f1157 ("KVM: PPC: Add support for nestedv2 guests")
    Reviewed-by: "Aneesh Kumar K.V (IBM)" <aneesh.kumar@kernel.org>
    Reviewed-by: Vaibhav Jain <vaibhav@linux.ibm.com>
    Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240207054526.3720087-1-amachhiw@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
lib/Kconfig.debug: TEST_IOV_ITER depends on MMU [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu Feb 8 07:30:10 2024 -0800

    lib/Kconfig.debug: TEST_IOV_ITER depends on MMU
    
    commit 1eb1e984379e2da04361763f66eec90dd75cf63e upstream.
    
    Trying to run the iov_iter unit test on a nommu system such as the qemu
    kc705-nommu emulation results in a crash.
    
        KTAP version 1
        # Subtest: iov_iter
        # module: kunit_iov_iter
        1..9
    BUG: failure at mm/nommu.c:318/vmap()!
    Kernel panic - not syncing: BUG!
    
    The test calls vmap() directly, but vmap() is not supported on nommu
    systems, causing the crash.  TEST_IOV_ITER therefore needs to depend on
    MMU.
    
    Link: https://lkml.kernel.org/r/20240208153010.1439753-1-linux@roeck-us.net
    Fixes: 2d71340ff1d4 ("iov_iter: Kunit tests for copying to/from an iterator")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Cc: David Howells <dhowells@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
libceph: fail sparse-read if the data length doesn't match [+ + +]
Author: Xiubo Li <xiubli@redhat.com>
Date:   Fri Oct 13 13:55:44 2023 +0800

    libceph: fail sparse-read if the data length doesn't match
    
    [ Upstream commit cd7d469c25704d414d71bf3644f163fb74e7996b ]
    
    Once this happens that means there have bugs.
    
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

    Linux 6.7.7
    
    Link: https://lore.kernel.org/r/20240227131630.636392135@linuxfoundation.org
    Tested-by: Luna Jernberg <droidbittin@gmail.com>
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Conor Dooley <conor.dooley@microchip.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Ricardo B. Marliere <ricardo@marliere.net>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
LoongArch: Call early_init_fdt_scan_reserved_mem() earlier [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Fri Feb 23 14:36:31 2024 +0800

    LoongArch: Call early_init_fdt_scan_reserved_mem() earlier
    
    commit 9fa304b9f8ec440e614af6d35826110c633c4074 upstream.
    
    The unflatten_and_copy_device_tree() function contains a call to
    memblock_alloc(). This means that memblock is allocating memory before
    any of the reserved memory regions are set aside in the arch_mem_init()
    function which calls early_init_fdt_scan_reserved_mem(). Therefore,
    there is a possibility for memblock to allocate from any of the
    reserved memory regions.
    
    Hence, move the call to early_init_fdt_scan_reserved_mem() to be earlier
    in the init sequence, so that the reserved memory regions are set aside
    before any allocations are done using memblock.
    
    Cc: stable@vger.kernel.org
    Fixes: 88d4d957edc707e ("LoongArch: Add FDT booting support from efi system table")
    Signed-off-by: Oreoluwa Babatunde <quic_obabatun@quicinc.com>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC] [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Tue Feb 6 12:32:05 2024 +0800

    LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]
    
    [ Upstream commit 4551b30525cf3d2f026b92401ffe241eb04dfebe ]
    
    With default config, the value of NR_CPUS is 64. When HW platform has
    more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC
    is the maximum cpu number in MADT table (max physical number) which can
    exceed the supported maximum cpu number (NR_CPUS, max logical number),
    but kernel should not crash. Kernel should boot cpus with NR_CPUS, let
    the remainder cpus stay in BIOS.
    
    The potential crash reason is that the array acpi_core_pic[NR_CPUS] can
    be overflowed when parsing MADT table, and it is obvious that CORE_PIC
    should be corresponding to physical core rather than logical core, so it
    is better to define the array as acpi_core_pic[MAX_CORE_PIC].
    
    With the patch, system can boot up 64 vcpus with qemu parameter -smp 128,
    otherwise system will crash with the following message.
    
    [    0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000420000004259, era == 90000000037a5f0c, ra == 90000000037a46ec
    [    0.000000] Oops[#1]:
    [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.8.0-rc2+ #192
    [    0.000000] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
    [    0.000000] pc 90000000037a5f0c ra 90000000037a46ec tp 9000000003c90000 sp 9000000003c93d60
    [    0.000000] a0 0000000000000019 a1 9000000003d93bc0 a2 0000000000000000 a3 9000000003c93bd8
    [    0.000000] a4 9000000003c93a74 a5 9000000083c93a67 a6 9000000003c938f0 a7 0000000000000005
    [    0.000000] t0 0000420000004201 t1 0000000000000000 t2 0000000000000001 t3 0000000000000001
    [    0.000000] t4 0000000000000003 t5 0000000000000000 t6 0000000000000030 t7 0000000000000063
    [    0.000000] t8 0000000000000014 u0 ffffffffffffffff s9 0000000000000000 s0 9000000003caee98
    [    0.000000] s1 90000000041b0480 s2 9000000003c93da0 s3 9000000003c93d98 s4 9000000003c93d90
    [    0.000000] s5 9000000003caa000 s6 000000000a7fd000 s7 000000000f556b60 s8 000000000e0a4330
    [    0.000000]    ra: 90000000037a46ec platform_init+0x214/0x250
    [    0.000000]   ERA: 90000000037a5f0c efi_runtime_init+0x30/0x94
    [    0.000000]  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
    [    0.000000]  PRMD: 00000000 (PPLV0 -PIE -PWE)
    [    0.000000]  EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
    [    0.000000]  ECFG: 00070800 (LIE=11 VS=7)
    [    0.000000] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
    [    0.000000]  BADV: 0000420000004259
    [    0.000000]  PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
    [    0.000000] Modules linked in:
    [    0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____))
    [    0.000000] Stack : 9000000003c93a14 9000000003800898 90000000041844f8 90000000037a46ec
    [    0.000000]         000000000a7fd000 0000000008290000 0000000000000000 0000000000000000
    [    0.000000]         0000000000000000 0000000000000000 00000000019d8000 000000000f556b60
    [    0.000000]         000000000a7fd000 000000000f556b08 9000000003ca7700 9000000003800000
    [    0.000000]         9000000003c93e50 9000000003800898 9000000003800108 90000000037a484c
    [    0.000000]         000000000e0a4330 000000000f556b60 000000000a7fd000 000000000f556b08
    [    0.000000]         9000000003ca7700 9000000004184000 0000000000200000 000000000e02b018
    [    0.000000]         000000000a7fd000 90000000037a0790 9000000003800108 0000000000000000
    [    0.000000]         0000000000000000 000000000e0a4330 000000000f556b60 000000000a7fd000
    [    0.000000]         000000000f556b08 000000000eaae298 000000000eaa5040 0000000000200000
    [    0.000000]         ...
    [    0.000000] Call Trace:
    [    0.000000] [<90000000037a5f0c>] efi_runtime_init+0x30/0x94
    [    0.000000] [<90000000037a46ec>] platform_init+0x214/0x250
    [    0.000000] [<90000000037a484c>] setup_arch+0x124/0x45c
    [    0.000000] [<90000000037a0790>] start_kernel+0x90/0x670
    [    0.000000] [<900000000378b0d8>] kernel_entry+0xd8/0xdc
    
    Signed-off-by: Bibo Mao <maobibo@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

LoongArch: Disable IRQ before init_fn() for nonboot CPUs [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Fri Feb 23 14:36:31 2024 +0800

    LoongArch: Disable IRQ before init_fn() for nonboot CPUs
    
    commit 1001db6c42e4012b55e5ee19405490f23e033b5a upstream.
    
    Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to
    silence such warnings (and also avoid potential errors due to unexpected
    interrupts):
    
    WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198
    pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0
    a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000
    a4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c
    t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e
    t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000
    t8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001
    s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001
    s5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8
       ra: 90000000047bd56c tlb_init+0x24c/0x528
      ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280
     CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
     PRMD: 00000000 (PPLV0 -PIE -PWE)
     EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
     ECFG: 00071000 (LIE=12 VS=7)
    ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)
     PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198
    Stack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000
            900000010039fa30 0000000000000000 900000010039fa38 900000000619a140
            9000000006456888 9000000006456880 900000010039f950 0000000000000001
            0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700
            0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003
            0000000000040000 9000000007930370 0000000002b90000 0000000000000004
            9000000006366000 900000000619a140 0000000000000000 0000000000000004
            0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940
            9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8
            00000000000000b0 0000000000000000 0000000000000000 0000000000071000
            ...
    Call Trace:
    [<90000000047a4828>] show_stack+0x48/0x1a0
    [<9000000005b61874>] dump_stack_lvl+0x84/0xcc
    [<90000000047f60ac>] __warn+0x8c/0x1e0
    [<9000000005b0ab34>] report_bug+0x1b4/0x280
    [<9000000005b63110>] do_bp+0x2d0/0x480
    [<90000000047a2e20>] handle_bp+0x120/0x1c0
    [<90000000048e3334>] rcu_cpu_starting+0x214/0x280
    [<90000000047bd568>] tlb_init+0x248/0x528
    [<90000000047a4c44>] per_cpu_trap_init+0x124/0x160
    [<90000000047a19f4>] cpu_probe+0x494/0xa00
    [<90000000047b551c>] start_secondary+0x3c/0xc0
    [<9000000005b66134>] smpboot_entry+0x50/0x58
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

LoongArch: Select ARCH_ENABLE_THP_MIGRATION instead of redefining it [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue Feb 6 12:32:05 2024 +0800

    LoongArch: Select ARCH_ENABLE_THP_MIGRATION instead of redefining it
    
    [ Upstream commit b3ff2d9c3a9c64cd0a011cdd407ffc38a6ea8788 ]
    
    ARCH_ENABLE_THP_MIGRATION is supposed to be selected by arch Kconfig.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

LoongArch: Select HAVE_ARCH_SECCOMP to use the common SECCOMP menu [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue Feb 6 12:32:05 2024 +0800

    LoongArch: Select HAVE_ARCH_SECCOMP to use the common SECCOMP menu
    
    [ Upstream commit 6b79ecd084c99b31c8b4d0beda08893716d5558e ]
    
    LoongArch missed the refactoring made by commit 282a181b1a0d ("seccomp:
    Move config option SECCOMP to arch/Kconfig") because LoongArch was not
    mainlined at that time.
    
    The 'depends on PROC_FS' statement is stale as described in that commit.
    Select HAVE_ARCH_SECCOMP, and remove the duplicated config entry.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

LoongArch: Update cpu_sibling_map when disabling nonboot CPUs [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Fri Feb 23 14:36:31 2024 +0800

    LoongArch: Update cpu_sibling_map when disabling nonboot CPUs
    
    commit 752cd08da320a667a833803a8fd6bb266114cce5 upstream.
    
    Update cpu_sibling_map when disabling nonboot CPUs by defining & calling
    clear_cpu_sibling_map(), otherwise we get such errors on SMT systems:
    
    jump label: negative count!
    WARNING: CPU: 6 PID: 45 at kernel/jump_label.c:263 __static_key_slow_dec_cpuslocked+0xec/0x100
    CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340
    pc 90000000004c302c ra 90000000004c302c tp 90000001005bc000 sp 90000001005bfd20
    a0 000000000000001b a1 900000000224c278 a2 90000001005bfb58 a3 900000000224c280
    a4 900000000224c278 a5 90000001005bfb50 a6 0000000000000001 a7 0000000000000001
    t0 ce87a4763eb5234a t1 ce87a4763eb5234a t2 0000000000000000 t3 0000000000000000
    t4 0000000000000006 t5 0000000000000000 t6 0000000000000064 t7 0000000000001964
    t8 000000000009ebf6 u0 9000000001f2a068 s9 0000000000000000 s0 900000000246a2d8
    s1 ffffffffffffffff s2 ffffffffffffffff s3 90000000021518c0 s4 0000000000000040
    s5 9000000002151058 s6 9000000009828e40 s7 00000000000000b4 s8 0000000000000006
       ra: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100
      ERA: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100
     CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
     PRMD: 00000004 (PPLV0 +PIE -PWE)
     EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
     ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
    ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)
     PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV)
    CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340
    Stack : 0000000000000000 900000000203f258 900000000179afc8 90000001005bc000
            90000001005bf980 0000000000000000 90000001005bf988 9000000001fe0be0
            900000000224c280 900000000224c278 90000001005bf8c0 0000000000000001
            0000000000000001 ce87a4763eb5234a 0000000007f38000 90000001003f8cc0
            0000000000000000 0000000000000006 0000000000000000 4c206e6f73676e6f
            6f4c203a656d616e 000000000009ec99 0000000007f38000 0000000000000000
            900000000214b000 9000000001fe0be0 0000000000000004 0000000000000000
            0000000000000107 0000000000000009 ffffffffffafdabe 00000000000000b4
            0000000000000006 90000000004c302c 9000000000224528 00005555939a0c7c
            00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
            ...
    Call Trace:
    [<9000000000224528>] show_stack+0x48/0x1a0
    [<900000000179afc8>] dump_stack_lvl+0x78/0xa0
    [<9000000000263ed0>] __warn+0x90/0x1a0
    [<90000000017419b8>] report_bug+0x1b8/0x280
    [<900000000179c564>] do_bp+0x264/0x420
    [<90000000004c302c>] __static_key_slow_dec_cpuslocked+0xec/0x100
    [<90000000002b4d7c>] sched_cpu_deactivate+0x2fc/0x300
    [<9000000000266498>] cpuhp_invoke_callback+0x178/0x8a0
    [<9000000000267f70>] cpuhp_thread_fun+0xf0/0x240
    [<90000000002a117c>] smpboot_thread_fn+0x1dc/0x2e0
    [<900000000029a720>] kthread+0x140/0x160
    [<9000000000222288>] ret_from_kernel_thread+0xc/0xa4
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

LoongArch: vDSO: Disable UBSAN instrumentation [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Feb 6 12:32:05 2024 +0800

    LoongArch: vDSO: Disable UBSAN instrumentation
    
    [ Upstream commit cca5efe77a6a2d02b3da4960f799fa233e460ab1 ]
    
    The vDSO executes in userspace, so the kernel's UBSAN should not
    instrument it. Solves these kind of build errors:
    
      loongarch64-linux-ld: arch/loongarch/vdso/vgettimeofday.o: in function `vdso_shift_ns':
      lib/vdso/gettimeofday.c:23:(.text+0x3f8): undefined reference to `__ubsan_handle_shift_out_of_bounds'
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202401310530.lZHCj1Zl-lkp@intel.com/
    Cc: Huacai Chen <chenhuacai@kernel.org>
    Cc: WANG Xuerui <kernel@xen0n.name>
    Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Masahiro Yamada <masahiroy@kernel.org>
    Cc: Fangrui Song <maskray@google.com>
    Cc: loongarch@lists.linux.dev
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md: Don't ignore read-only array in md_check_recovery() [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu Feb 1 17:25:47 2024 +0800

    md: Don't ignore read-only array in md_check_recovery()
    
    commit 55a48ad2db64737f7ffc0407634218cc6e4c513b upstream.
    
    Usually if the array is not read-write, md_check_recovery() won't
    register new sync_thread in the first place. And if the array is
    read-write and sync_thread is registered, md_set_readonly() will
    unregister sync_thread before setting the array read-only. md/raid
    follow this behavior hence there is no problem.
    
    After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
    hang can be triggered by test shell/integrity-caching.sh:
    
    1) array is read-only. dm-raid update super block:
    rs_update_sbs
     ro = mddev->ro
     mddev->ro = 0
      -> set array read-write
     md_update_sb
    
    2) register new sync thread concurrently.
    
    3) dm-raid set array back to read-only:
    rs_update_sbs
     mddev->ro = ro
    
    4) stop the array:
    raid_dtr
     md_stop
      stop_sync_thread
        set_bit(MD_RECOVERY_INTR, &mddev->recovery);
        md_wakeup_thread_directly(mddev->sync_thread);
        wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))
    
    5) sync thread done:
     md_do_sync
     set_bit(MD_RECOVERY_DONE, &mddev->recovery);
     md_wakeup_thread(mddev->thread);
    
    6) daemon thread can't unregister sync thread:
     md_check_recovery
      if (!md_is_rdwr(mddev) &&
          !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery))
       return;
      -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;
    
    The root cause is that dm-raid manipulate 'mddev->ro' by itself,
    however, dm-raid really should stop sync thread before setting the
    array read-only. Unfortunately, I need to read more code before I
    can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix
    the problem the easy way for now to prevent dm-raid regression.
    
    Reported-by: Mikulas Patocka <mpatocka@redhat.com>
    Closes: https://lore.kernel.org/all/9801e40-8ac7-e225-6a71-309dcf9dc9aa@redhat.com/
    Fixes: ecbfb9f118bc ("dm raid: add raid level takeover support")
    Fixes: f52f5c71f3d4 ("md: fix stopping sync thread")
    Cc: stable@vger.kernel.org # v6.7+
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240201092559.910982-3-yukuai1@huaweicloud.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

md: Don't ignore suspended array in md_check_recovery() [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu Feb 1 17:25:46 2024 +0800

    md: Don't ignore suspended array in md_check_recovery()
    
    commit 1baae052cccd08daf9a9d64c3f959d8cdb689757 upstream.
    
    mddev_suspend() never stop sync_thread, hence it doesn't make sense to
    ignore suspended array in md_check_recovery(), which might cause
    sync_thread can't be unregistered.
    
    After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
    hang can be triggered by test shell/integrity-caching.sh:
    
    1) suspend the array:
    raid_postsuspend
     mddev_suspend
    
    2) stop the array:
    raid_dtr
     md_stop
      __md_stop_writes
       stop_sync_thread
        set_bit(MD_RECOVERY_INTR, &mddev->recovery);
        md_wakeup_thread_directly(mddev->sync_thread);
        wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))
    
    3) sync thread done:
    md_do_sync
     set_bit(MD_RECOVERY_DONE, &mddev->recovery);
     md_wakeup_thread(mddev->thread);
    
    4) daemon thread can't unregister sync thread:
    md_check_recovery
     if (mddev->suspended)
       return; -> return directly
     md_read_sync_thread
     clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
     -> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang;
    
    This problem is not just related to dm-raid, fix it by ignoring
    suspended array in md_check_recovery(). And follow up patches will
    improve dm-raid better to frozen sync thread during suspend.
    
    Reported-by: Mikulas Patocka <mpatocka@redhat.com>
    Closes: https://lore.kernel.org/all/8fb335e-6d2c-dbb5-d7-ded8db5145a@redhat.com/
    Fixes: 68866e425be2 ("MD: no sync IO while suspended")
    Fixes: f52f5c71f3d4 ("md: fix stopping sync thread")
    Cc: stable@vger.kernel.org # v6.7+
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240201092559.910982-2-yukuai1@huaweicloud.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

md: Don't register sync_thread for reshape directly [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu Feb 1 17:25:49 2024 +0800

    md: Don't register sync_thread for reshape directly
    
    commit ad39c08186f8a0f221337985036ba86731d6aafe upstream.
    
    Currently, if reshape is interrupted, then reassemble the array will
    register sync_thread directly from pers->run(), in this case
    'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee
    that md_do_sync() will be executed, hence stop_sync_thread() will hang
    because 'MD_RECOVERY_RUNNING' can't be cleared.
    
    Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE,
    however, following hang can still be triggered by dm-raid test
    shell/lvconvert-raid-reshape.sh occasionally:
    
    [root@fedora ~]# cat /proc/1982/stack
    [<0>] stop_sync_thread+0x1ab/0x270 [md_mod]
    [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod]
    [<0>] raid_presuspend+0x1e/0x70 [dm_raid]
    [<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod]
    [<0>] __dm_destroy+0x2a5/0x310 [dm_mod]
    [<0>] dm_destroy+0x16/0x30 [dm_mod]
    [<0>] dev_remove+0x165/0x290 [dm_mod]
    [<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod]
    [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod]
    [<0>] vfs_ioctl+0x21/0x60
    [<0>] __x64_sys_ioctl+0xb9/0xe0
    [<0>] do_syscall_64+0xc6/0x230
    [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
    
    Meanwhile mddev->recovery is:
    MD_RECOVERY_RUNNING |
    MD_RECOVERY_INTR |
    MD_RECOVERY_RESHAPE |
    MD_RECOVERY_FROZEN
    
    Fix this problem by remove the code to register sync_thread directly
    from raid10 and raid5. And let md_check_recovery() to register
    sync_thread.
    
    Fixes: f67055780caa ("[PATCH] md: Checkpoint and allow restart of raid5 reshape")
    Fixes: f52f5c71f3d4 ("md: fix stopping sync thread")
    Cc: stable@vger.kernel.org # v6.7+
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240201092559.910982-5-yukuai1@huaweicloud.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

md: Don't suspend the array for interrupted reshape [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu Feb 1 17:25:50 2024 +0800

    md: Don't suspend the array for interrupted reshape
    
    commit 9e46c70e829bddc24e04f963471e9983a11598b7 upstream.
    
    md_start_sync() will suspend the array if there are spares that can be
    added or removed from conf, however, if reshape is still in progress,
    this won't happen at all or data will be corrupted(remove_and_add_spares
    won't be called from md_choose_sync_action for reshape), hence there is
    no need to suspend the array if reshape is not done yet.
    
    Meanwhile, there is a potential deadlock for raid456:
    
    1) reshape is interrupted;
    
    2) set one of the disk WantReplacement, and add a new disk to the array,
       however, recovery won't start until the reshape is finished;
    
    3) then issue an IO across reshpae position, this IO will wait for
       reshape to make progress;
    
    4) continue to reshape, then md_start_sync() found there is a spare disk
       that can be added to conf, mddev_suspend() is called;
    
    Step 4 and step 3 is waiting for each other, deadlock triggered. Noted
    this problem is found by code review, and it's not reporduced yet.
    
    Fix this porblem by don't suspend the array for interrupted reshape,
    this is safe because conf won't be changed until reshape is done.
    
    Fixes: bc08041b32ab ("md: suspend array in md_start_sync() if array need reconfiguration")
    Cc: stable@vger.kernel.org # v6.7+
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240201092559.910982-6-yukuai1@huaweicloud.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

md: Fix missing release of 'active_io' for flush [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu Feb 1 17:25:51 2024 +0800

    md: Fix missing release of 'active_io' for flush
    
    commit 855678ed8534518e2b428bcbcec695de9ba248e8 upstream.
    
    submit_flushes
     atomic_set(&mddev->flush_pending, 1);
     rdev_for_each_rcu(rdev, mddev)
      atomic_inc(&mddev->flush_pending);
      bi->bi_end_io = md_end_flush
      submit_bio(bi);
                            /* flush io is done first */
                            md_end_flush
                             if (atomic_dec_and_test(&mddev->flush_pending))
                              percpu_ref_put(&mddev->active_io)
                              -> active_io is not released
    
     if (atomic_dec_and_test(&mddev->flush_pending))
      -> missing release of active_io
    
    For consequence, mddev_suspend() will wait for 'active_io' to be zero
    forever.
    
    Fix this problem by releasing 'active_io' in submit_flushes() if
    'flush_pending' is decreased to zero.
    
    Fixes: fa2bbff7b0b4 ("md: synchronize flush io with array reconfiguration")
    Cc: stable@vger.kernel.org # v6.1+
    Reported-by: Blazej Kucman <blazej.kucman@linux.intel.com>
    Closes: https://lore.kernel.org/lkml/20240130172524.0000417b@linux.intel.com/
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240201092559.910982-7-yukuai1@huaweicloud.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

md: Make sure md_do_sync() will set MD_RECOVERY_DONE [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu Feb 1 17:25:48 2024 +0800

    md: Make sure md_do_sync() will set MD_RECOVERY_DONE
    
    commit 82ec0ae59d02e89164b24c0cc8e4e50de78b5fd6 upstream.
    
    stop_sync_thread() will interrupt md_do_sync(), and md_do_sync() must
    set MD_RECOVERY_DONE, so that follow up md_check_recovery() will
    unregister sync_thread, clear MD_RECOVERY_RUNNING and wake up
    stop_sync_thread().
    
    If MD_RECOVERY_WAIT is set or the array is read-only, md_do_sync() will
    return without setting MD_RECOVERY_DONE, and after commit f52f5c71f3d4
    ("md: fix stopping sync thread"), dm-raid switch from
    md_reap_sync_thread() to stop_sync_thread() to unregister sync_thread
    from md_stop() and md_stop_writes(), causing the test
    shell/lvconvert-raid-reshape.sh hang.
    
    We shouldn't switch back to md_reap_sync_thread() because it's
    problematic in the first place. Fix the problem by making sure
    md_do_sync() will set MD_RECOVERY_DONE.
    
    Reported-by: Mikulas Patocka <mpatocka@redhat.com>
    Closes: https://lore.kernel.org/all/ece2b06f-d647-6613-a534-ff4c9bec1142@redhat.com/
    Fixes: d5d885fd514f ("md: introduce new personality funciton start()")
    Fixes: 5fd6c1dce06e ("[PATCH] md: allow checkpoint of recovery with version-1 superblock")
    Fixes: f52f5c71f3d4 ("md: fix stopping sync thread")
    Cc: stable@vger.kernel.org # v6.7+
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240201092559.910982-4-yukuai1@huaweicloud.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

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

 
misc: open-dice: Fix spurious lockdep warning [+ + +]
Author: Will Deacon <will@kernel.org>
Date:   Fri Jan 26 15:24:10 2024 +0000

    misc: open-dice: Fix spurious lockdep warning
    
    [ Upstream commit ac9762a74c7ca7cbfcb4c65f5871373653a046ac ]
    
    When probing the open-dice driver with PROVE_LOCKING=y, lockdep
    complains that the mutex in 'drvdata->lock' has a non-static key:
    
     | INFO: trying to register non-static key.
     | The code is fine but needs lockdep annotation, or maybe
     | you didn't initialize this object before use?
     | turning off the locking correctness validator.
    
    Fix the problem by initialising the mutex memory with mutex_init()
    instead of __MUTEX_INITIALIZER().
    
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: David Brazdil <dbrazdil@google.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20240126152410.10148-1-will@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/damon/core: check apply interval in damon_do_apply_schemes() [+ + +]
Author: SeongJae Park <sj@kernel.org>
Date:   Mon Feb 5 12:13:06 2024 -0800

    mm/damon/core: check apply interval in damon_do_apply_schemes()
    
    commit e9e3db69966d5e9e6f7e7d017b407c0025180fe5 upstream.
    
    kdamond_apply_schemes() checks apply intervals of schemes and avoid
    further applying any schemes if no scheme passed its apply interval.
    However, the following schemes applying function, damon_do_apply_schemes()
    iterates all schemes without the apply interval check.  As a result, the
    shortest apply interval is applied to all schemes.  Fix the problem by
    checking the apply interval in damon_do_apply_schemes().
    
    Link: https://lkml.kernel.org/r/20240205201306.88562-1-sj@kernel.org
    Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>    [6.7.x]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/damon/lru_sort: fix quota status loss due to online tunings [+ + +]
Author: SeongJae Park <sj@kernel.org>
Date:   Fri Feb 16 11:40:25 2024 -0800

    mm/damon/lru_sort: fix quota status loss due to online tunings
    
    commit 13d0599ab3b2ff17f798353f24bcbef1659d3cfc upstream.
    
    For online parameters change, DAMON_LRU_SORT creates new schemes based on
    latest values of the parameters and replaces the old schemes with the new
    one.  When creating it, the internal status of the quotas of the old
    schemes is not preserved.  As a result, charging of the quota starts from
    zero after the online tuning.  The data that collected to estimate the
    throughput of the scheme's action is also reset, and therefore the
    estimation should start from the scratch again.  Because the throughput
    estimation is being used to convert the time quota to the effective size
    quota, this could result in temporal time quota inaccuracy.  It would be
    recovered over time, though.  In short, the quota accuracy could be
    temporarily degraded after online parameters update.
    
    Fix the problem by checking the case and copying the internal fields for
    the status.
    
    Link: https://lkml.kernel.org/r/20240216194025.9207-3-sj@kernel.org
    Fixes: 40e983cca927 ("mm/damon: introduce DAMON-based LRU-lists Sorting")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>    [6.0+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/damon/reclaim: fix quota stauts loss due to online tunings [+ + +]
Author: SeongJae Park <sj@kernel.org>
Date:   Fri Feb 16 11:40:24 2024 -0800

    mm/damon/reclaim: fix quota stauts loss due to online tunings
    
    commit 1b0ca4e4ff10a2c8402e2cf70132c683e1c772e4 upstream.
    
    Patch series "mm/damon: fix quota status loss due to online tunings".
    
    DAMON_RECLAIM and DAMON_LRU_SORT is not preserving internal quota status
    when applying new user parameters, and hence could cause temporal quota
    accuracy degradation.  Fix it by preserving the status.
    
    
    This patch (of 2):
    
    For online parameters change, DAMON_RECLAIM creates new scheme based on
    latest values of the parameters and replaces the old scheme with the new
    one.  When creating it, the internal status of the quota of the old
    scheme is not preserved.  As a result, charging of the quota starts from
    zero after the online tuning.  The data that collected to estimate the
    throughput of the scheme's action is also reset, and therefore the
    estimation should start from the scratch again.  Because the throughput
    estimation is being used to convert the time quota to the effective size
    quota, this could result in temporal time quota inaccuracy.  It would be
    recovered over time, though.  In short, the quota accuracy could be
    temporarily degraded after online parameters update.
    
    Fix the problem by checking the case and copying the internal fields for
    the status.
    
    Link: https://lkml.kernel.org/r/20240216194025.9207-1-sj@kernel.org
    Link: https://lkml.kernel.org/r/20240216194025.9207-2-sj@kernel.org
    Fixes: e035c280f6df ("mm/damon/reclaim: support online inputs update")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>    [5.19+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/memblock: add MEMBLOCK_RSRV_NOINIT into flagname[] array [+ + +]
Author: Anshuman Khandual <anshuman.khandual@arm.com>
Date:   Fri Feb 9 08:39:12 2024 +0530

    mm/memblock: add MEMBLOCK_RSRV_NOINIT into flagname[] array
    
    commit 4f155af0ae4464134bfcfd9f043b6b727c84e947 upstream.
    
    The commit 77e6c43e137c ("memblock: introduce MEMBLOCK_RSRV_NOINIT flag")
    skipped adding this newly introduced memblock flag into flagname[] array,
    thus preventing a correct memblock flags output for applicable memblock
    regions.
    
    Link: https://lkml.kernel.org/r/20240209030912.1382251-1-anshuman.khandual@arm.com
    Fixes: 77e6c43e137c ("memblock: introduce MEMBLOCK_RSRV_NOINIT flag")
    Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Reviewed-by: Mike Rapoport <rppt@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/swap: fix race when skipping swapcache [+ + +]
Author: Kairui Song <kasong@tencent.com>
Date:   Wed Feb 7 02:25:59 2024 +0800

    mm/swap: fix race when skipping swapcache
    
    commit 13ddaf26be324a7f951891ecd9ccd04466d27458 upstream.
    
    When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads
    swapin the same entry at the same time, they get different pages (A, B).
    Before one thread (T0) finishes the swapin and installs page (A) to the
    PTE, another thread (T1) could finish swapin of page (B), swap_free the
    entry, then swap out the possibly modified page reusing the same entry.
    It breaks the pte_same check in (T0) because PTE value is unchanged,
    causing ABA problem.  Thread (T0) will install a stalled page (A) into the
    PTE and cause data corruption.
    
    One possible callstack is like this:
    
    CPU0                                 CPU1
    ----                                 ----
    do_swap_page()                       do_swap_page() with same entry
    <direct swapin path>                 <direct swapin path>
    <alloc page A>                       <alloc page B>
    swap_read_folio() <- read to page A  swap_read_folio() <- read to page B
    <slow on later locks or interrupt>   <finished swapin first>
    ...                                  set_pte_at()
                                         swap_free() <- entry is free
                                         <write to page B, now page A stalled>
                                         <swap out page B to same swap entry>
    pte_same() <- Check pass, PTE seems
                  unchanged, but page A
                  is stalled!
    swap_free() <- page B content lost!
    set_pte_at() <- staled page A installed!
    
    And besides, for ZRAM, swap_free() allows the swap device to discard the
    entry content, so even if page (B) is not modified, if swap_read_folio()
    on CPU0 happens later than swap_free() on CPU1, it may also cause data
    loss.
    
    To fix this, reuse swapcache_prepare which will pin the swap entry using
    the cache flag, and allow only one thread to swap it in, also prevent any
    parallel code from putting the entry in the cache.  Release the pin after
    PT unlocked.
    
    Racers just loop and wait since it's a rare and very short event.  A
    schedule_timeout_uninterruptible(1) call is added to avoid repeated page
    faults wasting too much CPU, causing livelock or adding too much noise to
    perf statistics.  A similar livelock issue was described in commit
    029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead")
    
    Reproducer:
    
    This race issue can be triggered easily using a well constructed
    reproducer and patched brd (with a delay in read path) [1]:
    
    With latest 6.8 mainline, race caused data loss can be observed easily:
    $ gcc -g -lpthread test-thread-swap-race.c && ./a.out
      Polulating 32MB of memory region...
      Keep swapping out...
      Starting round 0...
      Spawning 65536 workers...
      32746 workers spawned, wait for done...
      Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss!
      Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss!
      Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss!
      Round 0 Failed, 15 data loss!
    
    This reproducer spawns multiple threads sharing the same memory region
    using a small swap device.  Every two threads updates mapped pages one by
    one in opposite direction trying to create a race, with one dedicated
    thread keep swapping out the data out using madvise.
    
    The reproducer created a reproduce rate of about once every 5 minutes, so
    the race should be totally possible in production.
    
    After this patch, I ran the reproducer for over a few hundred rounds and
    no data loss observed.
    
    Performance overhead is minimal, microbenchmark swapin 10G from 32G
    zram:
    
    Before:     10934698 us
    After:      11157121 us
    Cached:     13155355 us (Dropping SWP_SYNCHRONOUS_IO flag)
    
    [kasong@tencent.com: v4]
      Link: https://lkml.kernel.org/r/20240219082040.7495-1-ryncsn@gmail.com
    Link: https://lkml.kernel.org/r/20240206182559.32264-1-ryncsn@gmail.com
    Fixes: 0bcac06f27d7 ("mm, swap: skip swapcache for swapin of synchronous device")
    Reported-by: "Huang, Ying" <ying.huang@intel.com>
    Closes: https://lore.kernel.org/lkml/87bk92gqpx.fsf_-_@yhuang6-desk2.ccr.corp.intel.com/
    Link: https://github.com/ryncsn/emm-test-project/tree/master/swap-stress-race [1]
    Signed-off-by: Kairui Song <kasong@tencent.com>
    Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
    Acked-by: Yu Zhao <yuzhao@google.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Acked-by: Chris Li <chrisl@kernel.org>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Yosry Ahmed <yosryahmed@google.com>
    Cc: Yu Zhao <yuzhao@google.com>
    Cc: Barry Song <21cnbao@gmail.com>
    Cc: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/zswap: invalidate duplicate entry when !zswap_enabled [+ + +]
Author: Chengming Zhou <zhouchengming@bytedance.com>
Date:   Thu Feb 8 02:32:54 2024 +0000

    mm/zswap: invalidate duplicate entry when !zswap_enabled
    
    commit 678e54d4bb9a4822f8ae99690ac131c5d490cdb1 upstream.
    
    We have to invalidate any duplicate entry even when !zswap_enabled since
    zswap can be disabled anytime.  If the folio store success before, then
    got dirtied again but zswap disabled, we won't invalidate the old
    duplicate entry in the zswap_store().  So later lru writeback may
    overwrite the new data in swapfile.
    
    Link: https://lkml.kernel.org/r/20240208023254.3873823-1-chengming.zhou@linux.dev
    Fixes: 42c06a0e8ebe ("mm: kill frontswap")
    Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Nhat Pham <nphamcs@gmail.com>
    Cc: Yosry Ahmed <yosryahmed@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm: memcontrol: clarify swapaccount=0 deprecation warning [+ + +]
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Tue Feb 13 03:16:34 2024 -0500

    mm: memcontrol: clarify swapaccount=0 deprecation warning
    
    commit 118642d7f606fc9b9c92ee611275420320290ffb upstream.
    
    The swapaccount deprecation warning is throwing false positives.  Since we
    deprecated the knob and defaulted to enabling, the only reports we've been
    getting are from folks that set swapaccount=1.  While this is a nice
    affirmation that always-enabling was the right choice, we certainly don't
    want to warn when users request the supported mode.
    
    Only warn when disabling is requested, and clarify the warning.
    
    [colin.i.king@gmail.com: spelling: "commdandline" -> "commandline"]
      Link: https://lkml.kernel.org/r/20240215090544.1649201-1-colin.i.king@gmail.com
    Link: https://lkml.kernel.org/r/20240213081634.3652326-1-hannes@cmpxchg.org
    Fixes: b25806dcd3d5 ("mm: memcontrol: deprecate swapaccounting=0 mode")
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Reported-by: "Jonas Schäfer" <jonas@wielicki.name>
    Reported-by: Narcis Garcia <debianlists@actiu.net>
    Suggested-by: Yosry Ahmed <yosryahmed@google.com>
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Yosry Ahmed <yosryahmed@google.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Shakeel Butt <shakeelb@google.com>
    Cc: Roman Gushchin <roman.gushchin@linux.dev>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm: zswap: fix missing folio cleanup in writeback race path [+ + +]
Author: Yosry Ahmed <yosryahmed@google.com>
Date:   Thu Jan 25 08:51:27 2024 +0000

    mm: zswap: fix missing folio cleanup in writeback race path
    
    commit e3b63e966cac0bf78aaa1efede1827a252815a1d upstream.
    
    In zswap_writeback_entry(), after we get a folio from
    __read_swap_cache_async(), we grab the tree lock again to check that the
    swap entry was not invalidated and recycled.  If it was, we delete the
    folio we just added to the swap cache and exit.
    
    However, __read_swap_cache_async() returns the folio locked when it is
    newly allocated, which is always true for this path, and the folio is
    ref'd.  Make sure to unlock and put the folio before returning.
    
    This was discovered by code inspection, probably because this path handles
    a race condition that should not happen often, and the bug would not crash
    the system, it will only strand the folio indefinitely.
    
    Link: https://lkml.kernel.org/r/20240125085127.1327013-1-yosryahmed@google.com
    Fixes: 04fc7816089c ("mm: fix zswap writeback race condition")
    Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
    Reviewed-by: Chengming Zhou <zhouchengming@bytedance.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Nhat Pham <nphamcs@gmail.com>
    Cc: Domenico Cerasuolo <cerasuolodomenico@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mptcp: add CurrEstab MIB counter support [+ + +]
Author: Geliang Tang <geliang@kernel.org>
Date:   Fri Dec 22 13:47:22 2023 +0100

    mptcp: add CurrEstab MIB counter support
    
    [ Upstream commit d9cd27b8cd191133e287e5de107f971136abe8a2 ]
    
    Add a new MIB counter named MPTCP_MIB_CURRESTAB to count current
    established MPTCP connections, similar to TCP_MIB_CURRESTAB. This is
    useful to quickly list the number of MPTCP connections without having to
    iterate over all of them.
    
    This patch adds a new helper function mptcp_set_state(): if the state
    switches from or to ESTABLISHED state, this newly added counter is
    incremented. This helper is going to be used in the following patch.
    
    Similar to MPTCP_INC_STATS(), a new helper called MPTCP_DEC_STATS() is
    also needed to decrement a MIB counter.
    
    Signed-off-by: Geliang Tang <geliang.tang@linux.dev>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: e4a0fa47e816 ("mptcp: corner case locking for rx path fields initialization")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mptcp: add needs_id for netlink appending addr [+ + +]
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Thu Feb 15 19:25:29 2024 +0100

    mptcp: add needs_id for netlink appending addr
    
    commit 584f3894262634596532cf43a5e782e34a0ce374 upstream.
    
    Just the same as userspace PM, a new parameter needs_id is added for
    in-kernel PM mptcp_pm_nl_append_new_local_addr() too.
    
    Add a new helper mptcp_pm_has_addr_attr_id() to check whether an address
    ID is set from PM or not.
    
    In mptcp_pm_nl_get_local_id(), needs_id is always true, but in
    mptcp_pm_nl_add_addr_doit(), pass mptcp_pm_has_addr_attr_id() to
    needs_it.
    
    Fixes: efd5a4c04e18 ("mptcp: add the address ID assignment bitmap")
    Cc: stable@vger.kernel.org
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    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>

mptcp: add needs_id for userspace appending addr [+ + +]
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Thu Feb 15 19:25:28 2024 +0100

    mptcp: add needs_id for userspace appending addr
    
    commit 6c347be62ae963b301ead8e7fa7b9973e6e0d6e1 upstream.
    
    When userspace PM requires to create an ID 0 subflow in "userspace pm
    create id 0 subflow" test like this:
    
            userspace_pm_add_sf $ns2 10.0.3.2 0
    
    An ID 1 subflow, in fact, is created.
    
    Since in mptcp_pm_nl_append_new_local_addr(), 'id 0' will be treated as
    no ID is set by userspace, and will allocate a new ID immediately:
    
         if (!e->addr.id)
                 e->addr.id = find_next_zero_bit(pernet->id_bitmap,
                                                 MPTCP_PM_MAX_ADDR_ID + 1,
                                                 1);
    
    To solve this issue, a new parameter needs_id is added for
    mptcp_userspace_pm_append_new_local_addr() to distinguish between
    whether userspace PM has set an ID 0 or whether userspace PM has
    not set any address.
    
    needs_id is true in mptcp_userspace_pm_get_local_id(), but false in
    mptcp_pm_nl_announce_doit() and mptcp_pm_nl_subflow_create_doit().
    
    Fixes: e5ed101a6028 ("mptcp: userspace pm allow creating id 0 subflow")
    Cc: stable@vger.kernel.org
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    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>

mptcp: corner case locking for rx path fields initialization [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 8 19:03:52 2024 +0100

    mptcp: corner case locking for rx path fields initialization
    
    [ Upstream commit e4a0fa47e816e186f6b4c0055d07eeec42d11871 ]
    
    Most MPTCP-level related fields are under the mptcp data lock
    protection, but are written one-off without such lock at MPC
    complete time, both for the client and the server
    
    Leverage the mptcp_propagate_state() infrastructure to move such
    initialization under the proper lock client-wise.
    
    The server side critical init steps are done by
    mptcp_subflow_fully_established(): ensure the caller properly held the
    relevant lock, and avoid acquiring the same lock in the nested scopes.
    
    There are no real potential races, as write access to such fields
    is implicitly serialized by the MPTCP state machine; the primary
    goal is consistency.
    
    Fixes: d22f4988ffec ("mptcp: process MP_CAPABLE data option")
    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: Sasha Levin <sashal@kernel.org>

mptcp: fix data races on local_id [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 15 19:25:31 2024 +0100

    mptcp: fix data races on local_id
    
    commit a7cfe776637004a4c938fde78be4bd608c32c3ef upstream.
    
    The local address id is accessed lockless by the NL PM, add
    all the required ONCE annotation. There is a caveat: the local
    id can be initialized late in the subflow life-cycle, and its
    validity is controlled by the local_id_valid flag.
    
    Remove such flag and encode the validity in the local_id field
    itself with negative value before initialization. That allows
    accessing the field consistently with a single read operation.
    
    Fixes: 0ee4261a3681 ("mptcp: implement mptcp_pm_remove_subflow")
    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>

mptcp: fix data races on remote_id [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 15 19:25:32 2024 +0100

    mptcp: fix data races on remote_id
    
    commit 967d3c27127e71a10ff5c083583a038606431b61 upstream.
    
    Similar to the previous patch, address the data race on
    remote_id, adding the suitable ONCE annotations.
    
    Fixes: bedee0b56113 ("mptcp: address lookup improvements")
    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>

mptcp: fix duplicate subflow creation [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 15 19:25:33 2024 +0100

    mptcp: fix duplicate subflow creation
    
    commit 045e9d812868a2d80b7a57b224ce8009444b7bbc upstream.
    
    Fullmesh endpoints could end-up unexpectedly generating duplicate
    subflows - same local and remote addresses - when multiple incoming
    ADD_ADDR are processed before the PM creates the subflow for the local
    endpoints.
    
    Address the issue explicitly checking for duplicates at subflow
    creation time.
    
    To avoid a quadratic computational complexity, track the unavailable
    remote address ids in a temporary bitmap and initialize such bitmap
    with the remote ids of all the existing subflows matching the local
    address currently processed.
    
    The above allows additionally replacing the existing code checking
    for duplicate entry in the current set with a simple bit test
    operation.
    
    Fixes: 2843ff6f36db ("mptcp: remote addresses fullmesh")
    Cc: stable@vger.kernel.org
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/435
    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>

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>

mptcp: fix more tx path fields initialization [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 8 19:03:51 2024 +0100

    mptcp: fix more tx path fields initialization
    
    [ Upstream commit 3f83d8a77eeeb47011b990fd766a421ee64f1d73 ]
    
    The 'msk->write_seq' and 'msk->snd_nxt' are always updated under
    the msk socket lock, except at MPC handshake completiont time.
    
    Builds-up on the previous commit to move such init under the relevant
    lock.
    
    There are no known problems caused by the potential race, the
    primary goal is consistency.
    
    Fixes: 6d0060f600ad ("mptcp: Write MPTCP DSS headers to outgoing data packets")
    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>
    Stable-dep-of: e4a0fa47e816 ("mptcp: corner case locking for rx path fields initialization")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mptcp: use mptcp_set_state [+ + +]
Author: Geliang Tang <geliang@kernel.org>
Date:   Fri Dec 22 13:47:23 2023 +0100

    mptcp: use mptcp_set_state
    
    [ Upstream commit c693a8516429908da3ea111b0caa3c042ab1e6e9 ]
    
    This patch replaces all the 'inet_sk_state_store()' calls under net/mptcp
    with the new helper mptcp_set_state().
    
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/460
    Signed-off-by: Geliang Tang <geliang.tang@linux.dev>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: e4a0fa47e816 ("mptcp: corner case locking for rx path fields initialization")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sched: act_mirred: Create function tcf_mirred_to_dev and improve readability [+ + +]
Author: Victor Nogueira <victor@mojatatu.com>
Date:   Tue Dec 19 15:16:21 2023 -0300

    net/sched: act_mirred: Create function tcf_mirred_to_dev and improve readability
    
    [ Upstream commit 16085e48cb48aeb50a1178dc276747749910b0f2 ]
    
    As a preparation for adding block ID to mirred, separate the part of
    mirred that redirect/mirrors to a dev into a specific function so that it
    can be called by blockcast for each dev.
    
    Also improve readability. Eg. rename use_reinsert to dont_clone and skb2
    to skb_to_send.
    
    Co-developed-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Co-developed-by: Pedro Tammela <pctammela@mojatatu.com>
    Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
    Signed-off-by: Victor Nogueira <victor@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 52f671db1882 ("net/sched: act_mirred: use the backlog for mirred ingress")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/sched: act_mirred: don't override retval if we already lost the skb [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu Feb 15 06:33:46 2024 -0800

    net/sched: act_mirred: don't override retval if we already lost the skb
    
    [ Upstream commit 166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210 ]
    
    If we're redirecting the skb, and haven't called tcf_mirred_forward(),
    yet, we need to tell the core to drop the skb by setting the retcode
    to SHOT. If we have called tcf_mirred_forward(), however, the skb
    is out of our hands and returning SHOT will lead to UaF.
    
    Move the retval override to the error path which actually need it.
    
    Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
    Fixes: e5cf1baf92cb ("act_mirred: use TC_ACT_REINSERT when possible")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/sched: act_mirred: use the backlog for mirred ingress [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu Feb 15 06:33:45 2024 -0800

    net/sched: act_mirred: use the backlog for mirred ingress
    
    [ Upstream commit 52f671db18823089a02f07efc04efdb2272ddc17 ]
    
    The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog
    for nested calls to mirred ingress") hangs our testing VMs every 10 or so
    runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by
    lockdep.
    
    The problem as previously described by Davide (see Link) is that
    if we reverse flow of traffic with the redirect (egress -> ingress)
    we may reach the same socket which generated the packet. And we may
    still be holding its socket lock. The common solution to such deadlocks
    is to put the packet in the Rx backlog, rather than run the Rx path
    inline. Do that for all egress -> ingress reversals, not just once
    we started to nest mirred calls.
    
    In the past there was a concern that the backlog indirection will
    lead to loss of error reporting / less accurate stats. But the current
    workaround does not seem to address the issue.
    
    Fixes: 53592b364001 ("net/sched: act_mirred: Implement ingress actions")
    Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Suggested-by: Davide Caratti <dcaratti@redhat.com>
    Link: https://lore.kernel.org/netdev/33dc43f587ec1388ba456b4915c75f02a8aae226.1663945716.git.dcaratti@redhat.com/
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/sched: flower: Add lock protection when remove filter handle [+ + +]
Author: Jianbo Liu <jianbol@nvidia.com>
Date:   Tue Feb 20 08:59:28 2024 +0000

    net/sched: flower: Add lock protection when remove filter handle
    
    [ Upstream commit 1fde0ca3a0de7e9f917668941156959dd5e9108b ]
    
    As IDR can't protect itself from the concurrent modification, place
    idr_remove() under the protection of tp->lock.
    
    Fixes: 08a0063df3ae ("net/sched: flower: Move filter handle initialization earlier")
    Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
    Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
    Reviewed-by: Gal Pressman <gal@nvidia.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Link: https://lore.kernel.org/r/20240220085928.9161-1-jianbol@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: bcmasp: Indicate MAC is in charge of PHY PM [+ + +]
Author: Florian Fainelli <florian.fainelli@broadcom.com>
Date:   Thu Feb 15 10:27:31 2024 -0800

    net: bcmasp: Indicate MAC is in charge of PHY PM
    
    [ Upstream commit 5b76d928f8b779a1b19c5842e7cabee4cbb610c3 ]
    
    Avoid the PHY library call unnecessarily into the suspend/resume
    functions by setting phydev->mac_managed_pm to true. The ASP driver
    essentially does exactly what mdio_bus_phy_resume() does.
    
    Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller")
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Justin Chen <justin.chen@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bcmasp: Sanity check is off by one [+ + +]
Author: Justin Chen <justin.chen@broadcom.com>
Date:   Thu Feb 15 10:27:32 2024 -0800

    net: bcmasp: Sanity check is off by one
    
    [ Upstream commit f120e62e37f0af4c4cbe08e5a88ea60a6a17c858 ]
    
    A sanity check for OOB write is off by one leading to a false positive
    when the array is full.
    
    Fixes: 9b90aca97f6d ("net: ethernet: bcmasp: fix possible OOB write in bcmasp_netfilt_get_all_active()")
    Signed-off-by: Justin Chen <justin.chen@broadcom.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bridge: switchdev: Ensure deferred event delivery on unoffload [+ + +]
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Feb 14 22:40:04 2024 +0100

    net: bridge: switchdev: Ensure deferred event delivery on unoffload
    
    [ Upstream commit f7a70d650b0b6b0134ccba763d672c8439d9f09b ]
    
    When unoffloading a device, it is important to ensure that all
    relevant deferred events are delivered to it before it disassociates
    itself from the bridge.
    
    Before this change, this was true for the normal case when a device
    maps 1:1 to a net_bridge_port, i.e.
    
       br0
       /
    swp0
    
    When swp0 leaves br0, the call to switchdev_deferred_process() in
    del_nbp() makes sure to process any outstanding events while the
    device is still associated with the bridge.
    
    In the case when the association is indirect though, i.e. when the
    device is attached to the bridge via an intermediate device, like a
    LAG...
    
        br0
        /
      lag0
      /
    swp0
    
    ...then detaching swp0 from lag0 does not cause any net_bridge_port to
    be deleted, so there was no guarantee that all events had been
    processed before the device disassociated itself from the bridge.
    
    Fix this by always synchronously processing all deferred events before
    signaling completion of unoffloading back to the driver.
    
    Fixes: 4e51bf44a03a ("net: bridge: move the switchdev object replay helpers to "push" mode")
    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bridge: switchdev: Skip MDB replays of deferred events on offload [+ + +]
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Feb 14 22:40:03 2024 +0100

    net: bridge: switchdev: Skip MDB replays of deferred events on offload
    
    [ Upstream commit dc489f86257cab5056e747344f17a164f63bff4b ]
    
    Before this change, generation of the list of MDB events to replay
    would race against the creation of new group memberships, either from
    the IGMP/MLD snooping logic or from user configuration.
    
    While new memberships are immediately visible to walkers of
    br->mdb_list, the notification of their existence to switchdev event
    subscribers is deferred until a later point in time. So if a replay
    list was generated during a time that overlapped with such a window,
    it would also contain a replay of the not-yet-delivered event.
    
    The driver would thus receive two copies of what the bridge internally
    considered to be one single event. On destruction of the bridge, only
    a single membership deletion event was therefore sent. As a
    consequence of this, drivers which reference count memberships (at
    least DSA), would be left with orphan groups in their hardware
    database when the bridge was destroyed.
    
    This is only an issue when replaying additions. While deletion events
    may still be pending on the deferred queue, they will already have
    been removed from br->mdb_list, so no duplicates can be generated in
    that scenario.
    
    To a user this meant that old group memberships, from a bridge in
    which a port was previously attached, could be reanimated (in
    hardware) when the port joined a new bridge, without the new bridge's
    knowledge.
    
    For example, on an mv88e6xxx system, create a snooping bridge and
    immediately add a port to it:
    
        root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \
        > ip link set dev x3 up master br0
    
    And then destroy the bridge:
    
        root@infix-06-0b-00:~$ ip link del dev br0
        root@infix-06-0b-00:~$ mvls atu
        ADDRESS             FID  STATE      Q  F  0  1  2  3  4  5  6  7  8  9  a
        DEV:0 Marvell 88E6393X
        33:33:00:00:00:6a     1  static     -  -  0  .  .  .  .  .  .  .  .  .  .
        33:33:ff:87:e4:3f     1  static     -  -  0  .  .  .  .  .  .  .  .  .  .
        ff:ff:ff:ff:ff:ff     1  static     -  -  0  1  2  3  4  5  6  7  8  9  a
        root@infix-06-0b-00:~$
    
    The two IPv6 groups remain in the hardware database because the
    port (x3) is notified of the host's membership twice: once via the
    original event and once via a replay. Since only a single delete
    notification is sent, the count remains at 1 when the bridge is
    destroyed.
    
    Then add the same port (or another port belonging to the same hardware
    domain) to a new bridge, this time with snooping disabled:
    
        root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \
        > ip link set dev x3 up master br1
    
    All multicast, including the two IPv6 groups from br0, should now be
    flooded, according to the policy of br1. But instead the old
    memberships are still active in the hardware database, causing the
    switch to only forward traffic to those groups towards the CPU (port
    0).
    
    Eliminate the race in two steps:
    
    1. Grab the write-side lock of the MDB while generating the replay
       list.
    
    This prevents new memberships from showing up while we are generating
    the replay list. But it leaves the scenario in which a deferred event
    was already generated, but not delivered, before we grabbed the
    lock. Therefore:
    
    2. Make sure that no deferred version of a replay event is already
       enqueued to the switchdev deferred queue, before adding it to the
       replay list, when replaying additions.
    
    Fixes: 4f2673b3a2b6 ("net: bridge: add helper to replay port and host-joined mdb entries")
    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: implement lockless setsockopt(SO_PEEK_OFF) [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Feb 19 14:12:20 2024 +0000

    net: implement lockless setsockopt(SO_PEEK_OFF)
    
    [ Upstream commit 56667da7399eb19af857e30f41bea89aa6fa812c ]
    
    syzbot reported a lockdep violation [1] involving af_unix
    support of SO_PEEK_OFF.
    
    Since SO_PEEK_OFF is inherently not thread safe (it uses a per-socket
    sk_peek_off field), there is really no point to enforce a pointless
    thread safety in the kernel.
    
    After this patch :
    
    - setsockopt(SO_PEEK_OFF) no longer acquires the socket lock.
    
    - skb_consume_udp() no longer has to acquire the socket lock.
    
    - af_unix no longer needs a special version of sk_set_peek_off(),
      because it does not lock u->iolock anymore.
    
    As a followup, we could replace prot->set_peek_off to be a boolean
    and avoid an indirect call, since we always use sk_set_peek_off().
    
    [1]
    
    WARNING: possible circular locking dependency detected
    6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Not tainted
    
    syz-executor.2/30025 is trying to acquire lock:
     ffff8880765e7d80 (&u->iolock){+.+.}-{3:3}, at: unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789
    
    but task is already holding lock:
     ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline]
     ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline]
     ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (sk_lock-AF_UNIX){+.+.}-{0:0}:
            lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
            lock_sock_nested+0x48/0x100 net/core/sock.c:3524
            lock_sock include/net/sock.h:1691 [inline]
            __unix_dgram_recvmsg+0x1275/0x12c0 net/unix/af_unix.c:2415
            sock_recvmsg_nosec+0x18e/0x1d0 net/socket.c:1046
            ____sys_recvmsg+0x3c0/0x470 net/socket.c:2801
            ___sys_recvmsg net/socket.c:2845 [inline]
            do_recvmmsg+0x474/0xae0 net/socket.c:2939
            __sys_recvmmsg net/socket.c:3018 [inline]
            __do_sys_recvmmsg net/socket.c:3041 [inline]
            __se_sys_recvmmsg net/socket.c:3034 [inline]
            __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034
           do_syscall_64+0xf9/0x240
           entry_SYSCALL_64_after_hwframe+0x6f/0x77
    
    -> #0 (&u->iolock){+.+.}-{3:3}:
            check_prev_add kernel/locking/lockdep.c:3134 [inline]
            check_prevs_add kernel/locking/lockdep.c:3253 [inline]
            validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869
            __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137
            lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
            __mutex_lock_common kernel/locking/mutex.c:608 [inline]
            __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752
            unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789
           sk_setsockopt+0x207e/0x3360
            do_sock_setsockopt+0x2fb/0x720 net/socket.c:2307
            __sys_setsockopt+0x1ad/0x250 net/socket.c:2334
            __do_sys_setsockopt net/socket.c:2343 [inline]
            __se_sys_setsockopt net/socket.c:2340 [inline]
            __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
           do_syscall_64+0xf9/0x240
           entry_SYSCALL_64_after_hwframe+0x6f/0x77
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(sk_lock-AF_UNIX);
                                   lock(&u->iolock);
                                   lock(sk_lock-AF_UNIX);
      lock(&u->iolock);
    
     *** DEADLOCK ***
    
    1 lock held by syz-executor.2/30025:
      #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline]
      #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline]
      #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193
    
    stack backtrace:
    CPU: 0 PID: 30025 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
      check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2187
      check_prev_add kernel/locking/lockdep.c:3134 [inline]
      check_prevs_add kernel/locking/lockdep.c:3253 [inline]
      validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869
      __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137
      lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
      __mutex_lock_common kernel/locking/mutex.c:608 [inline]
      __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752
      unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789
     sk_setsockopt+0x207e/0x3360
      do_sock_setsockopt+0x2fb/0x720 net/socket.c:2307
      __sys_setsockopt+0x1ad/0x250 net/socket.c:2334
      __do_sys_setsockopt net/socket.c:2343 [inline]
      __se_sys_setsockopt net/socket.c:2340 [inline]
      __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
     do_syscall_64+0xf9/0x240
     entry_SYSCALL_64_after_hwframe+0x6f/0x77
    RIP: 0033:0x7f78a1c7dda9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f78a0fde0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
    RAX: ffffffffffffffda RBX: 00007f78a1dac050 RCX: 00007f78a1c7dda9
    RDX: 000000000000002a RSI: 0000000000000001 RDI: 0000000000000006
    RBP: 00007f78a1cca47a R08: 0000000000000004 R09: 0000000000000000
    R10: 0000000020000180 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000000006e R14: 00007f78a1dac050 R15: 00007ffe5cd81ae8
    
    Fixes: 859051dd165e ("bpf: Implement cgroup sockaddr hooks for unix sockets")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
    Cc: Daan De Meyer <daan.j.demeyer@gmail.com>
    Cc: Kuniyuki Iwashima <kuniyu@amazon.com>
    Cc: Martin KaFai Lau <martin.lau@kernel.org>
    Cc: David Ahern <dsahern@kernel.org>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ipa: don't overrun IPA suspend interrupt registers [+ + +]
Author: Alex Elder <elder@linaro.org>
Date:   Mon Feb 19 08:40:15 2024 -0600

    net: ipa: don't overrun IPA suspend interrupt registers
    
    [ Upstream commit d80f8e96d47d7374794a30fbed69be43f3388afc ]
    
    In newer hardware, IPA supports more than 32 endpoints.  Some
    registers--such as IPA interrupt registers--represent endpoints
    as bits in a 4-byte register, and such registers are repeated as
    needed to represent endpoints beyond the first 32.
    
    In ipa_interrupt_suspend_clear_all(), we clear all pending IPA
    suspend interrupts by reading all status register(s) and writing
    corresponding registers to clear interrupt conditions.
    
    Unfortunately the number of registers to read/write is calculated
    incorrectly, and as a result we access *many* more registers than
    intended.  This bug occurs only when the IPA hardware signals a
    SUSPEND interrupt, which happens when a packet is received for an
    endpoint (or its underlying GSI channel) that is suspended.  This
    situation is difficult to reproduce, but possible.
    
    Fix this by correctly computing the number of interrupt registers to
    read and write.  This is the only place in the code where registers
    that map endpoints or channels this way perform this calculation.
    
    Fixes: f298ba785e2d ("net: ipa: add a parameter to suspend registers")
    Signed-off-by: Alex Elder <elder@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mctp: put sock on tag allocation failure [+ + +]
Author: Jeremy Kerr <jk@codeconstruct.com.au>
Date:   Thu Feb 15 15:53:08 2024 +0800

    net: mctp: put sock on tag allocation failure
    
    [ Upstream commit 9990889be14288d4f1743e4768222d5032a79c27 ]
    
    We may hold an extra reference on a socket if a tag allocation fails: we
    optimistically allocate the sk_key, and take a ref there, but do not
    drop if we end up not using the allocated key.
    
    Ensure we're dropping the sock on this failure by doing a proper unref
    rather than directly kfree()ing.
    
    Fixes: de8a6b15d965 ("net: mctp: add an explicit reference from a mctp_sk_key to sock")
    Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/ce9b61e44d1cdae7797be0c5e3141baf582d23a0.1707983487.git.jk@codeconstruct.com.au
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: realtek: Fix rtl8211f_config_init() for RTL8211F(D)(I)-VD-CG PHY [+ + +]
Author: Siddharth Vadapalli <s-vadapalli@ti.com>
Date:   Tue Feb 20 12:30:07 2024 +0530

    net: phy: realtek: Fix rtl8211f_config_init() for RTL8211F(D)(I)-VD-CG PHY
    
    [ Upstream commit 3489182b11d35f1944c1245fc9c4867cf622c50f ]
    
    Commit bb726b753f75 ("net: phy: realtek: add support for
    RTL8211F(D)(I)-VD-CG") extended support of the driver from the existing
    support for RTL8211F(D)(I)-CG PHY to the newer RTL8211F(D)(I)-VD-CG PHY.
    
    While that commit indicated that the RTL8211F_PHYCR2 register is not
    supported by the "VD-CG" PHY model and therefore updated the corresponding
    section in rtl8211f_config_init() to be invoked conditionally, the call to
    "genphy_soft_reset()" was left as-is, when it should have also been invoked
    conditionally. This is because the call to "genphy_soft_reset()" was first
    introduced by the commit 0a4355c2b7f8 ("net: phy: realtek: add dt property
    to disable CLKOUT clock") since the RTL8211F guide indicates that a PHY
    reset should be issued after setting bits in the PHYCR2 register.
    
    As the PHYCR2 register is not applicable to the "VD-CG" PHY model, fix the
    rtl8211f_config_init() function by invoking "genphy_soft_reset()"
    conditionally based on the presence of the "PHYCR2" register.
    
    Fixes: bb726b753f75 ("net: phy: realtek: add support for RTL8211F(D)(I)-VD-CG")
    Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240220070007.968762-1-s-vadapalli@ti.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: sparx5: Add spinlock for frame transmission from CPU [+ + +]
Author: Horatiu Vultur <horatiu.vultur@microchip.com>
Date:   Mon Feb 19 09:00:43 2024 +0100

    net: sparx5: Add spinlock for frame transmission from CPU
    
    [ Upstream commit 603ead96582d85903baec2d55f021b8dac5c25d2 ]
    
    Both registers used when doing manual injection or fdma injection are
    shared between all the net devices of the switch. It was noticed that
    when having two process which each of them trying to inject frames on
    different ethernet ports, that the HW started to behave strange, by
    sending out more frames then expected. When doing fdma injection it is
    required to set the frame in the DCB and then make sure that the next
    pointer of the last DCB is invalid. But because there is no locks for
    this, then easily this pointer between the DCB can be broken and then it
    would create a loop of DCBs. And that means that the HW will
    continuously transmit these frames in a loop. Until the SW will break
    this loop.
    Therefore to fix this issue, add a spin lock for when accessing the
    registers for manual or fdma injection.
    
    Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
    Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
    Fixes: f3cad2611a77 ("net: sparx5: add hostmode with phylink support")
    Link: https://lore.kernel.org/r/20240219080043.1561014-1-horatiu.vultur@microchip.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

netfilter: nf_tables: register hooks last when adding new chain/flowtable [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Feb 19 19:43:53 2024 +0100

    netfilter: nf_tables: register hooks last when adding new chain/flowtable
    
    [ Upstream commit d472e9853d7b46a6b094224d131d09ccd3a03daf ]
    
    Register hooks last when adding chain/flowtable to ensure that packets do
    not walk over datastructure that is being released in the error path
    without waiting for the rcu grace period.
    
    Fixes: 91c7b38dc9f0 ("netfilter: nf_tables: use new transaction infrastructure to handle chain")
    Fixes: 3b49e2e94e6e ("netfilter: nf_tables: add flow table netlink frontend")
    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>

netfilter: nf_tables: use kzalloc for hook allocation [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Feb 21 18:38:45 2024 +0100

    netfilter: nf_tables: use kzalloc for hook allocation
    
    [ Upstream commit 195e5f88c2e48330ba5483e0bad2de3b3fad484f ]
    
    KMSAN reports unitialized variable when registering the hook,
       reg->hook_ops_type == NF_HOOK_OP_BPF)
            ~~~~~~~~~~~ undefined
    
    This is a small structure, just use kzalloc to make sure this
    won't happen again when new fields get added to nf_hook_ops.
    
    Fixes: 7b4b2fa37587 ("netfilter: annotate nf_tables base hook ops")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

nvmet-fc: free queue and assoc directly [+ + +]
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:05 2024 +0100

    nvmet-fc: free queue and assoc directly
    
    [ Upstream commit c5e27b1a779ec25779d04c3af65aebaee6bd4304 ]
    
    Neither struct nvmet_fc_tgt_queue nor struct nvmet_fc_tgt_assoc are data
    structure which are used in a RCU context. So there is no reason to
    delay the free operation.
    
    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: hold reference on hostport match [+ + +]
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:06 2024 +0100

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

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

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

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

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

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

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

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

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

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

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

 
parisc: Fix stack unwinder [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu Feb 15 13:51:45 2024 -0800

    parisc: Fix stack unwinder
    
    [ Upstream commit 882a2a724ee964c1ebe7268a91d5c8c8ddc796bf ]
    
    Debugging shows a large number of unaligned access traps in the unwinder
    code. Code analysis reveals a number of issues with this code:
    
    - handle_interruption is passed twice through
      dereference_kernel_function_descriptor()
    - ret_from_kernel_thread, syscall_exit, intr_return,
      _switch_to_ret, and _call_on_stack are passed through
      dereference_kernel_function_descriptor() even though they are
      not declared as function pointers.
    
    To fix the problems, drop one of the calls to
    dereference_kernel_function_descriptor() for handle_interruption,
    and compare the other pointers directly.
    
    Fixes: 6414b30b39f9 ("parisc: unwind: Avoid missing prototype warning for handle_interruption()")
    Fixes: 8e0ba125c2bf ("parisc/unwind: fix unwinder when CONFIG_64BIT is enabled")
    Cc: Helge Deller <deller@gmx.de>
    Cc: Sven Schnelle <svens@stackframe.org>
    Cc: John David Anglin <dave.anglin@bell.net>
    Cc: Charlie Jenkins <charlie@rivosinc.com>
    Cc: David Laight <David.Laight@ACULAB.COM>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    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>

 
phonet/pep: fix racy skb_queue_empty() use [+ + +]
Author: Rémi Denis-Courmont <courmisch@gmail.com>
Date:   Sun Feb 18 10:12:14 2024 +0200

    phonet/pep: fix racy skb_queue_empty() use
    
    [ Upstream commit 7d2a894d7f487dcb894df023e9d3014cf5b93fe5 ]
    
    The receive queues are protected by their respective spin-lock, not
    the socket lock. This could lead to skb_peek() unexpectedly
    returning NULL or a pointer to an already dequeued socket buffer.
    
    Fixes: 9641458d3ec4 ("Phonet: Pipe End Point for Phonet Pipes protocol")
    Signed-off-by: Rémi Denis-Courmont <courmisch@gmail.com>
    Link: https://lore.kernel.org/r/20240218081214.4806-2-remi@remlab.net
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
phonet: take correct lock to peek at the RX queue [+ + +]
Author: Rémi Denis-Courmont <courmisch@gmail.com>
Date:   Sun Feb 18 10:12:13 2024 +0200

    phonet: take correct lock to peek at the RX queue
    
    [ Upstream commit 3b2d9bc4d4acdf15a876eae2c0d83149250e85ba ]
    
    The receive queue is protected by its embedded spin-lock, not the
    socket lock, so we need the former lock here (and only that one).
    
    Fixes: 107d0d9b8d9a ("Phonet: Phonet datagram transport protocol")
    Reported-by: Luosili <rootlab@huawei.com>
    Signed-off-by: Rémi Denis-Courmont <courmisch@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240218081214.4806-1-remi@remlab.net
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/mellanox: mlxbf-tmfifo: Drop Tx network packet when Tx TmFIFO is full [+ + +]
Author: Liming Sun <limings@nvidia.com>
Date:   Thu Jan 11 12:31:06 2024 -0500

    platform/mellanox: mlxbf-tmfifo: Drop Tx network packet when Tx TmFIFO is full
    
    [ Upstream commit 8cbc756b802605dee3dd40019bd75960772bacf5 ]
    
    Starting from Linux 5.16 kernel, Tx timeout mechanism was added
    in the virtio_net driver which prints the "Tx timeout" warning
    message when a packet stays in Tx queue for too long. Below is an
    example of the reported message:
    
    "[494105.316739] virtio_net virtio1 tmfifo_net0: TX timeout on
    queue: 0, sq: output.0, vq: 0×1, name: output.0, usecs since
    last trans: 3079892256".
    
    This issue could happen when external host driver which drains the
    FIFO is restared, stopped or upgraded. To avoid such confusing
    "Tx timeout" messages, this commit adds logic to drop the outstanding
    Tx packet if it's not able to transmit in two seconds due to Tx FIFO
    full, which can be considered as congestion or out-of-resource drop.
    
    This commit also handles the special case that the packet is half-
    transmitted into the Tx FIFO. In such case, the packet is discarded
    with remaining length stored in vring->rem_padding. So paddings with
    zeros can be sent out when Tx space is available to maintain the
    integrity of the packet format. The padded packet will be dropped on
    the receiving side.
    
    Signed-off-by: Liming Sun <limings@nvidia.com>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20240111173106.96958-1-limings@nvidia.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

platform/x86: think-lmi: Fix password opcode ordering for workstations [+ + +]
Author: Mark Pearson <mpearson-lenovo@squebb.ca>
Date:   Fri Feb 9 10:23:47 2024 -0500

    platform/x86: think-lmi: Fix password opcode ordering for workstations
    
    [ Upstream commit 6f7d0f5fd8e440c3446560100ac4ff9a55eec340 ]
    
    The Lenovo workstations require the password opcode to be run before
    the attribute value is changed (if Admin password is enabled).
    
    Tested on some Thinkpads to confirm they are OK with this order too.
    
    Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca>
    Fixes: 640a5fa50a42 ("platform/x86: think-lmi: Opcode support")
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20240209152359.528919-1-mpearson-lenovo@squebb.ca
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: thinkpad_acpi: Only update profile if successfully converted [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Fri Feb 16 20:23:11 2024 -0600

    platform/x86: thinkpad_acpi: Only update profile if successfully converted
    
    [ Upstream commit 427c70dec738318b7f71e1b9d829ff0e9771d493 ]
    
    Randomly a Lenovo Z13 will trigger a kernel warning traceback from this
    condition:
    
    ```
    if (WARN_ON((profile < 0) || (profile >= ARRAY_SIZE(profile_names))))
    ```
    
    This happens because thinkpad-acpi always assumes that
    convert_dytc_to_profile() successfully updated the profile. On the
    contrary a condition can occur that when dytc_profile_refresh() is called
    the profile doesn't get updated as there is a -EOPNOTSUPP branch.
    
    Catch this situation and avoid updating the profile. Also log this into
    dynamic debugging in case any other modes should be added in the future.
    
    Fixes: c3bfcd4c6762 ("platform/x86: thinkpad_acpi: Add platform profile support")
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/r/20240217022311.113879-1-mario.limonciello@amd.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

platform/x86: x86-android-tablets: Fix keyboard touchscreen on Lenovo Yogabook1 X90 [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Feb 16 21:17:18 2024 +0100

    platform/x86: x86-android-tablets: Fix keyboard touchscreen on Lenovo Yogabook1 X90
    
    commit bd8905d70944aae5063fd91c667e6f846ee92718 upstream.
    
    After commit 4014ae236b1d ("platform/x86: x86-android-tablets: Stop using
    gpiolib private APIs") the touchscreen in the keyboard half of
    the Lenovo Yogabook1 X90 stopped working with the following error:
    
     Goodix-TS i2c-goodix_ts: error -EBUSY: Failed to get irq GPIO
    
    The problem is that when getting the IRQ for instantiated i2c_client-s
    from a GPIO (rather then using an IRQ directly from the IOAPIC),
    x86_acpi_irq_helper_get() now properly requests the GPIO, which disallows
    other drivers from requesting it. Normally this is a good thing, but
    the goodix touchscreen also uses the IRQ as an output during reset
    to select which of its 2 possible I2C addresses should be used.
    
    Add a new free_gpio flag to struct x86_acpi_irq_data to deal with this
    and release the GPIO after getting the IRQ in this special case.
    
    Fixes: 4014ae236b1d ("platform/x86: x86-android-tablets: Stop using gpiolib private APIs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240216201721.239791-2-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/pseries/iommu: DLPAR add doesn't completely initialize pci_controller [+ + +]
Author: Gaurav Batra <gbatra@linux.ibm.com>
Date:   Thu Feb 15 16:18:33 2024 -0600

    powerpc/pseries/iommu: DLPAR add doesn't completely initialize pci_controller
    
    [ Upstream commit a5c57fd2e9bd1c8ea8613a8f94fd0be5eccbf321 ]
    
    When a PCI device is dynamically added, the kernel oopses with a NULL
    pointer dereference:
    
      BUG: Kernel NULL pointer dereference on read at 0x00000030
      Faulting instruction address: 0xc0000000006bbe5c
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
      Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse
      CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66
      Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries
      NIP:  c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8
      REGS: c00000009924f240 TRAP: 0300   Not tainted  (6.7.0-203405+)
      MSR:  8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 24002220  XER: 20040006
      CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0
      ...
      NIP sysfs_add_link_to_group+0x34/0x94
      LR  iommu_device_link+0x5c/0x118
      Call Trace:
       iommu_init_device+0x26c/0x318 (unreliable)
       iommu_device_link+0x5c/0x118
       iommu_init_device+0xa8/0x318
       iommu_probe_device+0xc0/0x134
       iommu_bus_notifier+0x44/0x104
       notifier_call_chain+0xb8/0x19c
       blocking_notifier_call_chain+0x64/0x98
       bus_notify+0x50/0x7c
       device_add+0x640/0x918
       pci_device_add+0x23c/0x298
       of_create_pci_dev+0x400/0x884
       of_scan_pci_dev+0x124/0x1b0
       __of_scan_bus+0x78/0x18c
       pcibios_scan_phb+0x2a4/0x3b0
       init_phb_dynamic+0xb8/0x110
       dlpar_add_slot+0x170/0x3b8 [rpadlpar_io]
       add_slot_store.part.0+0xb4/0x130 [rpadlpar_io]
       kobj_attr_store+0x2c/0x48
       sysfs_kf_write+0x64/0x78
       kernfs_fop_write_iter+0x1b0/0x290
       vfs_write+0x350/0x4a0
       ksys_write+0x84/0x140
       system_call_exception+0x124/0x330
       system_call_vectored_common+0x15c/0x2ec
    
    Commit a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities
    and allow blocking domains") broke DLPAR add of PCI devices.
    
    The above added iommu_device structure to pci_controller. During
    system boot, PCI devices are discovered and this newly added iommu_device
    structure is initialized by a call to iommu_device_register().
    
    During DLPAR add of a PCI device, a new pci_controller structure is
    allocated but there are no calls made to iommu_device_register()
    interface.
    
    Fix is to register the iommu device during DLPAR add as well.
    
    Fixes: a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains")
    Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com>
    Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240215221833.4817-1-gbatra@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/bnxt_re: Add a missing check in bnxt_qplib_query_srq [+ + +]
Author: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Date:   Mon Jan 22 20:54:37 2024 -0800

    RDMA/bnxt_re: Add a missing check in bnxt_qplib_query_srq
    
    [ Upstream commit 80dde187f734cf9ccf988d5c2ef1a46b990660fd ]
    
    Before populating the response, driver has to check the status
    of HWRM command.
    
    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-6-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    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/irdma: Add AE for too many RNRS [+ + +]
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Wed Jan 31 17:38:49 2024 -0600

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

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

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

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

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

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

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

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

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

 
RDMA/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 (max5970): Fix IRQ handler [+ + +]
Author: Patrick Rudolph <patrick.rudolph@9elements.com>
Date:   Tue Jan 30 20:32:56 2024 +0530

    regulator (max5970): Fix IRQ handler
    
    [ Upstream commit a3fa9838e8140584a6f338e8516f2b05d3bea812 ]
    
    The max5970 datasheet gives the impression that IRQ status bits must
    be cleared by writing a one to set bits, as those are marked with 'R/C',
    however tests showed that a zero must be written.
    
    Fixes an IRQ storm as the interrupt handler actually clears the IRQ
    status bits.
    
    Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
    Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
    Link: https://msgid.link/r/20240130150257.3643657-1-naresh.solanki@9elements.com
    Signed-off-by: Mark Brown <broonie@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 "drm/amd/display: increased min_dcfclk_mhz and min_fclk_mhz" [+ + +]
Author: Sohaib Nadeem <sohaib.nadeem@amd.com>
Date:   Mon Jan 29 17:33:40 2024 -0500

    Revert "drm/amd/display: increased min_dcfclk_mhz and min_fclk_mhz"
    
    commit a538dabf772c169641e151834e161e241802ab33 upstream.
    
    [why]:
    This reverts commit 2ff33c759a4247c84ec0b7815f1f223e155ba82a.
    
    The commit caused corruption when running some applications in fullscreen
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Alvin Lee <alvin.lee2@amd.com>
    Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Sohaib Nadeem <sohaib.nadeem@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "parisc: Only list existing CPUs in cpu_possible_mask" [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Mon Feb 5 10:39:20 2024 +0100

    Revert "parisc: Only list existing CPUs in cpu_possible_mask"
    
    commit 82b143aeb169b8b55798d7d2063032e1a6ceeeb0 upstream.
    
    This reverts commit 0921244f6f4f0d05698b953fe632a99b38907226.
    
    It broke CPU hotplugging because it modifies the __cpu_possible_mask
    after bootup, so that it will be different than nr_cpu_ids, which
    then effictively breaks the workqueue setup code and triggers crashes
    when shutting down CPUs at runtime.
    
    Guenter was the first who noticed the wrong values in __cpu_possible_mask,
    since the cpumask Kunit tests were failig.
    
    Reverting this commit fixes both issues, but sadly brings back this
    uncritical runtime warning:
    register_cpu_capacity_sysctl: too early to get CPU4 device!
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lkml.org/lkml/2024/2/4/146
    Link: https://lore.kernel.org/lkml/Zb0mbHlIud_bqftx@slm.duckdns.org/t/
    Cc: stable@vger.kernel.org # 6.0+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "usb: typec: tcpm: reset counter when enter into unattached state after try role" [+ + +]
Author: Ondrej Jirman <megi@xff.cz>
Date:   Sat Feb 17 17:20:21 2024 +0100

    Revert "usb: typec: tcpm: reset counter when enter into unattached state after try role"
    
    commit 23b1d2d99b0f55326f05e7d757fa197c4a95dc5c upstream.
    
    The reverted commit makes the state machine only ever go from SRC_ATTACH_WAIT
    to SNK_TRY in endless loop when toggling. After revert it goes to SRC_ATTACHED
    after initially trying SNK_TRY earlier, as it should for toggling to ever detect
    the power source mode and the port is again able to provide power to attached
    power sinks.
    
    This reverts commit 2d6d80127006ae3da26b1f21a65eccf957f2d1e5.
    
    Cc: stable@vger.kernel.org
    Fixes: 2d6d80127006 ("usb: typec: tcpm: reset counter when enter into unattached state after try role")
    Signed-off-by: Ondrej Jirman <megi@xff.cz>
    Link: https://lore.kernel.org/r/20240217162023.1719738-1-megi@xff.cz
    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>

 
scsi: core: Consult supported VPD page list prior to fetching page [+ + +]
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Wed Feb 14 17:14:11 2024 -0500

    scsi: core: Consult supported VPD page list prior to fetching page
    
    commit b5fc07a5fb56216a49e6c1d0b172d5464d99a89b upstream.
    
    Commit c92a6b5d6335 ("scsi: core: Query VPD size before getting full
    page") removed the logic which checks whether a VPD page is present on
    the supported pages list before asking for the page itself. That was
    done because SPC helpfully states "The Supported VPD Pages VPD page
    list may or may not include all the VPD pages that are able to be
    returned by the device server". Testing had revealed a few devices
    that supported some of the 0xBn pages but didn't actually list them in
    page 0.
    
    Julian Sikorski bisected a problem with his drive resetting during
    discovery to the commit above. As it turns out, this particular drive
    firmware will crash if we attempt to fetch page 0xB9.
    
    Various approaches were attempted to work around this. In the end,
    reinstating the logic that consults VPD page 0 before fetching any
    other page was the path of least resistance. A firmware update for the
    devices which originally compelled us to remove the check has since
    been released.
    
    Link: https://lore.kernel.org/r/20240214221411.2888112-1-martin.petersen@oracle.com
    Fixes: c92a6b5d6335 ("scsi: core: Query VPD size before getting full page")
    Cc: stable@vger.kernel.org
    Cc: Bart Van Assche <bvanassche@acm.org>
    Reported-by: Julian Sikorski <belegdol@gmail.com>
    Tested-by: Julian Sikorski <belegdol@gmail.com>
    Reviewed-by: Lee Duncan <lee.duncan@suse.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    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: sd: usb_storage: uas: Access media prior to querying device properties [+ + +]
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Tue Feb 13 09:33:06 2024 -0500

    scsi: sd: usb_storage: uas: Access media prior to querying device properties
    
    commit 321da3dc1f3c92a12e3c5da934090d2992a8814c upstream.
    
    It has been observed that some USB/UAS devices return generic properties
    hardcoded in firmware for mode pages for a period of time after a device
    has been discovered. The reported properties are either garbage or they do
    not accurately reflect the characteristics of the physical storage device
    attached in the case of a bridge.
    
    Prior to commit 1e029397d12f ("scsi: sd: Reorganize DIF/DIX code to
    avoid calling revalidate twice") we would call revalidate several
    times during device discovery. As a result, incorrect values would
    eventually get replaced with ones accurately describing the attached
    storage. When we did away with the redundant revalidate pass, several
    cases were reported where devices reported nonsensical values or would
    end up in write-protected state.
    
    An initial attempt at addressing this issue involved introducing a
    delayed second revalidate invocation. However, this approach still
    left some devices reporting incorrect characteristics.
    
    Tasos Sahanidis debugged the problem further and identified that
    introducing a READ operation prior to MODE SENSE fixed the problem and that
    it wasn't a timing issue. Issuing a READ appears to cause the devices to
    update their state to reflect the actual properties of the storage
    media. Device properties like vendor, model, and storage capacity appear to
    be correctly reported from the get-go. It is unclear why these devices
    defer populating the remaining characteristics.
    
    Match the behavior of a well known commercial operating system and
    trigger a READ operation prior to querying device characteristics to
    force the device to populate the mode pages.
    
    The additional READ is triggered by a flag set in the USB storage and
    UAS drivers. We avoid issuing the READ for other transport classes
    since some storage devices identify Linux through our particular
    discovery command sequence.
    
    Link: https://lore.kernel.org/r/20240213143306.2194237-1-martin.petersen@oracle.com
    Fixes: 1e029397d12f ("scsi: sd: Reorganize DIF/DIX code to avoid calling revalidate twice")
    Cc: stable@vger.kernel.org
    Reported-by: Tasos Sahanidis <tasos@tasossah.com>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Tested-by: Tasos Sahanidis <tasos@tasossah.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: smartpqi: Add new controller PCI IDs [+ + +]
Author: David Strahan <david.strahan@microchip.com>
Date:   Tue Dec 19 13:36:50 2023 -0600

    scsi: smartpqi: Add new controller PCI IDs
    
    [ Upstream commit c6d5aa44eaf6d119f9ceb3bfc7d22405ac04232a ]
    
    All PCI ID entries in Hex.
    
    Add PCI IDs for Cisco controllers:
                                                    VID  / DID  / SVID / SDID
                                                    ----   ----   ----   ----
            Cisco 24G TriMode M1 RAID 4GB FBWC 32D  9005 / 028f / 1137 / 02f8
            Cisco 24G TriMode M1 RAID 4GB FBWC 16D  9005 / 028f / 1137 / 02f9
            Cisco 24G TriMode M1 HBA 16D            9005 / 028f / 1137 / 02fa
    
    Add PCI IDs for CloudNine controllers:
                                                    VID  / DID  / SVID / SDID
                                                    ----   ----   ----   ----
            SmartRAID P7604N-16i                    9005 / 028f / 1f51 / 100e
            SmartRAID P7604N-8i                     9005 / 028f / 1f51 / 100f
            SmartRAID P7504N-16i                    9005 / 028f / 1f51 / 1010
            SmartRAID P7504N-8i                     9005 / 028f / 1f51 / 1011
            SmartRAID P7504N-8i                     9005 / 028f / 1f51 / 1043
            SmartHBA  P6500-8i                      9005 / 028f / 1f51 / 1044
            SmartRAID P7504-8i                      9005 / 028f / 1f51 / 1045
    
    Reviewed-by: Murthy Bhat <Murthy.Bhat@microchip.com>
    Reviewed-by: Mahesh Rajashekhara <mahesh.rajashekhara@microchip.com>
    Reviewed-by: Scott Teel <scott.teel@microchip.com>
    Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
    Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
    Reviewed-by: Kevin Barnett <kevin.barnett@microchip.com>
    Signed-off-by: David Strahan <david.strahan@microchip.com>
    Signed-off-by: Don Brace <don.brace@microchip.com>
    Link: https://lore.kernel.org/r/20231219193653.277553-2-don.brace@microchip.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: smartpqi: Fix disable_managed_interrupts [+ + +]
Author: Don Brace <don.brace@microchip.com>
Date:   Tue Feb 13 10:22:00 2024 -0600

    scsi: smartpqi: Fix disable_managed_interrupts
    
    [ Upstream commit 5761eb9761d2d5fe8248a9b719efc4d8baf1f24a ]
    
    Correct blk-mq registration issue with module parameter
    disable_managed_interrupts enabled.
    
    When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs to
    register with blk-mq using blk_mq_map_queues(). The driver is currently
    calling blk_mq_pci_map_queues() which results in a stack trace and possibly
    undefined behavior.
    
    Stack Trace:
    [    7.860089] scsi host2: smartpqi
    [    7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0
    [    7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
    [    7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1
    [    7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022
    [    7.963026] Workqueue: events work_for_cpu_fn
    [    7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0
    [    7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54
    [    7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216
    [    7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010
    [    7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310
    [    7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00
    [    7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000
    [    7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8
    [    7.978290] FS:  0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000
    [    7.978292] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0
    [    8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [    8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [    8.172818] PKRU: 55555554
    [    8.172819] Call Trace:
    [    8.172823]  blk_mq_alloc_tag_set+0x12e/0x310
    [    8.264339]  scsi_add_host_with_dma.cold.9+0x30/0x245
    [    8.279302]  pqi_ctrl_init+0xacf/0xc8e [smartpqi]
    [    8.294085]  ? pqi_pci_probe+0x480/0x4c8 [smartpqi]
    [    8.309015]  pqi_pci_probe+0x480/0x4c8 [smartpqi]
    [    8.323286]  local_pci_probe+0x42/0x80
    [    8.337855]  work_for_cpu_fn+0x16/0x20
    [    8.351193]  process_one_work+0x1a7/0x360
    [    8.364462]  ? create_worker+0x1a0/0x1a0
    [    8.379252]  worker_thread+0x1ce/0x390
    [    8.392623]  ? create_worker+0x1a0/0x1a0
    [    8.406295]  kthread+0x10a/0x120
    [    8.418428]  ? set_kthread_struct+0x50/0x50
    [    8.431532]  ret_from_fork+0x1f/0x40
    [    8.444137] ---[ end trace 1bf0173d39354506 ]---
    
    Fixes: cf15c3e734e8 ("scsi: smartpqi: Add module param to disable managed ints")
    Tested-by: Yogesh Chandra Pandey <YogeshChandra.Pandey@microchip.com>
    Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
    Reviewed-by: Scott Teel <scott.teel@microchip.com>
    Reviewed-by: Mahesh Rajashekhara <mahesh.rajashekhara@microchip.com>
    Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
    Reviewed-by: Kevin Barnett <kevin.barnett@microchip.com>
    Signed-off-by: Don Brace <don.brace@microchip.com>
    Link: https://lore.kernel.org/r/20240213162200.1875970-2-don.brace@microchip.com
    Reviewed-by: Tomas Henzl <thenzl@redhat.com>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: smartpqi: Fix logical volume rescan race condition [+ + +]
Author: Mahesh Rajashekhara <mahesh.rajashekhara@microchip.com>
Date:   Tue Dec 19 13:36:51 2023 -0600

    scsi: smartpqi: Fix logical volume rescan race condition
    
    [ Upstream commit fb4cece17b4583f55b34a8538e27a4adc833c9d4 ]
    
    Correct rescan flag race condition.
    
    Multiple conditions are being evaluated before notifying OS to do a rescan.
    
    Driver will skip rescanning the device if any one of the following
    conditions are met:
    
     - Devices that have not yet been added to the OS or devices that have been
       removed.
    
     - Devices which are already marked for removal or in the phase of removal.
    
    Under very rare conditions, after logical volume size expansion, the OS
    still sees the size of the logical volume which was before expansion.
    
    The rescan flag in the driver is used to signal the need for a logical
    volume rescan. A race condition can occur in the driver, and it leads to
    one thread overwriting the flag inadvertently. As a result, driver is not
    notifying the OS SML to rescan the logical volume.
    
    Move device->rescan update into new function pqi_mark_volumes_for_rescan()
    and protect with a spin lock.
    
    Move check for device->rescan into new function pqi_volume_rescan_needed()
    and protect function call with a spin_lock.
    
    Reviewed-by: Scott Teel <scott.teel@microchip.com>
    Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
    Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
    Reviewed-by: Kevin Barnett <kevin.barnett@microchip.com>
    Co-developed-by: Murthy Bhat <Murthy.Bhat@microchip.com>
    Signed-off-by: Murthy Bhat <Murthy.Bhat@microchip.com>
    Signed-off-by: Mahesh Rajashekhara <mahesh.rajashekhara@microchip.com>
    Signed-off-by: Don Brace <don.brace@microchip.com>
    Link: https://lore.kernel.org/r/20231219193653.277553-3-don.brace@microchip.com
    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>

scsi: target: pscsi: Fix bio_put() for error case [+ + +]
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Wed Feb 14 23:43:56 2024 +0900

    scsi: target: pscsi: Fix bio_put() for error case
    
    commit de959094eb2197636f7c803af0943cb9d3b35804 upstream.
    
    As of commit 066ff571011d ("block: turn bio_kmalloc into a simple kmalloc
    wrapper"), a bio allocated by bio_kmalloc() must be freed by bio_uninit()
    and kfree(). That is not done properly for the error case, hitting WARN and
    NULL pointer dereference in bio_free().
    
    Fixes: 066ff571011d ("block: turn bio_kmalloc into a simple kmalloc wrapper")
    CC: stable@vger.kernel.org # 6.1+
    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Link: https://lore.kernel.org/r/20240214144356.101814-1-naohiro.aota@wdc.com
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: ufs: core: Fix shift issue in ufshcd_clear_cmd() [+ + +]
Author: Alice Chao <alice.chao@mediatek.com>
Date:   Mon Feb 5 18:49:04 2024 +0800

    scsi: ufs: core: Fix shift issue in ufshcd_clear_cmd()
    
    [ Upstream commit b513d30d59bb383a6a5d6b533afcab2cee99a8f8 ]
    
    When task_tag >= 32 (in MCQ mode) and sizeof(unsigned int) == 4, 1U <<
    task_tag will out of bounds for a u32 mask. Fix this up to prevent
    SHIFT_ISSUE (bitwise shifts that are out of bounds for their data type).
    
    [name:debug_monitors&]Unexpected kernel BRK exception at EL1
    [name:traps&]Internal error: BRK handler: 00000000f2005514 [#1] PREEMPT SMP
    [name:mediatek_cpufreq_hw&]cpufreq stop DVFS log done
    [name:mrdump&]Kernel Offset: 0x1ba5800000 from 0xffffffc008000000
    [name:mrdump&]PHYS_OFFSET: 0x80000000
    [name:mrdump&]pstate: 22400005 (nzCv daif +PAN -UAO)
    [name:mrdump&]pc : [0xffffffdbaf52bb2c] ufshcd_clear_cmd+0x280/0x288
    [name:mrdump&]lr : [0xffffffdbaf52a774] ufshcd_wait_for_dev_cmd+0x3e4/0x82c
    [name:mrdump&]sp : ffffffc0081471b0
    <snip>
    Workqueue: ufs_eh_wq_0 ufshcd_err_handler
    Call trace:
     dump_backtrace+0xf8/0x144
     show_stack+0x18/0x24
     dump_stack_lvl+0x78/0x9c
     dump_stack+0x18/0x44
     mrdump_common_die+0x254/0x480 [mrdump]
     ipanic_die+0x20/0x30 [mrdump]
     notify_die+0x15c/0x204
     die+0x10c/0x5f8
     arm64_notify_die+0x74/0x13c
     do_debug_exception+0x164/0x26c
     el1_dbg+0x64/0x80
     el1h_64_sync_handler+0x3c/0x90
     el1h_64_sync+0x68/0x6c
     ufshcd_clear_cmd+0x280/0x288
     ufshcd_wait_for_dev_cmd+0x3e4/0x82c
     ufshcd_exec_dev_cmd+0x5bc/0x9ac
     ufshcd_verify_dev_init+0x84/0x1c8
     ufshcd_probe_hba+0x724/0x1ce0
     ufshcd_host_reset_and_restore+0x260/0x574
     ufshcd_reset_and_restore+0x138/0xbd0
     ufshcd_err_handler+0x1218/0x2f28
     process_one_work+0x5fc/0x1140
     worker_thread+0x7d8/0xe20
     kthread+0x25c/0x468
     ret_from_fork+0x10/0x20
    
    Signed-off-by: Alice Chao <alice.chao@mediatek.com>
    Link: https://lore.kernel.org/r/20240205104905.24929-1-alice.chao@mediatek.com
    Reviewed-by: Stanley Jhu <chu.stanley@gmail.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: core: Remove the ufshcd_release() in ufshcd_err_handling_prepare() [+ + +]
Author: SEO HOYOUNG <hy50.seo@samsung.com>
Date:   Mon Jan 22 17:33:24 2024 +0900

    scsi: ufs: core: Remove the ufshcd_release() in ufshcd_err_handling_prepare()
    
    [ Upstream commit 17e94b2585417e04dabc2f13bc03b4665ae687f3 ]
    
    If ufshcd_err_handler() is called in a suspend/resume situation,
    ufs_release() can be called twice and active_reqs end up going negative.
    This is because ufshcd_err_handling_prepare() and
    ufshcd_err_handling_unprepare() both call ufshcd_release().
    
    Remove superfluous call to ufshcd_release().
    
    Signed-off-by: SEO HOYOUNG <hy50.seo@samsung.com>
    Link: https://lore.kernel.org/r/20240122083324.11797-1-hy50.seo@samsung.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Can Guo <quic_cang@quicinc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: Uninitialized variable in ufshcd_devfreq_target() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Tue Feb 13 21:08:09 2024 +0300

    scsi: ufs: Uninitialized variable in ufshcd_devfreq_target()
    
    [ Upstream commit f2dced9d1992824d677593072bc20eccf66ac5d5 ]
    
    There is one goto where "sched_clk_scaling_suspend_work" is true but
    "scale_up" is uninitialized.  It leads to a Smatch uninitialized variable
    warning:
    
    drivers/ufs/core/ufshcd.c:1589 ufshcd_devfreq_target() error: uninitialized symbol 'scale_up'.
    
    Fixes: 1d969731b87f ("scsi: ufs: core: Only suspend clock scaling if scaling down")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/c787d37f-1107-4512-8991-bccf80e74a35@moroto.mountain
    Reviewed-by: Peter Wang <peter.wang@mediatek.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/iommu: fix the config fragment [+ + +]
Author: Muhammad Usama Anjum <usama.anjum@collabora.com>
Date:   Thu Feb 22 12:49:33 2024 +0500

    selftests/iommu: fix the config fragment
    
    [ Upstream commit 510325e5ac5f45c1180189d3bfc108c54bf64544 ]
    
    The config fragment doesn't follow the correct format to enable those
    config options which make the config options getting missed while
    merging with other configs.
    
    ➜ merge_config.sh -m .config tools/testing/selftests/iommu/config
    Using .config as base
    Merging tools/testing/selftests/iommu/config
    ➜ make olddefconfig
    .config:5295:warning: unexpected data: CONFIG_IOMMUFD
    .config:5296:warning: unexpected data: CONFIG_IOMMUFD_TEST
    
    While at it, add CONFIG_FAULT_INJECTION as well which is needed for
    CONFIG_IOMMUFD_TEST. If CONFIG_FAULT_INJECTION isn't present in base
    config (such as x86 defconfig), CONFIG_IOMMUFD_TEST doesn't get enabled.
    
    Fixes: 57f0988706fe ("iommufd: Add a selftest")
    Link: https://lore.kernel.org/r/20240222074934.71380-1-usama.anjum@collabora.com
    Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/mm: uffd-unit-test check if huge page size is 0 [+ + +]
Author: Terry Tritton <terry.tritton@linaro.org>
Date:   Mon Feb 5 14:50:56 2024 +0000

    selftests/mm: uffd-unit-test check if huge page size is 0
    
    commit 7efa6f2c803366f84c3c362f01e822490669d72b upstream.
    
    If HUGETLBFS is not enabled then the default_huge_page_size function will
    return 0 and cause a divide by 0 error. Add a check to see if the huge page
    size is 0 and skip the hugetlb tests if it is.
    
    Link: https://lkml.kernel.org/r/20240205145055.3545806-2-terry.tritton@linaro.org
    Fixes: 16a45b57cbf2 ("selftests/mm: add framework for uffd-unit-test")
    Signed-off-by: Terry Tritton <terry.tritton@linaro.org>
    Cc: Peter Griffin <peter.griffin@linaro.org>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests: bonding: set active slave to primary eth1 specifically [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu Feb 15 10:33:25 2024 +0800

    selftests: bonding: set active slave to primary eth1 specifically
    
    [ Upstream commit cd65c48d66920457129584553f217005d09b1edb ]
    
    In bond priority testing, we set the primary interface to eth1 and add
    eth0,1,2 to bond in serial. This is OK in normal times. But when in
    debug kernel, the bridge port that eth0,1,2 connected would start
    slowly (enter blocking, forwarding state), which caused the primary
    interface down for a while after enslaving and active slave changed.
    Here is a test log from Jakub's debug test[1].
    
     [  400.399070][   T50] br0: port 1(s0) entered disabled state
     [  400.400168][   T50] br0: port 4(s2) entered disabled state
     [  400.941504][ T2791] bond0: (slave eth0): making interface the new active one
     [  400.942603][ T2791] bond0: (slave eth0): Enslaving as an active interface with an up link
     [  400.943633][ T2766] br0: port 1(s0) entered blocking state
     [  400.944119][ T2766] br0: port 1(s0) entered forwarding state
     [  401.128792][ T2792] bond0: (slave eth1): making interface the new active one
     [  401.130771][ T2792] bond0: (slave eth1): Enslaving as an active interface with an up link
     [  401.131643][   T69] br0: port 2(s1) entered blocking state
     [  401.132067][   T69] br0: port 2(s1) entered forwarding state
     [  401.346201][ T2793] bond0: (slave eth2): Enslaving as a backup interface with an up link
     [  401.348414][   T50] br0: port 4(s2) entered blocking state
     [  401.348857][   T50] br0: port 4(s2) entered forwarding state
     [  401.519669][  T250] bond0: (slave eth0): link status definitely down, disabling slave
     [  401.526522][  T250] bond0: (slave eth1): link status definitely down, disabling slave
     [  401.526986][  T250] bond0: (slave eth2): making interface the new active one
     [  401.629470][  T250] bond0: (slave eth0): link status definitely up
     [  401.630089][  T250] bond0: (slave eth1): link status definitely up
     [...]
     # TEST: prio (active-backup ns_ip6_target primary_reselect 1)         [FAIL]
     # Current active slave is eth2 but not eth1
    
    Fix it by setting active slave to primary slave specifically before
    testing.
    
    [1] https://netdev-3.bots.linux.dev/vmksft-bonding-dbg/results/464301/1-bond-options-sh/stdout
    
    Fixes: 481b56e0391e ("selftests: bonding: re-format bond option tests")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: mptcp: add mptcp_lib_get_counter [+ + +]
Author: Geliang Tang <geliang@kernel.org>
Date:   Tue Nov 28 15:18:55 2023 -0800

    selftests: mptcp: add mptcp_lib_get_counter
    
    commit 61c131f5d4d2b79904af2fdcb2839a9db8e7c55c upstream.
    
    To avoid duplicated code in different MPTCP selftests, we can add
    and use helpers defined in mptcp_lib.sh.
    
    The helper get_counter() in mptcp_join.sh and get_mib_counter() in
    mptcp_connect.sh have the same functionality, export get_counter() into
    mptcp_lib.sh and rename it as mptcp_lib_get_counter(). Use this new
    helper instead of get_counter() and get_mib_counter().
    
    Use this helper in test_prio() in userspace_pm.sh too instead of
    open-coding.
    
    Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
    Signed-off-by: Geliang Tang <geliang.tang@suse.com>
    Signed-off-by: Mat Martineau <martineau@kernel.org>
    Link: https://lore.kernel.org/r/20231128-send-net-next-2023107-v4-11-8d6b94150f6b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: diag: check CURRESTAB counters [+ + +]
Author: Geliang Tang <geliang@kernel.org>
Date:   Fri Dec 22 13:47:25 2023 +0100

    selftests: mptcp: diag: check CURRESTAB counters
    
    commit 81ab772819da408977ac79c0a17d8be57283379f upstream.
    
    This patch adds a new helper chk_msk_cestab() to check the current
    established connections counter MIB_CURRESTAB in diag.sh. Invoke it
    to check the counter during the connection after every chk_msk_inuse().
    
    Signed-off-by: Geliang Tang <geliang.tang@linux.dev>
    Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: diag: fix bash warnings on older kernels [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Thu Feb 15 19:25:36 2024 +0100

    selftests: mptcp: diag: fix bash warnings on older kernels
    
    commit 694bd45980a61045eb5ec07799e3b94c76db830e upstream.
    
    Since the 'Fixes' commit mentioned below, the command that is executed
    in __chk_nr() helper can return nothing if the feature is not supported.
    This is the case when the MPTCP CURRESTAB counter is not supported.
    
    To avoid this warning ...
    
      ./diag.sh: line 65: [: !=: unary operator expected
    
    ... we just need to surround '$nr' with double quotes, to support an
    empty string when the feature is not supported.
    
    Fixes: 81ab772819da ("selftests: mptcp: diag: check CURRESTAB counters")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@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>

selftests: mptcp: diag: unique 'cestab' subtest names [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Thu Feb 15 19:25:40 2024 +0100

    selftests: mptcp: diag: unique 'cestab' subtest names
    
    commit 4103d8480866fe5abb71ef0ed8af3a3b7b9625bf upstream.
    
    It is important to have a unique (sub)test name in TAP, because some CI
    environments drop tests with duplicated name.
    
    Some 'cestab' subtests from the diag selftest had the same names, e.g.:
    
        ....chk 0 cestab
    
    Now the previous value is taken, to have different names, e.g.:
    
        ....chk 2->0 cestab after flush
    
    While at it, the 'after flush' info is added, similar to what is done
    with the 'in use' subtests. Also inspired by these 'in use' subtests,
    'many' is displayed instead of a large number:
    
        many msk socket present                           [  ok  ]
        ....chk many msk in use                           [  ok  ]
        ....chk many cestab                               [  ok  ]
        ....chk many->0 msk in use after flush            [  ok  ]
        ....chk many->0 cestab after flush                [  ok  ]
    
    Fixes: 81ab772819da ("selftests: mptcp: diag: check CURRESTAB counters")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@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>

selftests: mptcp: diag: unique 'in use' subtest names [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Thu Feb 15 19:25:39 2024 +0100

    selftests: mptcp: diag: unique 'in use' subtest names
    
    commit 645c1dc965ef6b5554e5e69737bb179c7a0f872f upstream.
    
    It is important to have a unique (sub)test name in TAP, because some CI
    environments drop tests with duplicated name.
    
    Some 'in use' subtests from the diag selftest had the same names, e.g.:
    
        chk 0 msk in use after flush
    
    Now the previous value is taken, to have different names, e.g.:
    
        chk 2->0 msk in use after flush
    
    While at it, avoid repeating the full message, declare it once in the
    helper.
    
    Fixes: ce9902573652 ("selftests: mptcp: diag: format subtests results in TAP")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@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>

selftests: mptcp: join: stop transfer when check is done (part 1) [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Jan 31 22:49:53 2024 +0100

    selftests: mptcp: join: stop transfer when check is done (part 1)
    
    commit 31ee4ad86afd6ed6f4bb1b38c43011216080c42a upstream.
    
    Since the "Fixes" commit mentioned below, "userspace pm" subtests of
    mptcp_join selftests introduced in v6.5 are launching the whole transfer
    in the background, do the required checks, then wait for the end of
    transfer.
    
    There is no need to wait longer, especially because the checks at the
    end of the transfer are ignored (which is fine). This saves quite a few
    seconds in slow environments.
    
    Note that old versions will need commit bdbef0a6ff10 ("selftests: mptcp:
    add mptcp_lib_kill_wait") as well to get 'mptcp_lib_kill_wait()' helper.
    
    Fixes: 4369c198e599 ("selftests: mptcp: test userspace pm out of transfer")
    Cc: stable@vger.kernel.org # 6.5.x: bdbef0a6ff10: selftests: mptcp: add mptcp_lib_kill_wait
    Cc: stable@vger.kernel.org # 6.5.x
    Reviewed-and-tested-by: Geliang Tang <geliang@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240131-upstream-net-20240131-mptcp-ci-issues-v1-8-4c1c11e571ff@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: join: stop transfer when check is done (part 2) [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Jan 31 22:49:54 2024 +0100

    selftests: mptcp: join: stop transfer when check is done (part 2)
    
    commit 04b57c9e096a9479fe0ad31e3956e336fa589cb2 upstream.
    
    Since the "Fixes" commits mentioned below, the newly added "userspace
    pm" subtests of mptcp_join selftests are launching the whole transfer in
    the background, do the required checks, then wait for the end of
    transfer.
    
    There is no need to wait longer, especially because the checks at the
    end of the transfer are ignored (which is fine). This saves quite a few
    seconds on slow environments.
    
    While at it, use 'mptcp_lib_kill_wait()' helper everywhere, instead of
    on a specific one with 'kill_tests_wait()'.
    
    Fixes: b2e2248f365a ("selftests: mptcp: userspace pm create id 0 subflow")
    Fixes: e3b47e460b4b ("selftests: mptcp: userspace pm remove initial subflow")
    Fixes: b9fb176081fb ("selftests: mptcp: userspace pm send RM_ADDR for ID 0")
    Cc: stable@vger.kernel.org
    Reviewed-and-tested-by: Geliang Tang <geliang@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240131-upstream-net-20240131-mptcp-ci-issues-v1-9-4c1c11e571ff@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: pm nl: also list skipped tests [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Thu Feb 15 19:25:34 2024 +0100

    selftests: mptcp: pm nl: also list skipped tests
    
    commit d2a2547565a9f1ad7989f7e21f97cbf065a9390d upstream.
    
    If the feature is not supported by older kernels, and instead of just
    ignoring some tests, we should mark them as skipped, so we can still
    track them.
    
    Fixes: d85555ac11f9 ("selftests: mptcp: pm_netlink: format subtests results in TAP")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@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>

selftests: mptcp: pm nl: avoid error msg on older kernels [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Thu Feb 15 19:25:35 2024 +0100

    selftests: mptcp: pm nl: avoid error msg on older kernels
    
    commit 662f084f3396d8a804d56cb53ac05c9e39902a7b upstream.
    
    Since the 'Fixes' commit mentioned below, and if the kernel being tested
    doesn't support the 'fullmesh' flag, this error will be printed:
    
      netlink error -22 (Invalid argument)
      ./pm_nl_ctl: bailing out due to netlink error[s]
    
    But that can be normal if the kernel doesn't support the feature, no
    need to print this worrying error message while everything else looks
    OK. So we can mute stderr. Failures will still be detected if any.
    
    Fixes: 1dc88d241f92 ("selftests: mptcp: pm_nl_ctl: always look for errors")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@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>

selftests: mptcp: simult flows: fix some subtest names [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Thu Feb 15 19:25:37 2024 +0100

    selftests: mptcp: simult flows: fix some subtest names
    
    commit 4d8e0dde0403b5a86aa83e243f020711a9c3e31f upstream.
    
    The selftest was correctly recording all the results, but the 'reverse
    direction' part was missing in the name when needed.
    
    It is important to have a unique (sub)test name in TAP, because some CI
    environments drop tests with duplicated name.
    
    Fixes: 675d99338e7a ("selftests: mptcp: simult flows: format subtests results in TAP")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@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>

selftests: mptcp: userspace_pm: unique subtest names [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Thu Feb 15 19:25:38 2024 +0100

    selftests: mptcp: userspace_pm: unique subtest names
    
    commit 2ef0d804c090658960c008446523863fd7e3541e upstream.
    
    It is important to have a unique (sub)test name in TAP, because some CI
    environments drop tests with duplicated names.
    
    Some subtests from the userspace_pm selftest had the same names. That's
    because different subflows are created (and deleted) between the same
    pair of IP addresses.
    
    Simply adding the destination port in the name is then enough to have
    different names, because the destination port is always different.
    
    Note that adding such info takes a bit more space, so we need to
    increase a bit the width to print the name, simply to keep all the
    '[ OK ]' aligned as before.
    
    Fixes: f589234e1af0 ("selftests: mptcp: userspace_pm: format subtests results in TAP")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@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>

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

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

serial: stm32: do not always set SER_RS485_RX_DURING_TX if RS485 is enabled [+ + +]
Author: Lino Sanfilippo <l.sanfilippo@kunbus.com>
Date:   Fri Feb 16 23:47:07 2024 +0100

    serial: stm32: do not always set SER_RS485_RX_DURING_TX if RS485 is enabled
    
    commit f418ae73311deb901c0110b08d1bbafc20c1820e upstream.
    
    Before commit 07c30ea5861f ("serial: Do not hold the port lock when setting
    rx-during-tx GPIO") the SER_RS485_RX_DURING_TX flag was only set if the
    rx-during-tx mode was not controlled by a GPIO. Now the flag is set
    unconditionally when RS485 is enabled. This results in an incorrect setting
    if the rx-during-tx GPIO is not asserted.
    
    Fix this by setting the flag only if the rx-during-tx mode is not
    controlled by a GPIO and thus restore the correct behaviour.
    
    Cc: stable@vger.kernel.org # 6.6+
    Fixes: 07c30ea5861f ("serial: Do not hold the port lock when setting rx-during-tx GPIO")
    Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
    Link: https://lore.kernel.org/r/20240216224709.9928-1-l.sanfilippo@kunbus.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smb3: add missing null server pointer check [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Mon Feb 5 14:43:17 2024 -0600

    smb3: add missing null server pointer check
    
    commit 45be0882c5f91e1b92e645001dd1a53b3bd58c97 upstream.
    
    Address static checker warning in cifs_ses_get_chan_index():
        warn: variable dereferenced before check 'server'
    To be consistent, and reduce risk, we should add another check
    for null server pointer.
    
    Fixes: 88675b22d34e ("cifs: do not search for channel if server is terminating")
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

smb3: clarify mount warning [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Tue Feb 6 23:57:18 2024 -0600

    smb3: clarify mount warning
    
    [ Upstream commit a5cc98eba2592d6e3c5a4351319595ddde2a5901 ]
    
    When a user tries to use the "sec=krb5p" mount parameter to encrypt
    data on connection to a server (when authenticating with Kerberos), we
    indicate that it is not supported, but do not note the equivalent
    recommended mount parameter ("sec=krb5,seal") which turns on encryption
    for that mount (and uses Kerberos for auth).  Update the warning message.
    
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
smb: client: increase number of PDUs allowed in a compound request [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Mon Jan 29 21:04:44 2024 -0300

    smb: client: increase number of PDUs allowed in a compound request
    
    [ Upstream commit 11d4d1dba3315f73d2d1d386f5bf4811a8241d45 ]
    
    With the introduction of SMB2_OP_QUERY_WSL_EA, the client may now send
    5 commands in a single compound request in order to query xattrs from
    potential WSL reparse points, which should be fine as we currently
    allow up to 5 PDUs in a single compound request.  However, if
    encryption is enabled (e.g. 'seal' mount option) or enforced by the
    server, current MAX_COMPOUND(5) won't be enough as we require an extra
    PDU for the transform header.
    
    Fix this by increasing MAX_COMPOUND to 7 and, while we're at it, add
    an WARN_ON_ONCE() and return -EIO instead of -ENOMEM in case we
    attempt to send a compound request that couldn't include the extra
    transform header.
    
    Signed-off-by: Paulo Alcantara <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

smb: client: set correct d_type for reparse points under DFS mounts [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Fri Feb 2 12:38:24 2024 -0300

    smb: client: set correct d_type for reparse points under DFS mounts
    
    [ Upstream commit 55c7788c37242702868bfac7861cdf0c358d6c3d ]
    
    Send query dir requests with an info level of
    SMB_FIND_FILE_FULL_DIRECTORY_INFO rather than
    SMB_FIND_FILE_DIRECTORY_INFO when the client is generating its own
    inode numbers (e.g. noserverino) so that reparse tags still
    can be parsed directly from the responses, but server won't
    send UniqueId (server inode number)
    
    Signed-off-by: Paulo Alcantara <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

smb: Work around Clang __bdos() type confusion [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jan 23 15:47:34 2024 -0800

    smb: Work around Clang __bdos() type confusion
    
    [ Upstream commit 8deb05c84b63b4fdb8549e08942867a68924a5b8 ]
    
    Recent versions of Clang gets confused about the possible size of the
    "user" allocation, and CONFIG_FORTIFY_SOURCE ends up emitting a
    warning[1]:
    
    repro.c:126:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
      126 |                         __write_overflow_field(p_size_field, size);
          |                         ^
    
    for this memset():
    
            int len;
            __le16 *user;
            ...
            len = ses->user_name ? strlen(ses->user_name) : 0;
            user = kmalloc(2 + (len * 2), GFP_KERNEL);
            ...
            if (len) {
                    ...
            } else {
                    memset(user, '\0', 2);
            }
    
    While Clang works on this bug[2], switch to using a direct assignment,
    which avoids memset() entirely which both simplifies the code and silences
    the false positive warning. (Making "len" size_t also silences the
    warning, but the direct assignment seems better.)
    
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Closes: https://github.com/ClangBuiltLinux/linux/issues/1966 [1]
    Link: https://github.com/llvm/llvm-project/issues/77813 [2]
    Cc: Steve French <sfrench@samba.org>
    Cc: Paulo Alcantara <pc@manguebit.com>
    Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
    Cc: Shyam Prasad N <sprasad@microsoft.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: linux-cifs@vger.kernel.org
    Cc: llvm@lists.linux.dev
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sparc: Fix undefined reference to fb_is_primary_device [+ + +]
Author: Javier Martinez Canillas <javierm@redhat.com>
Date:   Tue Feb 20 10:54:12 2024 +0100

    sparc: Fix undefined reference to fb_is_primary_device
    
    commit ed683b9bb91fc274383e222ba5873a9ee9033462 upstream.
    
    Commit 55bffc8170bb ("fbdev: Split frame buffer support in FB and FB_CORE
    symbols") added a new FB_CORE Kconfig symbol, that can be enabled to only
    have fbcon/VT and DRM fbdev emulation, but without support for any legacy
    fbdev driver.
    
    Unfortunately, it missed to change the CONFIG_FB in arch/sparc makefiles,
    which leads to the following linking error in some sparc64 configurations:
    
       sparc64-linux-ld: drivers/video/fbdev/core/fbcon.o: in function `fbcon_fb_registered':
    >> fbcon.c:(.text+0x4f60): undefined reference to `fb_is_primary_device'
    
    Fixes: 55bffc8170bb ("fbdev: Split frame buffer support in FB and FB_CORE symbols")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/r/202401290306.IV8rhJ02-lkp@intel.com/
    Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Cc: <stable@vger.kernel.org> # v6.6+
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240220095428.3341195-1-javierm@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
spi: cs42l43: Handle error from devm_pm_runtime_enable [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Wed Jan 24 17:41:01 2024 +0000

    spi: cs42l43: Handle error from devm_pm_runtime_enable
    
    [ Upstream commit f9f4b0c6425eb9ffd9bf62b8b8143e786b6ba695 ]
    
    As it devm_pm_runtime_enable can fail due to memory allocations, it is
    best to handle the error.
    
    Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://msgid.link/r/20240124174101.2270249-1-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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: intel-pci: Add support for Arrow Lake SPI serial flash [+ + +]
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Mon Jan 22 14:00:34 2024 +0200

    spi: intel-pci: Add support for Arrow Lake SPI serial flash
    
    [ Upstream commit 8afe3c7fcaf72fca1e7d3dab16a5b7f4201ece17 ]
    
    This adds the PCI ID of the Arrow Lake and Meteor Lake-S PCH SPI serial
    flash controller. This one supports all the necessary commands Linux
    SPI-NOR stack requires.
    
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Link: https://msgid.link/r/20240122120034.2664812-3-mika.westerberg@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
tls: break out of main loop when PEEK gets a non-data record [+ + +]
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Thu Feb 15 17:17:29 2024 +0100

    tls: break out of main loop when PEEK gets a non-data record
    
    [ Upstream commit 10f41d0710fc81b7af93fa6106678d57b1ff24a7 ]
    
    PEEK needs to leave decrypted records on the rx_list so that we can
    receive them later on, so it jumps back into the async code that
    queues the skb. Unfortunately that makes us skip the
    TLS_RECORD_TYPE_DATA check at the bottom of the main loop, so if two
    records of the same (non-DATA) type are queued, we end up merging
    them.
    
    Add the same record type check, and make it unlikely to not penalize
    the async fastpath. Async decrypt only applies to data record, so this
    check is only needed for PEEK.
    
    process_rx_list also has similar issues.
    
    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/3df2eef4fdae720c55e69472b5bea668772b45a2.1708007371.git.sd@queasysnail.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tls: don't skip over different type records from the rx_list [+ + +]
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Thu Feb 15 17:17:31 2024 +0100

    tls: don't skip over different type records from the rx_list
    
    [ Upstream commit ec823bf3a479d42c589dc0f28ef4951c49cd2d2a ]
    
    If we queue 3 records:
     - record 1, type DATA
     - record 2, some other type
     - record 3, type DATA
    and do a recv(PEEK), the rx_list will contain the first two records.
    
    The next large recv will walk through the rx_list and copy data from
    record 1, then stop because record 2 is a different type. Since we
    haven't filled up our buffer, we will process the next available
    record. It's also DATA, so we can merge it with the current read.
    
    We shouldn't do that, since there was a record in between that we
    ignored.
    
    Add a flag to let process_rx_list inform tls_sw_recvmsg that it had
    more data available.
    
    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/f00c0c0afa080c60f016df1471158c1caf983c34.1708007371.git.sd@queasysnail.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
tools: selftests: riscv: Fix compile warnings in cbo [+ + +]
Author: Christoph Müllner <christoph.muellner@vrull.eu>
Date:   Thu Nov 23 19:58:18 2023 +0100

    tools: selftests: riscv: Fix compile warnings in cbo
    
    [ Upstream commit ac7b2a02d62faff8c6d45bacb5cb9ea565b47776 ]
    
    GCC prints a couple of format string warnings when compiling
    the cbo test. Let's follow the recommendation in
    Documentation/printk-formats.txt to fix these warnings.
    
    Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
    Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Link: https://lore.kernel.org/r/20231123185821.2272504-3-christoph.muellner@vrull.eu
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tools: selftests: riscv: Fix compile warnings in hwprobe [+ + +]
Author: Christoph Müllner <christoph.muellner@vrull.eu>
Date:   Thu Nov 23 19:58:17 2023 +0100

    tools: selftests: riscv: Fix compile warnings in hwprobe
    
    [ Upstream commit b91c26fdb0e8150cdb610cdaadea62bb5e43bee0 ]
    
    GCC prints a couple of format string warnings when compiling
    the hwprobe test. Let's follow the recommendation in
    Documentation/printk-formats.txt to fix these warnings.
    
    Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
    Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Link: https://lore.kernel.org/r/20231123185821.2272504-2-christoph.muellner@vrull.eu
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tools: selftests: riscv: Fix compile warnings in mm tests [+ + +]
Author: Christoph Müllner <christoph.muellner@vrull.eu>
Date:   Thu Nov 23 19:58:21 2023 +0100

    tools: selftests: riscv: Fix compile warnings in mm tests
    
    [ Upstream commit 12c16919652b5873f524c8b361336ecfa5ce5e6b ]
    
    When building the mm tests with a riscv32 compiler, we see a range
    of shift-count-overflow errors from shifting 1UL by more than 32 bits
    in do_mmaps(). Since, the relevant code is only called from code that
    is gated by `__riscv_xlen == 64`, we can just apply the same gating
    to do_mmaps().
    
    Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
    Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Link: https://lore.kernel.org/r/20231123185821.2272504-6-christoph.muellner@vrull.eu
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tools: selftests: riscv: Fix compile warnings in vector tests [+ + +]
Author: Christoph Müllner <christoph.muellner@vrull.eu>
Date:   Thu Nov 23 19:58:20 2023 +0100

    tools: selftests: riscv: Fix compile warnings in vector tests
    
    [ Upstream commit e1baf5e68ed128c1e22ba43e5190526d85de323c ]
    
    GCC prints a couple of format string warnings when compiling
    the vector tests. Let's follow the recommendation in
    Documentation/printk-formats.txt to fix these warnings.
    
    Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
    Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Link: https://lore.kernel.org/r/20231123185821.2272504-5-christoph.muellner@vrull.eu
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tools: ynl: don't leak mcast_groups on init error [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Tue Feb 20 08:11:12 2024 -0800

    tools: ynl: don't leak mcast_groups on init error
    
    [ Upstream commit 5d78b73e851455d525a064f3b042b29fdc0c1a4a ]
    
    Make sure to free the already-parsed mcast_groups if
    we don't get an ack from the kernel when reading family info.
    This is part of the ynl_sock_create() error path, so we won't
    get a call to ynl_sock_destroy() to free them later.
    
    Fixes: 86878f14d71a ("tools: ynl: user space helpers")
    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Link: https://lore.kernel.org/r/20240220161112.2735195-3-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tools: ynl: make sure we always pass yarg to mnl_cb_run [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Tue Feb 20 08:11:11 2024 -0800

    tools: ynl: make sure we always pass yarg to mnl_cb_run
    
    [ Upstream commit e4fe082c38cd74a8fa384bc7542cf3edf1cb7318 ]
    
    There is one common error handler in ynl - ynl_cb_error().
    It expects priv to be a pointer to struct ynl_parse_arg AKA yarg.
    To avoid potential crashes if we encounter a stray NLMSG_ERROR
    always pass yarg as priv (or a struct which has it as the first
    member).
    
    ynl_cb_null() has a similar problem directly - it expects yarg
    but priv passed by the caller is ys.
    
    Found by code inspection.
    
    Fixes: 86878f14d71a ("tools: ynl: user space helpers")
    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Link: https://lore.kernel.org/r/20240220161112.2735195-2-kuba@kernel.org
    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: cdnsp: blocked some cdns3 specific code [+ + +]
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Tue Feb 6 11:40:18 2024 +0100

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

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

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

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

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

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

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

usb: gadget: omap_udc: fix USB gadget regression on Palm TE [+ + +]
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Sat Feb 17 21:20:42 2024 +0200

    usb: gadget: omap_udc: fix USB gadget regression on Palm TE
    
    commit 858a74cb512833e276d96a72acb560ce8c138bec upstream.
    
    When upgrading from 6.1 LTS to 6.6 LTS, I noticed the ethernet gadget
    stopped working on Palm TE.
    
    Commit 8825acd7cc8a ("ARM: omap1: remove dead code") deleted Palm TE from
    machine_without_vbus_sense(), although the board is still used. Fix that.
    
    Fixes: 8825acd7cc8a ("ARM: omap1: remove dead code")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20240217192042.GA372205@darkstar.musicnaut.iki.fi
    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>

usb: ucsi_acpi: Quirk to ack a connector change ack cmd [+ + +]
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Sun Jan 21 21:41:23 2024 +0100

    usb: ucsi_acpi: Quirk to ack a connector change ack cmd
    
    [ Upstream commit f3be347ea42dbb0358cd8b2d8dc543a23b70a976 ]
    
    The PPM on some Dell laptops seems to expect that the ACK_CC_CI
    command to clear the connector change notification is in turn
    followed by another ACK_CC_CI to acknowledge the ACK_CC_CI command
    itself. This is in violation of the UCSI spec that states:
    
        "The only notification that is not acknowledged by the OPM is
         the command completion notification for the ACK_CC_CI or the
         PPM_RESET command."
    
    Add a quirk to send this ack anyway.
    Apply the quirk to all Dell systems.
    
    On the first command that acks a connector change send a dummy
    command to determine if it runs into a timeout. Only activate
    the quirk if it does. This ensure that we do not break Dell
    systems that do not need the quirk.
    
    Signed-off-by: "Christian A. Ehrhardt" <lk@c--e.de>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240121204123.275441-4-lk@c--e.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

wifi: iwlwifi: do not announce EPCS support [+ + +]
Author: Benjamin Berg <benjamin.berg@intel.com>
Date:   Thu Feb 1 16:17:30 2024 +0200

    wifi: iwlwifi: do not announce EPCS support
    
    [ Upstream commit a23c0af103e184bb1252dddddda040f6641bea7b ]
    
    mac80211 does not have proper support for EPCS currently as that would
    require changing the ECDA parameters if EPCS (Emergency Preparedness
    Communications Service) is in use. As such, do not announce support for
    it in the capabilities.
    
    Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240201155157.59d71656addc.Idde91b3018239c49fc6ed231b411d05354fb9fb1@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: accept broadcast probe responses on 6 GHz [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jan 29 20:09:07 2024 +0100

    wifi: mac80211: accept broadcast probe responses on 6 GHz
    
    [ Upstream commit 62a6183c13319e4d2227473a04abd104c4f56dcf ]
    
    On the 6 GHz band, probe responses are sent as broadcast to
    optimise medium usage. However, without OCE configuration
    we weren't accepting them, which is wrong, even if wpa_s is
    by default enabling OCE. Accept them without the OCE config
    as well.
    
    Link: https://msgid.link/20240129200907.5a89c2821897.I92e9dfa0f9b350bc7f37dd4bb38031d156d78d8a@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

wifi: mac80211: fix driver debugfs for vif type change [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jan 29 15:54:02 2024 +0100

    wifi: mac80211: fix driver debugfs for vif type change
    
    [ Upstream commit 733c498a80853acbafe284a40468b91f4d41f0b4 ]
    
    If a driver implements the change_interface() method, we switch
    interface type without taking the interface down, but still will
    recreate the debugfs for it since it's a new type. As such, we
    should use the ieee80211_debugfs_recreate_netdev() function here
    to also recreate the driver's files, if it is indeed from a type
    change while up.
    
    Link: https://msgid.link/20240129155402.7311a36ffeeb.I18df02bbeb685d4250911de5ffbaf090f60c3803@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

wifi: mac80211: initialize SMPS mode correctly [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jan 29 19:54:05 2024 +0100

    wifi: mac80211: initialize SMPS mode correctly
    
    [ Upstream commit 86b2dac224f963be92634a878888222e1e938f48 ]
    
    The SMPS mode is currently re-initialized too late, since
    ieee80211_prep_channel() can be called again after we've
    already done ieee80211_setup_assoc_link(), in case there's
    some override of the channel configuration. Fix this.
    
    Link: https://msgid.link/20240129195405.d6d74508be18.I0a7303b1ce4d8e5436011951ab624372a445c069@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: set station RX-NSS on reconfig [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jan 29 15:53:55 2024 +0100

    wifi: mac80211: set station RX-NSS on reconfig
    
    [ Upstream commit dd6c064cfc3fc18d871107c6f5db8837e88572e4 ]
    
    When a station is added/reconfigured by userspace, e.g. a TDLS
    peer or a SoftAP client STA, rx_nss is currently not always set,
    so that it might be left zero. Set it up properly.
    
    Link: https://msgid.link/20240129155354.98f148a3d654.I193a02155f557ea54dc9d0232da66cf96734119a@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/bugs: Add asm helpers for executing VERW [+ + +]
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Tue Feb 13 18:21:35 2024 -0800

    x86/bugs: Add asm helpers for executing VERW
    
    commit baf8361e54550a48a7087b603313ad013cc13386 upstream.
    
    MDS mitigation requires clearing the CPU buffers before returning to
    user. This needs to be done late in the exit-to-user path. Current
    location of VERW leaves a possibility of kernel data ending up in CPU
    buffers for memory accesses done after VERW such as:
    
      1. Kernel data accessed by an NMI between VERW and return-to-user can
         remain in CPU buffers since NMI returning to kernel does not
         execute VERW to clear CPU buffers.
      2. Alyssa reported that after VERW is executed,
         CONFIG_GCC_PLUGIN_STACKLEAK=y scrubs the stack used by a system
         call. Memory accesses during stack scrubbing can move kernel stack
         contents into CPU buffers.
      3. When caller saved registers are restored after a return from
         function executing VERW, the kernel stack accesses can remain in
         CPU buffers(since they occur after VERW).
    
    To fix this VERW needs to be moved very late in exit-to-user path.
    
    In preparation for moving VERW to entry/exit asm code, create macros
    that can be used in asm. Also make VERW patching depend on a new feature
    flag X86_FEATURE_CLEAR_CPU_BUF.
    
    Reported-by: Alyssa Milburn <alyssa.milburn@intel.com>
    Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Link: https://lore.kernel.org/all/20240213-delay-verw-v8-1-a6216d83edb7%40linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/numa: Fix the address overlap check in numa_fill_memblks() [+ + +]
Author: Alison Schofield <alison.schofield@intel.com>
Date:   Fri Jan 12 12:09:50 2024 -0800

    x86/numa: Fix the address overlap check in numa_fill_memblks()
    
    [ Upstream commit 9b99c17f7510bed2adbe17751fb8abddba5620bc ]
    
    numa_fill_memblks() fills in the gaps in numa_meminfo memblks over a
    physical address range. To do so, it first creates a list of existing
    memblks that overlap that address range. The issue is that it is off
    by one when comparing to the end of the address range, so memblks
    that do not overlap are selected.
    
    The impact of selecting a memblk that does not actually overlap is
    that an existing memblk may be filled when the expected action is to
    do nothing and return NUMA_NO_MEMBLK to the caller. The caller can
    then add a new NUMA node and memblk.
    
    Replace the broken open-coded search for address overlap with the
    memblock helper memblock_addrs_overlap(). Update the kernel doc
    and in code comments.
    
    Suggested by: "Huang, Ying" <ying.huang@intel.com>
    
    Fixes: 8f012db27c95 ("x86/numa: Introduce numa_fill_memblks()")
    Signed-off-by: Alison Schofield <alison.schofield@intel.com>
    Acked-by: Mike Rapoport (IBM) <rppt@kernel.org>
    Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Link: https://lore.kernel.org/r/10a3e6109c34c21a8dd4c513cf63df63481a2b07.1705085543.git.alison.schofield@intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

x86/numa: Fix the sort compare func used in numa_fill_memblks() [+ + +]
Author: Alison Schofield <alison.schofield@intel.com>
Date:   Fri Jan 12 12:09:51 2024 -0800

    x86/numa: Fix the sort compare func used in numa_fill_memblks()
    
    [ Upstream commit b626070ffc14acca5b87a2aa5f581db98617584c ]
    
    The compare function used to sort memblks into starting address
    order fails when the result of its u64 address subtraction gets
    truncated to an int upon return.
    
    The impact of the bad sort is that memblks will be filled out
    incorrectly. Depending on the set of memblks, a user may see no
    errors at all but still have a bad fill, or see messages reporting
    a node overlap that leads to numa init failure:
    
    [] node 0 [mem: ] overlaps with node 1 [mem: ]
    [] No NUMA configuration found
    
    Replace with a comparison that can only result in: 1, 0, -1.
    
    Fixes: 8f012db27c95 ("x86/numa: Introduce numa_fill_memblks()")
    Signed-off-by: Alison Schofield <alison.schofield@intel.com>
    Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Link: https://lore.kernel.org/r/99dcb3ae87e04995e9f293f6158dc8fa0749a487.1705085543.git.alison.schofield@intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xsk: Add truesize to skb_add_rx_frag(). [+ + +]
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Fri Feb 2 17:32:20 2024 +0100

    xsk: Add truesize to skb_add_rx_frag().
    
    [ Upstream commit 2127c604383666675789fd4a5fc2aead46c73aad ]
    
    xsk_build_skb() allocates a page and adds it to the skb via
    skb_add_rx_frag() and specifies 0 for truesize. This leads to a warning
    in skb_add_rx_frag() with CONFIG_DEBUG_NET enabled because size is
    larger than truesize.
    
    Increasing truesize requires to add the same amount to socket's
    sk_wmem_alloc counter in order not to underflow the counter during
    release in the destructor (sock_wfree()).
    
    Pass the size of the allocated page as truesize to skb_add_rx_frag().
    Add this mount to socket's sk_wmem_alloc counter.
    
    Fixes: cf24f5a5feea ("xsk: add support for AF_XDP multi-buffer on Tx path")
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Link: https://lore.kernel.org/bpf/20240202163221.2488589-1-bigeasy@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>