Linux 5.4.270

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

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

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

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

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

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

 
ALSA: hda/realtek - Enable micmute LED on and HP system [+ + +]
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Thu Apr 30 16:32:52 2020 +0800

    ALSA: hda/realtek - Enable micmute LED on and HP system
    
    [ Upstream commit 3e0650ab26e2010ee312311612e40e076ed1feca ]
    
    Though the system uses DMIC, headset mic still uses the HDA, let's use
    GPIO 0x1 to control the micmute LED.
    
    The micmute LED GPIO has a different polarity to the mute LED GPIO, we
    can use the newly added micmute_led_polarity to indicate that.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Link: https://lore.kernel.org/r/20200430083255.5093-2-kai.heng.feng@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: qcom: msm8916: Fix typo in pronto remoteproc node [+ + +]
Author: Sireesh Kodali <sireeshkodali1@gmail.com>
Date:   Thu May 26 19:47:40 2022 +0530

    arm64: dts: qcom: msm8916: Fix typo in pronto remoteproc node
    
    [ Upstream commit 5458d6f2827cd30218570f266b8d238417461f2f ]
    
    The smem-state properties for the pronto node were incorrectly labelled,
    reading `qcom,state*` rather than `qcom,smem-state*`. Fix that, allowing
    the stop state to be used.
    
    Fixes: 88106096cbf8 ("ARM: dts: msm8916: Add and enable wcnss node")
    Signed-off-by: Sireesh Kodali <sireeshkodali1@gmail.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220526141740.15834-3-sireeshkodali1@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>

 
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>

 
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>

 
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-integrity: don't modify bio's immutable bio_vec in integrity_metadata() [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Dec 5 16:39:16 2023 +0100

    dm-integrity: don't modify bio's immutable bio_vec in integrity_metadata()
    
    commit b86f4b790c998afdbc88fe1aa55cfe89c4068726 upstream.
    
    __bio_for_each_segment assumes that the first struct bio_vec argument
    doesn't change - it calls "bio_advance_iter_single((bio), &(iter),
    (bvl).bv_len)" to advance the iterator. Unfortunately, the dm-integrity
    code changes the bio_vec with "bv.bv_len -= pos". When this code path
    is taken, the iterator would be out of sync and dm-integrity would
    report errors. This happens if the machine is out of memory and
    "kmalloc" fails.
    
    Fix this bug by making a copy of "bv" and changing the copy instead.
    
    Fixes: 7eada909bfd7 ("dm: add integrity target")
    Cc: stable@vger.kernel.org      # v4.12+
    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>
    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>

 
drm/amdgpu: Check for valid number of registers to read [+ + +]
Author: Trek <trek00@inbox.ru>
Date:   Sat Aug 31 21:25:36 2019 +0200

    drm/amdgpu: Check for valid number of registers to read
    
    [ Upstream commit 13238d4fa6764fa74dcf863d5f2227765b3753eb ]
    
    Do not try to allocate any amount of memory requested by the user.
    Instead limit it to 128 registers. Actually the longest series of
    consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
    mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).
    
    Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273
    Signed-off-by: Trek <trek00@inbox.ru>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Fix type of second parameter in trans_msg() callback [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Nov 2 08:25:39 2022 -0700

    drm/amdgpu: Fix type of second parameter in trans_msg() callback
    
    [ Upstream commit f0d0f1087333714ee683cc134a95afe331d7ddd9 ]
    
    With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
    indirect call targets are validated against the expected function
    pointer prototype to make sure the call target is valid to help mitigate
    ROP attacks. If they are not identical, there is a failure at run time,
    which manifests as either a kernel panic or thread getting killed. A
    proposed warning in clang aims to catch these at compile time, which
    reveals:
    
      drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c:412:15: error: incompatible function pointer types initializing 'void (*)(struct amdgpu_device *, u32, u32, u32, u32)' (aka 'void (*)(struct amdgpu_device *, unsigned int, unsigned int, unsigned int, unsigned int)') with an expression of type 'void (struct amdgpu_device *, enum idh_request, u32, u32, u32)' (aka 'void (struct amdgpu_device *, enum idh_request, unsigned int, unsigned int, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict]
              .trans_msg = xgpu_ai_mailbox_trans_msg,
                          ^~~~~~~~~~~~~~~~~~~~~~~~~
      1 error generated.
    
      drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c:435:15: error: incompatible function pointer types initializing 'void (*)(struct amdgpu_device *, u32, u32, u32, u32)' (aka 'void (*)(struct amdgpu_device *, unsigned int, unsigned int, unsigned int, unsigned int)') with an expression of type 'void (struct amdgpu_device *, enum idh_request, u32, u32, u32)' (aka 'void (struct amdgpu_device *, enum idh_request, unsigned int, unsigned int, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict]
              .trans_msg = xgpu_nv_mailbox_trans_msg,
                          ^~~~~~~~~~~~~~~~~~~~~~~~~
      1 error generated.
    
    The type of the second parameter in the prototype should be 'enum
    idh_request' instead of 'u32'. Update it to clear up the warnings.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1750
    Reported-by: Sami Tolvanen <samitolvanen@google.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

 
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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
iomap: Set all uptodate bits for an Uptodate page [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Fri Sep 25 11:16:53 2020 -0700

    iomap: Set all uptodate bits for an Uptodate page
    
    [ Upstream commit 4595a298d5563cf76c1d852970f162051fd1a7a6 ]
    
    For filesystems with block size < page size, we need to set all the
    per-block uptodate bits if the page was already uptodate at the time
    we create the per-block metadata.  This can happen if the page is
    invalidated (eg by a write to drop_caches) but ultimately not removed
    from the page cache.
    
    This is a data corruption issue as page writeback skips blocks which
    are marked !uptodate.
    
    Fixes: 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O without buffer heads")
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Reported-by: Qian Cai <cai@redhat.com>
    Cc: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Gao Xiang <hsiangkao@redhat.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    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>

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

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

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

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

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

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

    Linux 5.4.270
    
    Link: https://lore.kernel.org/r/20240227131552.864701583@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
memcg: add refcnt for pcpu stock to avoid UAF problem in drain_all_stock() [+ + +]
Author: GONG, Ruiqi <gongruiqi1@huawei.com>
Date:   Thu Feb 22 11:02:37 2024 +0800

    memcg: add refcnt for pcpu stock to avoid UAF problem in drain_all_stock()
    
    commit 1a3e1f40962c445b997151a542314f3c6097f8c3 upstream.
    
    NOTE: This is a partial backport since we only need the refcnt between
    memcg and stock to fix the problem stated below, and in this way
    multiple versions use the same code and align with each other.
    
    There was a kernel panic happened on an in-house environment running
    3.10, and the same problem was reproduced on 4.19:
    
    general protection fault: 0000 [#1] SMP PTI
    CPU: 1 PID: 2085 Comm: bash Kdump: loaded Tainted: G             L    4.19.90+ #7
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
    RIP: 0010 drain_all_stock+0xad/0x140
    Code: 00 00 4d 85 ff 74 2c 45 85 c9 74 27 4d 39 fc 74 42 41 80 bc 24 28 04 00 00 00 74 17 49 8b 04 24 49 8b 17 48 8b 88 90 02 00 00 <48> 39 8a 90 02 00 00 74 02 eb 86 48 63 88 3c 01 00 00 39 8a 3c 01
    RSP: 0018:ffffa7efc5813d70 EFLAGS: 00010202
    RAX: ffff8cb185548800 RBX: ffff8cb89f420160 RCX: ffff8cb1867b6000
    RDX: babababababababa RSI: 0000000000000001 RDI: 0000000000231876
    RBP: 0000000000000000 R08: 0000000000000415 R09: 0000000000000002
    R10: 0000000000000000 R11: 0000000000000001 R12: ffff8cb186f89040
    R13: 0000000000020160 R14: 0000000000000001 R15: ffff8cb186b27040
    FS:  00007f4a308d3740(0000) GS:ffff8cb89f440000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007ffe4d634a68 CR3: 000000010b022000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     mem_cgroup_force_empty_write+0x31/0xb0
     cgroup_file_write+0x60/0x140
     ? __check_object_size+0x136/0x147
     kernfs_fop_write+0x10e/0x190
     __vfs_write+0x37/0x1b0
     ? selinux_file_permission+0xe8/0x130
     ? security_file_permission+0x2e/0xb0
     vfs_write+0xb6/0x1a0
     ksys_write+0x57/0xd0
     do_syscall_64+0x63/0x250
     ? async_page_fault+0x8/0x30
     entry_SYSCALL_64_after_hwframe+0x5c/0xc1
    Modules linked in: ...
    
    It is found that in case of stock->nr_pages == 0, the memcg on
    stock->cached could be freed due to its refcnt decreased to 0, which
    made stock->cached become a dangling pointer. It could cause a UAF
    problem in drain_all_stock() in the following concurrent scenario. Note
    that drain_all_stock() doesn't disable irq but only preemption.
    
    CPU1                             CPU2
    ==============================================================================
    stock->cached = memcgA (freed)
                                     drain_all_stock(memcgB)
                                      rcu_read_lock()
                                      memcg = CPU1's stock->cached (memcgA)
                                      (interrupted)
    refill_stock(memcgC)
     drain_stock(memcgA)
     stock->cached = memcgC
     stock->nr_pages += xxx (> 0)
                                      stock->nr_pages > 0
                                      mem_cgroup_is_descendant(memcgA, memcgB) [UAF]
                                      rcu_read_unlock()
    
    This problem is, unintentionally, fixed at 5.9, where commit
    1a3e1f40962c ("mm: memcontrol: decouple reference counting from page
    accounting") adds memcg refcnt for stock. Therefore affected LTS
    versions include 4.19 and 5.4.
    
    For 4.19, memcg's css offline process doesn't call drain_all_stock(). so
    it's easier for the released memcg to be left on the stock. For 5.4,
    although mem_cgroup_css_offline() does call drain_all_stock(), but the
    flushing could be skipped when stock->nr_pages happens to be 0, and
    besides the async draining could be delayed and take place after the UAF
    problem has happened.
    
    Fix this problem by adding (and decreasing) memcg's refcnt when memcg is
    put onto (and removed from) stock, just like how commit 1a3e1f40962c
    ("mm: memcontrol: decouple reference counting from page accounting")
    does. After all, "being on the stock" is a kind of reference with
    regards to memcg. As such, it's guaranteed that a css on stock would not
    be freed.
    
    It's good to mention that refill_stock() is executed in an irq-disabled
    context, so the drain_stock() patched with css_put() would not actually
    free memcgA until the end of refill_stock(), since css_put() is an RCU
    free and it's still in grace period. For CPU2, the access to CPU1's
    stock->cached is protected by rcu_read_lock(), so in this case it gets
    either NULL from stock->cached or a memcgA that is still good.
    
    Cc: stable@vger.kernel.org      # 4.19 5.4
    Fixes: cdec2e4265df ("memcg: coalesce charging via percpu storage")
    Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

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

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

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

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

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

 
net: bridge: clear bridge's private skb space on xmit [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Fri Jul 31 19:26:16 2020 +0300

    net: bridge: clear bridge's private skb space on xmit
    
    [ Upstream commit fd65e5a95d08389444e8591a20538b3edece0e15 ]
    
    We need to clear all of the bridge private skb variables as they can be
    stale due to the packet being recirculated through the stack and then
    transmitted through the bridge device. Similar memset is already done on
    bridge's input. We've seen cases where proxyarp_replied was 1 on routed
    multicast packets transmitted through the bridge to ports with neigh
    suppress which were getting dropped. Same thing can in theory happen with
    the port isolation bit as well.
    
    Fixes: 821f1b21cabb ("bridge: add new BR_NEIGH_SUPPRESS port flag to suppress arp and nd flood")
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.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: 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>

 
nilfs2: replace WARN_ONs for invalid DAT metadata block requests [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Fri Jan 27 01:41:14 2023 +0900

    nilfs2: replace WARN_ONs for invalid DAT metadata block requests
    
    commit 5124a0a549857c4b87173280e192eea24dea72ad upstream.
    
    If DAT metadata file block access fails due to corruption of the DAT file
    or abnormal virtual block numbers held by b-trees or inodes, a kernel
    warning is generated.
    
    This replaces the WARN_ONs by error output, so that a kernel, booted with
    panic_on_warn, does not panic.  This patch also replaces the detected
    return code -ENOENT with another internal code -EINVAL to notify the bmap
    layer of metadata corruption.  When the bmap layer sees -EINVAL, it
    handles the abnormal situation with nilfs_bmap_convert_error() and finally
    returns code -EIO as it should.
    
    Link: https://lkml.kernel.org/r/0000000000005cc3d205ea23ddcf@google.com
    Link: https://lkml.kernel.org/r/20230126164114.6911-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: <syzbot+5d5d25f90f195a3cfcb4@syzkaller.appspotmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

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

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

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

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

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

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

 
PCI: tegra: Fix OF node reference leak [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue May 4 19:17:42 2021 +0200

    PCI: tegra: Fix OF node reference leak
    
    [ Upstream commit eff21f5da308265678e7e59821795e606f3e560f ]
    
    Commit 9e38e690ace3 ("PCI: tegra: Fix OF node reference leak") has fixed
    some node reference leaks in this function but missed some of them.
    
    In fact, having 'port' referenced in the 'rp' structure is not enough to
    prevent the leak, until 'rp' is actually added in the 'pcie->ports' list.
    
    Add the missing 'goto err_node_put' accordingly.
    
    Link: https://lore.kernel.org/r/55b11e9a7fa2987fbc0869d68ae59888954d65e2.1620148539.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Vidya Sagar <vidyas@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: tegra: Fix reporting GPIO error value [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Apr 14 12:25:12 2020 +0200

    PCI: tegra: Fix reporting GPIO error value
    
    [ Upstream commit 63605f1cfcc56bcb25c48bbee75a679d85ba7675 ]
    
    Error code is stored in rp->reset_gpio and not in err variable.
    
    Link: https://lore.kernel.org/r/20200414102512.27506-1-pali@kernel.org
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Stable-dep-of: eff21f5da308 ("PCI: tegra: Fix OF node reference leak")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: pinctrl-rockchip: Fix a bunch of kerneldoc misdemeanours [+ + +]
Author: Lee Jones <lee@kernel.org>
Date:   Mon Jul 13 15:49:24 2020 +0100

    pinctrl: pinctrl-rockchip: Fix a bunch of kerneldoc misdemeanours
    
    [ Upstream commit e1524ea84af7172acc20827f8dca3fc8f72b8f37 ]
    
    Demote headers which are clearly not kerneldoc, provide titles for
    struct definition blocks, fix API slip (bitrot) misspellings and
    provide some missing entries.
    
    Fixes the following W=1 kernel build warning(s):
    
     drivers/pinctrl/pinctrl-rockchip.c:82: warning: cannot understand function prototype: 'struct rockchip_iomux '
     drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_IO_DEFAULT' not described in enum 'rockchip_pin_drv_type'
     drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_IO_1V8_OR_3V0' not described in enum 'rockchip_pin_drv_type'
     drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_IO_1V8_ONLY' not described in enum 'rockchip_pin_drv_type'
     drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_IO_1V8_3V0_AUTO' not described in enum 'rockchip_pin_drv_type'
     drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_IO_3V3_ONLY' not described in enum 'rockchip_pin_drv_type'
     drivers/pinctrl/pinctrl-rockchip.c:97: warning: Enum value 'DRV_TYPE_MAX' not described in enum 'rockchip_pin_drv_type'
     drivers/pinctrl/pinctrl-rockchip.c:106: warning: Enum value 'PULL_TYPE_IO_DEFAULT' not described in enum 'rockchip_pin_pull_type'
     drivers/pinctrl/pinctrl-rockchip.c:106: warning: Enum value 'PULL_TYPE_IO_1V8_ONLY' not described in enum 'rockchip_pin_pull_type'
     drivers/pinctrl/pinctrl-rockchip.c:106: warning: Enum value 'PULL_TYPE_MAX' not described in enum 'rockchip_pin_pull_type'
     drivers/pinctrl/pinctrl-rockchip.c:109: warning: Cannot understand  * @drv_type: drive strength variant using rockchip_perpin_drv_type
     on line 109 - I thought it was a doc line
     drivers/pinctrl/pinctrl-rockchip.c:122: warning: Cannot understand  * @reg_base: register base of the gpio bank
     on line 109 - I thought it was a doc line
     drivers/pinctrl/pinctrl-rockchip.c:325: warning: Function parameter or member 'route_location' not described in 'rockchip_mux_route_data'
     drivers/pinctrl/pinctrl-rockchip.c:328: warning: Cannot understand  */
     on line 109 - I thought it was a doc line
     drivers/pinctrl/pinctrl-rockchip.c:375: warning: Function parameter or member 'data' not described in 'rockchip_pin_group'
     drivers/pinctrl/pinctrl-rockchip.c:387: warning: Function parameter or member 'ngroups' not described in 'rockchip_pmx_func'
    
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Cc: Heiko Stuebner <heiko@sntech.de>
    Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Cc: linux-rockchip@lists.infradead.org
    Link: https://lore.kernel.org/r/20200713144930.1034632-20-lee.jones@linaro.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: rockchip: Fix refcount leak in rockchip_pinctrl_parse_groups [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon Jan 2 15:28:45 2023 +0400

    pinctrl: rockchip: Fix refcount leak in rockchip_pinctrl_parse_groups
    
    [ Upstream commit c818ae563bf99457f02e8170aabd6b174f629f65 ]
    
    of_find_node_by_phandle() returns a node pointer with refcount incremented,
    We should use of_node_put() on it when not needed anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: d3e5116119bd ("pinctrl: add pinctrl driver for Rockchip SoCs")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20230102112845.3982407-1-linmq006@gmail.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
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/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: Make debug output more detailed [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Mon May 25 10:22:10 2020 -0700

    RDMA/srpt: Make debug output more detailed
    
    [ Upstream commit d4ee7f3a4445ec1b0b88af216f4032c4d30abf5a ]
    
    Since the session name by itself is not sufficient to uniquely identify a
    queue pair, include the queue pair number. Show the ASCII channel state
    name instead of the numeric value. This change makes the ib_srpt debug
    output more consistent.
    
    Link: https://lore.kernel.org/r/20200525172212.14413-3-bvanassche@acm.org
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Stable-dep-of: eb5c7465c324 ("RDMA/srpt: fix function pointer cast warnings")
    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/sun4i: dsi: Change the start delay calculation" [+ + +]
Author: Icenowy Zheng <icenowy@aosc.io>
Date:   Tue Oct 1 16:02:51 2019 +0800

    Revert "drm/sun4i: dsi: Change the start delay calculation"
    
    [ Upstream commit a00d17e0a71ae2e4fdaac46e1c12785d3346c3f2 ]
    
    This reverts commit da676c6aa6413d59ab0a80c97bbc273025e640b2.
    
    The original commit adds a start parameter to the calculation of the
    start delay according to some old BSP versions from Allwinner. However,
    there're two ways to add this delay -- add it in DSI controller or add
    it in the TCON. Add it in both controllers won't work.
    
    The code before this commit is picked from new versions of BSP kernel,
    which has a comment for the 1 that says "put start_delay to tcon". By
    checking the sun4i_tcon0_mode_set_cpu() in sun4i_tcon driver, it has
    already added this delay, so we shouldn't repeat to add the delay in DSI
    controller, otherwise the timing won't match.
    
    Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
    Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20191001080253.6135-2-icenowy@aosc.io
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/qeth: Fix potential loss of L3-IP@ in case of network issues [+ + +]
Author: Alexandra Winter <wintera@linux.ibm.com>
Date:   Tue Feb 6 09:58:49 2024 +0100

    s390/qeth: Fix potential loss of L3-IP@ in case of network issues
    
    [ Upstream commit 2fe8a236436fe40d8d26a1af8d150fc80f04ee1a ]
    
    Symptom:
    In case of a bad cable connection (e.g. dirty optics) a fast sequence of
    network DOWN-UP-DOWN-UP could happen. UP triggers recovery of the qeth
    interface. In case of a second DOWN while recovery is still ongoing, it
    can happen that the IP@ of a Layer3 qeth interface is lost and will not
    be recovered by the second UP.
    
    Problem:
    When registration of IP addresses with Layer 3 qeth devices fails, (e.g.
    because of bad address format) the respective IP address is deleted from
    its hash-table in the driver. If registration fails because of a ENETDOWN
    condition, the address should stay in the hashtable, so a subsequent
    recovery can restore it.
    
    3caa4af834df ("qeth: keep ip-address after LAN_OFFLINE failure")
    fixes this for registration failures during normal operation, but not
    during recovery.
    
    Solution:
    Keep L3-IP address in case of ENETDOWN in qeth_l3_recover_ip(). For
    consistency with qeth_l3_add_ip() we also keep it in case of EADDRINUSE,
    i.e. for some reason the card already/still has this address registered.
    
    Fixes: 4a71df50047f ("qeth: new qeth device driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240206085849.2902775-1-wintera@linux.ibm.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

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

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

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

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

 
scripts/bpf: Fix xdp_md forward declaration typo [+ + +]
Author: Andrii Nakryiko <andriin@fb.com>
Date:   Wed Oct 9 21:25:34 2019 -0700

    scripts/bpf: Fix xdp_md forward declaration typo
    
    commit e0b68fb186b251374adbd870f99b1ecea236e770 upstream.
    
    Fix typo in struct xpd_md, generated from bpf_helpers_doc.py, which is
    causing compilation warnings for programs using bpf_helpers.h
    
    Fixes: 7a387bed47f7 ("scripts/bpf: teach bpf_helpers_doc.py to dump BPF helper definitions")
    Signed-off-by: Andrii Nakryiko <andriin@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20191010042534.290562-1-andriin@fb.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scripts/bpf: teach bpf_helpers_doc.py to dump BPF helper definitions [+ + +]
Author: Andrii Nakryiko <andriin@fb.com>
Date:   Sun Oct 6 20:07:37 2019 -0700

    scripts/bpf: teach bpf_helpers_doc.py to dump BPF helper definitions
    
    [ Upstream commit 7a387bed47f7e80e257d966cd64a3e92a63e26a1 ]
    
    Enhance scripts/bpf_helpers_doc.py to emit C header with BPF helper
    definitions (to be included from libbpf's bpf_helpers.h).
    
    Signed-off-by: Andrii Nakryiko <andriin@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Stable-dep-of: e37243b65d52 ("bpf, scripts: Correct GPL license name")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

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

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

 
selftests/bpf: Avoid running unprivileged tests with alignment requirements [+ + +]
Author: Björn Töpel <bjorn@kernel.org>
Date:   Wed Nov 18 08:16:39 2020 +0100

    selftests/bpf: Avoid running unprivileged tests with alignment requirements
    
    [ Upstream commit c77b0589ca29ad1859fe7d7c1ecd63c0632379fa ]
    
    Some architectures have strict alignment requirements. In that case,
    the BPF verifier detects if a program has unaligned accesses and
    rejects them. A user can pass BPF_F_ANY_ALIGNMENT to a program to
    override this check. That, however, will only work when a privileged
    user loads a program. An unprivileged user loading a program with this
    flag will be rejected prior entering the verifier.
    
    Hence, it does not make sense to load unprivileged programs without
    strict alignment when testing the verifier. This patch avoids exactly
    that.
    
    Signed-off-by: Björn Töpel <bjorn.topel@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Luke Nelson <luke.r.nels@gmail.com>
    Link: https://lore.kernel.org/bpf/20201118071640.83773-3-bjorn.topel@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spi: mt7621: Fix an error message in mt7621_spi_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Aug 27 13:42:07 2022 +0200

    spi: mt7621: Fix an error message in mt7621_spi_probe()
    
    [ Upstream commit 2b2bf6b7faa9010fae10dc7de76627a3fdb525b3 ]
    
    'status' is known to be 0 at this point. The expected error code is
    PTR_ERR(clk).
    
    Switch to dev_err_probe() in order to display the expected error code (in a
    human readable way).
    This also filters -EPROBE_DEFER cases, should it happen.
    
    Fixes: 1ab7f2a43558 ("staging: mt7621-spi: add mt7621 support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Link: https://lore.kernel.org/r/928f3fb507d53ba0774df27cea0bbba4b055993b.1661599671.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp: add annotations around sk->sk_shutdown accesses [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue May 9 20:36:56 2023 +0000

    tcp: add annotations around sk->sk_shutdown accesses
    
    [ Upstream commit e14cadfd80d76f01bfaa1a8d745b1db19b57d6be ]
    
    Now sk->sk_shutdown is no longer a bitfield, we can add
    standard READ_ONCE()/WRITE_ONCE() annotations to silence
    KCSAN reports like the following:
    
    BUG: KCSAN: data-race in tcp_disconnect / tcp_poll
    
    write to 0xffff88814588582c of 1 bytes by task 3404 on cpu 1:
    tcp_disconnect+0x4d6/0xdb0 net/ipv4/tcp.c:3121
    __inet_stream_connect+0x5dd/0x6e0 net/ipv4/af_inet.c:715
    inet_stream_connect+0x48/0x70 net/ipv4/af_inet.c:727
    __sys_connect_file net/socket.c:2001 [inline]
    __sys_connect+0x19b/0x1b0 net/socket.c:2018
    __do_sys_connect net/socket.c:2028 [inline]
    __se_sys_connect net/socket.c:2025 [inline]
    __x64_sys_connect+0x41/0x50 net/socket.c:2025
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    read to 0xffff88814588582c of 1 bytes by task 3374 on cpu 0:
    tcp_poll+0x2e6/0x7d0 net/ipv4/tcp.c:562
    sock_poll+0x253/0x270 net/socket.c:1383
    vfs_poll include/linux/poll.h:88 [inline]
    io_poll_check_events io_uring/poll.c:281 [inline]
    io_poll_task_func+0x15a/0x820 io_uring/poll.c:333
    handle_tw_list io_uring/io_uring.c:1184 [inline]
    tctx_task_work+0x1fe/0x4d0 io_uring/io_uring.c:1246
    task_work_run+0x123/0x160 kernel/task_work.c:179
    get_signal+0xe64/0xff0 kernel/signal.c:2635
    arch_do_signal_or_restart+0x89/0x2a0 arch/x86/kernel/signal.c:306
    exit_to_user_mode_loop+0x6f/0xe0 kernel/entry/common.c:168
    exit_to_user_mode_prepare+0x6c/0xb0 kernel/entry/common.c:204
    __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]
    syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:297
    do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    value changed: 0x03 -> 0x00
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: factor out __tcp_close() helper [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Mon Nov 16 10:48:04 2020 +0100

    tcp: factor out __tcp_close() helper
    
    [ Upstream commit 77c3c95637526f1e4330cc9a4b2065f668c2c4fe ]
    
    unlocked version of protocol level close, will be used by
    MPTCP to allow decouple orphaning and subflow level close.
    
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: return EPOLLOUT from tcp_poll only when notsent_bytes is half the limit [+ + +]
Author: Soheil Hassas Yeganeh <soheil@google.com>
Date:   Mon Sep 14 17:52:09 2020 -0400

    tcp: return EPOLLOUT from tcp_poll only when notsent_bytes is half the limit
    
    [ Upstream commit 8ba3c9d1c6d75d1e6af2087278b30e17f68e1fff ]
    
    If there was any event available on the TCP socket, tcp_poll()
    will be called to retrieve all the events.  In tcp_poll(), we call
    sk_stream_is_writeable() which returns true as long as we are at least
    one byte below notsent_lowat.  This will result in quite a few
    spurious EPLLOUT and frequent tiny sendmsg() calls as a result.
    
    Similar to sk_stream_write_space(), use __sk_stream_is_writeable
    with a wake value of 1, so that we set EPOLLOUT only if half the
    space is available for write.
    
    Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
x86/alternatives: Disable KASAN in apply_alternatives() [+ + +]
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Thu Oct 12 13:04:24 2023 +0300

    x86/alternatives: Disable KASAN in apply_alternatives()
    
    [ Upstream commit d35652a5fc9944784f6f50a5c979518ff8dacf61 ]
    
    Fei has reported that KASAN triggers during apply_alternatives() on
    a 5-level paging machine:
    
            BUG: KASAN: out-of-bounds in rcu_is_watching()
            Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
            ...
            __asan_load4()
            rcu_is_watching()
            trace_hardirqs_on()
            text_poke_early()
            apply_alternatives()
            ...
    
    On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)
    gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on
    __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().
    
    KASAN gets confused when apply_alternatives() patches the
    KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START
    static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.
    
    Fix it for real by disabling KASAN while the kernel is patching alternatives.
    
    [ mingo: updated the changelog ]
    
    Fixes: 6657fca06e3f ("x86/mm: Allow to boot without LA57 if CONFIG_X86_5LEVEL=y")
    Reported-by: Fei Yang <fei.yang@intel.com>
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20231012100424.1456-1-kirill.shutemov@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>