Changelog in Linux kernel 6.8.12

 
ACPI: bus: Indicate support for _TFP thru _OSC [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Sat Mar 9 21:13:06 2024 +0100

    ACPI: bus: Indicate support for _TFP thru _OSC
    
    [ Upstream commit 95d43290f1e476b3be782dd17642e452d0436266 ]
    
    The ACPI thermal driver already uses the _TPF ACPI method to retrieve
    precise sampling time values, but this is not reported thru _OSC.
    
    Fix this by setting bit 9 ("Fast Thermal Sampling support") when
    evaluating _OSC.
    
    Fixes: a2ee7581afd5 ("ACPI: thermal: Add Thermal fast Sampling Period (_TFP) support")
    Signed-off-by: Armin Wolf <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: bus: Indicate support for IRQ ResourceSource thru _OSC [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Sat Mar 9 21:13:10 2024 +0100

    ACPI: bus: Indicate support for IRQ ResourceSource thru _OSC
    
    [ Upstream commit 403ad17c06509794fdf6e4d4b3070bd5b56e2a8e ]
    
    The ACPI IRQ mapping code supports parsing of ResourceSource,
    but this is not reported thru _OSC.
    
    Fix this by setting bit 13 ("Interrupt ResourceSource support")
    when evaluating _OSC.
    
    Fixes: d44fa3d46079 ("ACPI: Add support for ResourceSource/IRQ domain mapping")
    Signed-off-by: Armin Wolf <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: bus: Indicate support for more than 16 p-states thru _OSC [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Sat Mar 9 21:13:07 2024 +0100

    ACPI: bus: Indicate support for more than 16 p-states thru _OSC
    
    [ Upstream commit 6e8345f23ca37d6d41bb76be5d6a705ddf542817 ]
    
    The code responsible for parsing the available p-states should
    have no problems handling more than 16 p-states.
    
    Indicate this by setting bit 10 ("Greater Than 16 p-state support")
    when evaluating _OSC.
    
    Signed-off-by: Armin Wolf <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Stable-dep-of: a8a967a243d7 ("ACPI: bus: Indicate support for the Generic Event Device thru _OSC")
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: bus: Indicate support for the Generic Event Device thru _OSC [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Sat Mar 9 21:13:08 2024 +0100

    ACPI: bus: Indicate support for the Generic Event Device thru _OSC
    
    [ Upstream commit a8a967a243d71dd635ede076020f665a4df51c63 ]
    
    A device driver for the Generic Event Device (ACPI0013) already
    exists for quite some time, but support for it was never reported
    thru _OSC.
    
    Fix this by setting bit 11 ("Generic Event Device support") when
    evaluating _OSC.
    
    Fixes: 3db80c230da1 ("ACPI: implement Generic Event Device")
    Signed-off-by: Armin Wolf <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: disable -Wstringop-truncation [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Apr 9 16:00:55 2024 +0200

    ACPI: disable -Wstringop-truncation
    
    [ Upstream commit a3403d304708f60565582d60af4316289d0316a0 ]
    
    gcc -Wstringop-truncation warns about copying a string that results in a
    missing nul termination:
    
    drivers/acpi/acpica/tbfind.c: In function 'acpi_tb_find_table':
    drivers/acpi/acpica/tbfind.c:60:9: error: 'strncpy' specified bound 6 equals destination size [-Werror=stringop-truncation]
       60 |         strncpy(header.oem_id, oem_id, ACPI_OEM_ID_SIZE);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/acpi/acpica/tbfind.c:61:9: error: 'strncpy' specified bound 8 equals destination size [-Werror=stringop-truncation]
       61 |         strncpy(header.oem_table_id, oem_table_id, ACPI_OEM_TABLE_ID_SIZE);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    The code works as intended, and the warning could be addressed by using
    a memcpy(), but turning the warning off for this file works equally well
    and may be easier to merge.
    
    Fixes: 47c08729bf1c ("ACPICA: Fix for LoadTable operator, input strings")
    Link: https://lore.kernel.org/lkml/CAJZ5v0hoUfv54KW7y4223Mn9E7D4xvR7whRFNLTBqCZMUxT50Q@mail.gmail.com/#t
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: Fix Generic Initiator Affinity _OSC bit [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Sat Mar 9 21:13:09 2024 +0100

    ACPI: Fix Generic Initiator Affinity _OSC bit
    
    [ Upstream commit d0d4f1474e36b195eaad477373127ae621334c01 ]
    
    The ACPI spec says bit 17 should be used to indicate support
    for Generic Initiator Affinity Structure in SRAT, but we currently
    set bit 13 ("Interrupt ResourceSource support").
    
    Fix this by actually setting bit 17 when evaluating _OSC.
    
    Fixes: 01aabca2fd54 ("ACPI: Let ACPI know we support Generic Initiator Affinity Structures")
    Signed-off-by: Armin Wolf <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: LPSS: Advertise number of chip selects via property [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Thu Apr 4 15:06:58 2024 +0300

    ACPI: LPSS: Advertise number of chip selects via property
    
    [ Upstream commit 07b73ee599428b41d0240f2f7b31b524eba07dd0 ]
    
    Advertise number of chip selects via property for Intel Braswell.
    
    Fixes: 620c803f42de ("ACPI: LPSS: Provide an SSP type to the driver")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
af_packet: do not call packet_read_pending() from tpacket_destruct_skb() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Wed May 15 16:33:58 2024 +0000

    af_packet: do not call packet_read_pending() from tpacket_destruct_skb()
    
    [ Upstream commit 581073f626e387d3e7eed55c48c8495584ead7ba ]
    
    trafgen performance considerably sank on hosts with many cores
    after the blamed commit.
    
    packet_read_pending() is very expensive, and calling it
    in af_packet fast path defeats Daniel intent in commit
    b013840810c2 ("packet: use percpu mmap tx frame pending refcount")
    
    tpacket_destruct_skb() makes room for one packet, we can immediately
    wakeup a producer, no need to completely drain the tx ring.
    
    Fixes: 89ed5b519004 ("af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Neil Horman <[email protected]>
    Cc: Daniel Borkmann <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg [+ + +]
Author: Breno Leitao <[email protected]>
Date:   Thu May 9 01:14:46 2024 -0700

    af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
    
    [ Upstream commit 540bf24fba16b88c1b3b9353927204b4f1074e25 ]
    
    A data-race condition has been identified in af_unix. In one data path,
    the write function unix_release_sock() atomically writes to
    sk->sk_shutdown using WRITE_ONCE. However, on the reader side,
    unix_stream_sendmsg() does not read it atomically. Consequently, this
    issue is causing the following KCSAN splat to occur:
    
            BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg
    
            write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
            unix_release_sock (net/unix/af_unix.c:640)
            unix_release (net/unix/af_unix.c:1050)
            sock_close (net/socket.c:659 net/socket.c:1421)
            __fput (fs/file_table.c:422)
            __fput_sync (fs/file_table.c:508)
            __se_sys_close (fs/open.c:1559 fs/open.c:1541)
            __x64_sys_close (fs/open.c:1541)
            x64_sys_call (arch/x86/entry/syscall_64.c:33)
            do_syscall_64 (arch/x86/entry/common.c:?)
            entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
            read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
            unix_stream_sendmsg (net/unix/af_unix.c:2273)
            __sock_sendmsg (net/socket.c:730 net/socket.c:745)
            ____sys_sendmsg (net/socket.c:2584)
            __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
            __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
            x64_sys_call (arch/x86/entry/syscall_64.c:33)
            do_syscall_64 (arch/x86/entry/common.c:?)
            entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
            value changed: 0x01 -> 0x03
    
    The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").
    
    Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")
    addressed a comparable issue in the past regarding sk->sk_shutdown.
    However, it overlooked resolving this particular data path.
    This patch only offending unix_stream_sendmsg() function, since the
    other reads seem to be protected by unix_state_lock() as discussed in
    Link: https://lore.kernel.org/all/[email protected]/
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Breno Leitao <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ALSA: core: Fix NULL module pointer assignment at card init [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Wed May 22 09:04:39 2024 +0200

    ALSA: core: Fix NULL module pointer assignment at card init
    
    commit 39381fe7394e5eafac76e7e9367e7351138a29c1 upstream.
    
    The commit 81033c6b584b ("ALSA: core: Warn on empty module")
    introduced a WARN_ON() for a NULL module pointer passed at snd_card
    object creation, and it also wraps the code around it with '#ifdef
    MODULE'.  This works in most cases, but the devils are always in
    details.  "MODULE" is defined when the target code (i.e. the sound
    core) is built as a module; but this doesn't mean that the caller is
    also built-in or not.  Namely, when only the sound core is built-in
    (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),
    the passed module pointer is ignored even if it's non-NULL, and
    card->module remains as NULL.  This would result in the missing module
    reference up/down at the device open/close, leading to a race with the
    code execution after the module removal.
    
    For addressing the bug, move the assignment of card->module again out
    of ifdef.  The WARN_ON() is still wrapped with ifdef because the
    module can be really NULL when all sound drivers are built-in.
    
    Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would
    lead to a false-positive NULL module check.  Admittedly it won't catch
    perfectly, i.e. no check is performed when CONFIG_SND=y.  But, it's no
    real problem as it's only for debugging, and the condition is pretty
    rare.
    
    Fixes: 81033c6b584b ("ALSA: core: Warn on empty module")
    Reported-by: Xu Yang <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Tested-by: Xu Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: emu10k1: make E-MU FPGA writes potentially more reliable [+ + +]
Author: Oswald Buddenhagen <[email protected]>
Date:   Sun Apr 28 11:37:16 2024 +0200

    ALSA: emu10k1: make E-MU FPGA writes potentially more reliable
    
    [ Upstream commit 15c7e87aa88f0ab2d51c2e2123b127a6d693ca21 ]
    
    We did not delay after the second strobe signal, so another immediately
    following access could potentially corrupt the written value.
    
    This is a purely speculative fix with no supporting evidence, but after
    taking out the spinlocks around the writes, it seems plausible that a
    modern processor could be actually too fast. Also, it's just cleaner to
    be consistent.
    
    Signed-off-by: Oswald Buddenhagen <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: Fix deadlocks with kctl removals at disconnection [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Fri May 10 12:14:23 2024 +0200

    ALSA: Fix deadlocks with kctl removals at disconnection
    
    commit 87988a534d8e12f2e6fc01fe63e6c1925dc5307c upstream.
    
    In snd_card_disconnect(), we set card->shutdown flag at the beginning,
    call callbacks and do sync for card->power_ref_sleep waiters at the
    end.  The callback may delete a kctl element, and this can lead to a
    deadlock when the device was in the suspended state.  Namely:
    
    * A process waits for the power up at snd_power_ref_and_wait() in
      snd_ctl_info() or read/write() inside card->controls_rwsem.
    
    * The system gets disconnected meanwhile, and the driver tries to
      delete a kctl via snd_ctl_remove*(); it tries to take
      card->controls_rwsem again, but this is already locked by the
      above.  Since the sleeper isn't woken up, this deadlocks.
    
    An easy fix is to wake up sleepers before processing the driver
    disconnect callbacks but right after setting the card->shutdown flag.
    Then all sleepers will abort immediately, and the code flows again.
    
    So, basically this patch moves the wait_event() call at the right
    timing.  While we're at it, just to be sure, call wait_event_all()
    instead of wait_event(), although we don't use exclusive events on
    this queue for now.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218816
    Cc: <[email protected]>
    Reviewed-by: Jaroslav Kysela <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek: fix mute/micmute LEDs don't work for ProBook 440/460 G11. [+ + +]
Author: Andy Chi <[email protected]>
Date:   Thu May 23 14:18:31 2024 +0800

    ALSA: hda/realtek: fix mute/micmute LEDs don't work for ProBook 440/460 G11.
    
    commit b3b6f125da2773cbc681316842afba63ca9869aa upstream.
    
    HP ProBook 440/460 G11 needs ALC236_FIXUP_HP_GPIO_LED quirk to
    make mic-mute/audio-mute working.
    
    Signed-off-by: Andy Chi <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda: cs35l41: Remove Speaker ID for Lenovo Legion slim 7 16ARHA7 [+ + +]
Author: Stefan Binding <[email protected]>
Date:   Thu Apr 11 12:08:13 2024 +0100

    ALSA: hda: cs35l41: Remove Speaker ID for Lenovo Legion slim 7 16ARHA7
    
    [ Upstream commit 4a1a8065f5d3565677347d34a908ff2d0803b14f ]
    
    These laptops do not have _DSD and must be added by configuration
    table, however, the initial entries for them are incorrect:
    Neither laptop contains a Speaker ID GPIO.
    This issue would not affect audio playback, but may affect which files
    are loaded when loading firmware.
    
    Fixes: b67a7dc418aa ("ALSA: hda/realtek: Add sound quirks for Lenovo Legion slim 7 16ARHA7 models")
    
    Signed-off-by: Stefan Binding <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda: cs35l56: Exit cache-only after cs35l56_wait_for_firmware_boot() [+ + +]
Author: Richard Fitzgerald <[email protected]>
Date:   Mon Apr 8 11:18:01 2024 +0100

    ALSA: hda: cs35l56: Exit cache-only after cs35l56_wait_for_firmware_boot()
    
    [ Upstream commit 73580ec607dfe125b140ed30c7c0a074db78c558 ]
    
    Adds calls to disable regmap cache-only after a successful return from
    cs35l56_wait_for_firmware_boot().
    
    This is to prepare for a change in the shared ASoC module that will
    leave regmap in cache-only mode after cs35l56_system_reset(). This is
    to prevent register accesses going to the hardware while it is
    rebooting.
    
    Signed-off-by: Richard Fitzgerald <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda: intel-dsp-config: harden I2C/I2S codec detection [+ + +]
Author: Pierre-Louis Bossart <[email protected]>
Date:   Fri Apr 26 10:28:18 2024 -0500

    ALSA: hda: intel-dsp-config: harden I2C/I2S codec detection
    
    [ Upstream commit 79ac4c1443eaec0d09355307043a9149287f23c1 ]
    
    The SOF driver is selected whenever specific I2C/I2S HIDs are reported
    as 'present' in the ACPI DSDT. In some cases, an HID is reported but
    the hardware does not actually rely on I2C/I2S.  This false positive
    leads to an invalid selection of the SOF driver and as a result an
    invalid topology is loaded.
    
    This patch hardens the detection with a check that the NHLT table is
    consistent with the report of an I2S-based codec in DSDT. This table
    should expose at least one SSP endpoint configured for an I2S-codec
    connection.
    
    Tested on Huawei Matebook D14 (NBLB-WAX9N) using an HDaudio codec with
    an invalid ES8336 ACPI HID reported:
    
    [    7.858249] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
    [    7.858312] snd_hda_intel 0000:00:1f.3: snd_intel_dsp_find_config: no valid SSP found for HID ESSX8336, skipped
    
    Reported-by: Mauro Carvalho Chehab <[email protected]>
    Tested-by: Mauro Carvalho Chehab <[email protected]>
    Closes: https://github.com/thesofproject/linux/issues/4934
    Signed-off-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Bard Liao <[email protected]>
    Reviewed-by: Péter Ujfalusi <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
arm64/fpsimd: Avoid erroneous elide of user state reload [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Wed May 22 11:13:36 2024 +0200

    arm64/fpsimd: Avoid erroneous elide of user state reload
    
    commit e92bee9f861b466c676f0200be3e46af7bc4ac6b upstream.
    
    TIF_FOREIGN_FPSTATE is a 'convenience' flag that should reflect whether
    the current CPU holds the most recent user mode FP/SIMD state of the
    current task. It combines two conditions:
    - whether the current CPU's FP/SIMD state belongs to the task;
    - whether that state is the most recent associated with the task (as a
      task may have executed on other CPUs as well).
    
    When a task is scheduled in and TIF_KERNEL_FPSTATE is set, it means the
    task was in a kernel mode NEON section when it was scheduled out, and so
    the kernel mode FP/SIMD state is restored. Since this implies that the
    current CPU is *not* holding the most recent user mode FP/SIMD state of
    the current task, the TIF_FOREIGN_FPSTATE flag is set too, so that the
    user mode FP/SIMD state is reloaded from memory when returning to
    userland.
    
    However, the task may be scheduled out after completing the kernel mode
    NEON section, but before returning to userland. When this happens, the
    TIF_FOREIGN_FPSTATE flag will not be preserved, but will be set as usual
    the next time the task is scheduled in, and will be based on the above
    conditions.
    
    This means that, rather than setting TIF_FOREIGN_FPSTATE when scheduling
    in a task with TIF_KERNEL_FPSTATE set, the underlying state should be
    updated so that TIF_FOREIGN_FPSTATE will assume the expected value as a
    result.
    
    So instead, call fpsimd_flush_cpu_state(), which takes care of this.
    
    Closes: https://lore.kernel.org/all/[email protected]
    Reported-by: Johannes Nixdorf <[email protected]>
    Fixes: aefbab8e77eb ("arm64: fpsimd: Preserve/restore kernel mode NEON at context switch")
    Cc: Mark Brown <[email protected]>
    Cc: Dave Martin <[email protected]>
    Cc: Janne Grunau <[email protected]>
    Cc: [email protected]
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Tested-by: Janne Grunau <[email protected]>
    Tested-by: Johannes Nixdorf <[email protected]>
    Reviewed-by: Mark Brown <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Cc: Florian Klink <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
arm64: Remove unnecessary irqflags alternative.h include [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Thu Mar 14 14:38:19 2024 +0800

    arm64: Remove unnecessary irqflags alternative.h include
    
    [ Upstream commit 98631c4904bf6380834c8585ce50451f00eb5389 ]
    
    Since commit 20af807d806d ("arm64: Avoid cpus_have_const_cap() for
    ARM64_HAS_GIC_PRIO_MASKING"), the alternative.h include is not used,
    so remove it.
    
    Fixes: 20af807d806d ("arm64: Avoid cpus_have_const_cap() for ARM64_HAS_GIC_PRIO_MASKING")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ARM: configs: sunxi: Enable DRM_DW_HDMI [+ + +]
Author: Maxime Ripard <[email protected]>
Date:   Wed Apr 3 12:56:23 2024 +0200

    ARM: configs: sunxi: Enable DRM_DW_HDMI
    
    [ Upstream commit deff401b14e2d832b25b55862ad6c73378fe034e ]
    
    Commit 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper
    module") turned the DRM_DW_HDMI dependency of DRM_SUN8I_DW_HDMI into a
    depends on which ended up disabling the driver in the defconfig. Make
    sure it's still enabled.
    
    Fixes: 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper module")
    Reported-by: Mark Brown <[email protected]>
    Reported-by: Alexander Stein <[email protected]>
    Signed-off-by: Maxime Ripard <[email protected]>
    Acked-by: Jernej Skrabec <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jernej Skrabec <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: acp: Support microphone from device Acer 315-24p [+ + +]
Author: end.to.start <[email protected]>
Date:   Mon Apr 8 18:24:54 2024 +0300

    ASoC: acp: Support microphone from device Acer 315-24p
    
    [ Upstream commit 4b9a474c7c820391c0913d64431ae9e1f52a5143 ]
    
    This patch adds microphone detection for the Acer 315-24p, after which a microphone appears on the device and starts working
    
    Signed-off-by: end.to.start <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: cs35l41: Update DSP1RX5/6 Sources for DSP config [+ + +]
Author: Stefan Binding <[email protected]>
Date:   Thu Apr 11 15:26:48 2024 +0100

    ASoC: cs35l41: Update DSP1RX5/6 Sources for DSP config
    
    [ Upstream commit eefb831d2e4dd58d58002a2ef75ff989e073230d ]
    
    Currently, all ASoC systems are set to use VPMON for DSP1RX5_SRC,
    however, this is required only for internal boost systems.
    External boost systems require VBSTMON instead of VPMON to be the
    input to DSP1RX5_SRC.
    Shared Boost Active acts like Internal boost (requires VPMON).
    Shared Boost Passive acts like External boost (requires VBSTMON)
    All systems require DSP1RX6_SRC to be set to VBSTMON.
    
    Signed-off-by: Stefan Binding <[email protected]>
    Reviewed-by: Richard Fitzgerald <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: cs35l56: fix usages of device_get_named_child_node() [+ + +]
Author: Pierre-Louis Bossart <[email protected]>
Date:   Fri Apr 26 10:29:39 2024 -0500

    ASoC: cs35l56: fix usages of device_get_named_child_node()
    
    [ Upstream commit fbd741f0993203d07b2b6562d68d1e5e4745b59b ]
    
    The documentation for device_get_named_child_node() mentions this
    important point:
    
    "
    The caller is responsible for calling fwnode_handle_put() on the
    returned fwnode pointer.
    "
    
    Add fwnode_handle_put() to avoid leaked references.
    
    Signed-off-by: Pierre-Louis Bossart <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: da7219-aad: fix usage of device_get_named_child_node() [+ + +]
Author: Pierre-Louis Bossart <[email protected]>
Date:   Fri Apr 26 10:30:33 2024 -0500

    ASoC: da7219-aad: fix usage of device_get_named_child_node()
    
    [ Upstream commit e8a6a5ad73acbafd98e8fd3f0cbf6e379771bb76 ]
    
    The documentation for device_get_named_child_node() mentions this
    important point:
    
    "
    The caller is responsible for calling fwnode_handle_put() on the
    returned fwnode pointer.
    "
    
    Add fwnode_handle_put() to avoid a leaked reference.
    
    Signed-off-by: Pierre-Louis Bossart <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: dt-bindings: rt5645: add cbj sleeve gpio property [+ + +]
Author: Derek Fang <[email protected]>
Date:   Mon Apr 8 17:10:57 2024 +0800

    ASoC: dt-bindings: rt5645: add cbj sleeve gpio property
    
    [ Upstream commit 306b38e3fa727d22454a148a364123709e356600 ]
    
    Add an optional gpio property to control external CBJ circuits
    to avoid some electric noise caused by sleeve/ring2 contacts floating.
    
    Signed-off-by: Derek Fang <[email protected]>
    
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: avs: Fix ASRC module initialization [+ + +]
Author: Cezary Rojewski <[email protected]>
Date:   Fri Apr 5 11:09:21 2024 +0200

    ASoC: Intel: avs: Fix ASRC module initialization
    
    [ Upstream commit 9d2e26f31c7cc3fa495c423af9b4902ec0dc7be3 ]
    
    The ASRC module configuration consists of several reserved fields. Zero
    them out when initializing the module to avoid sending invalid data.
    
    Fixes: 274d79e51875 ("ASoC: Intel: avs: Configure modules according to their type")
    Signed-off-by: Cezary Rojewski <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: avs: Fix potential integer overflow [+ + +]
Author: Cezary Rojewski <[email protected]>
Date:   Fri Apr 5 11:09:23 2024 +0200

    ASoC: Intel: avs: Fix potential integer overflow
    
    [ Upstream commit c7e832cabe635df47c2bf6df7801e97bf3045b1e ]
    
    While stream_tag for CLDMA on SKL-based platforms is always 1, function
    hda_cldma_setup() uses AZX_SD_CTL_STRM() macro which does:
            stream_tag << 20
    
    what combined with stream_tag type of 'unsigned int' generates a
    potential overflow issue. Update the field type to fix that.
    
    Fixes: 45864e49a05a ("ASoC: Intel: avs: Implement CLDMA transfer")
    Signed-off-by: Cezary Rojewski <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: avs: Restore stream decoupling on prepare [+ + +]
Author: Amadeusz Sławiński <[email protected]>
Date:   Fri Apr 5 11:09:17 2024 +0200

    ASoC: Intel: avs: Restore stream decoupling on prepare
    
    [ Upstream commit 680507581e025d16a0b6d3782603ca8c598fbe2b ]
    
    Revert changes from commit b87b8f43afd5 ("ASoC: Intel: avs: Drop
    superfluous stream decoupling") to restore working streaming during S3.
    
    Fixes: b87b8f43afd5 ("ASoC: Intel: avs: Drop superfluous stream decoupling")
    Signed-off-by: Amadeusz Sławiński <[email protected]>
    Signed-off-by: Cezary Rojewski <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: avs: ssm4567: Do not ignore route checks [+ + +]
Author: Cezary Rojewski <[email protected]>
Date:   Fri Mar 8 10:05:00 2024 +0100

    ASoC: Intel: avs: ssm4567: Do not ignore route checks
    
    [ Upstream commit e6719d48ba6329536c459dcee5a571e535687094 ]
    
    A copy-paste from intel/boards/skl_nau88l25_ssm4567.c made the avs's
    equivalent disable route checks as well. Such behavior is not desired.
    
    Fixes: 69ea14efe99b ("ASoC: Intel: avs: Add ssm4567 machine board")
    Signed-off-by: Cezary Rojewski <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: avs: Test result of avs_get_module_entry() [+ + +]
Author: Cezary Rojewski <[email protected]>
Date:   Fri Apr 5 11:09:24 2024 +0200

    ASoC: Intel: avs: Test result of avs_get_module_entry()
    
    [ Upstream commit 41bf4525fadb3d8df3860420d6ac9025c51a3bac ]
    
    While PROBE_MOD_UUID is always part of the base AudioDSP firmware
    manifest, from maintenance point of view it is better to check the
    result.
    
    Fixes: dab8d000e25c ("ASoC: Intel: avs: Add data probing requests")
    Signed-off-by: Cezary Rojewski <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: bytcr_rt5640: Apply Asus T100TA quirk to Asus T100TAM too [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Sun Apr 7 21:15:59 2024 +0200

    ASoC: Intel: bytcr_rt5640: Apply Asus T100TA quirk to Asus T100TAM too
    
    [ Upstream commit e50729d742ec364895f1c389c32315984a987aa5 ]
    
    The Asus T100TA quirk has been using an exact match on a product-name of
    "T100TA" but there are also T100TAM variants with a slightly higher
    clocked CPU and a metal backside which need the same quirk.
    
    Sort the existing T100TA (stereo speakers) below the more specific
    T100TAF (mono speaker) quirk and switch from exact matching to
    substring matching so that the T100TA quirk will also match on
    the T100TAM models.
    
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: Disable route checks for Skylake boards [+ + +]
Author: Cezary Rojewski <[email protected]>
Date:   Fri Mar 8 10:04:58 2024 +0100

    ASoC: Intel: Disable route checks for Skylake boards
    
    [ Upstream commit 0cb3b7fd530b8c107443218ce6db5cb6e7b5dbe1 ]
    
    Topology files that are propagated to the world and utilized by the
    skylake-driver carry shortcomings in their SectionGraphs.
    
    Since commit daa480bde6b3 ("ASoC: soc-core: tidyup for
    snd_soc_dapm_add_routes()") route checks are no longer permissive. Probe
    failures for Intel boards have been partially addressed by commit
    a22ae72b86a4 ("ASoC: soc-core: disable route checks for legacy devices")
    and its follow up but only skl_nau88l25_ssm4567.c is patched. Fix the
    problem for the rest of the boards.
    
    Link: https://lore.kernel.org/all/[email protected]/
    Fixes: daa480bde6b3 ("ASoC: soc-core: tidyup for snd_soc_dapm_add_routes()")
    Signed-off-by: Cezary Rojewski <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: kirkwood: Fix potential NULL dereference [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Thu Mar 28 20:33:37 2024 +0300

    ASoC: kirkwood: Fix potential NULL dereference
    
    [ Upstream commit ea60ab95723f5738e7737b56dda95e6feefa5b50 ]
    
    In kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL if
    CONFIG_PLAT_ORION macro is not defined.
    Fix this bug by adding NULL check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: bb6a40fc5a83 ("ASoC: kirkwood: Fix reference to PCM buffer address")
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: mediatek: Assign dummy when codec not specified for a DAI link [+ + +]
Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Wed Mar 13 12:01:29 2024 +0100

    ASoC: mediatek: Assign dummy when codec not specified for a DAI link
    
    [ Upstream commit 5f39231888c63f0a7708abc86b51b847476379d8 ]
    
    MediaTek sound card drivers are checking whether a DAI link is present
    and used on a board to assign the correct parameters and this is done
    by checking the codec DAI names at probe time.
    
    If no real codec is present, assign the dummy codec to the DAI link
    to avoid NULL pointer during string comparison.
    
    Fixes: 4302187d955f ("ASoC: mediatek: common: add soundcard driver common code")
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rt5645: Fix the electric noise due to the CBJ contacts floating [+ + +]
Author: Derek Fang <[email protected]>
Date:   Mon Apr 8 17:10:56 2024 +0800

    ASoC: rt5645: Fix the electric noise due to the CBJ contacts floating
    
    [ Upstream commit 103abab975087e1f01b76fcb54c91dbb65dbc249 ]
    
    The codec leaves tie combo jack's sleeve/ring2 to floating status
    default. It would cause electric noise while connecting the active
    speaker jack during boot or shutdown.
    This patch requests a gpio to control the additional jack circuit
    to tie the contacts to the ground or floating.
    
    Signed-off-by: Derek Fang <[email protected]>
    
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rt715-sdca: volume step modification [+ + +]
Author: Jack Yu <[email protected]>
Date:   Tue Apr 23 06:59:35 2024 +0000

    ASoC: rt715-sdca: volume step modification
    
    [ Upstream commit bda16500dd0b05e2e047093b36cbe0873c95aeae ]
    
    Volume step (dB/step) modification to fix format error
    which shown in amixer control.
    
    Signed-off-by: Jack Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rt715: add vendor clear control register [+ + +]
Author: Jack Yu <[email protected]>
Date:   Mon Apr 15 06:27:23 2024 +0000

    ASoC: rt715: add vendor clear control register
    
    [ Upstream commit cebfbc89ae2552dbb58cd9b8206a5c8e0e6301e9 ]
    
    Add vendor clear control register in readable register's
    callback function. This prevents an access failure reported
    in Intel CI tests.
    
    Signed-off-by: Jack Yu <[email protected]>
    Closes: https://github.com/thesofproject/linux/issues/4860
    Tested-by: Pierre-Louis Bossart <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rt722-sdca: add headset microphone vrefo setting [+ + +]
Author: Jack Yu <[email protected]>
Date:   Tue Apr 9 06:47:34 2024 +0000

    ASoC: rt722-sdca: add headset microphone vrefo setting
    
    [ Upstream commit 140e0762ca055d1aa84b17847cde5d9e47f56f76 ]
    
    Add vrefo settings to fix jd and headset mic recording issue.
    
    Signed-off-by: Jack Yu <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rt722-sdca: modify channel number to support 4 channels [+ + +]
Author: Jack Yu <[email protected]>
Date:   Tue Apr 9 06:47:43 2024 +0000

    ASoC: rt722-sdca: modify channel number to support 4 channels
    
    [ Upstream commit cb9946971d7cb717b726710e1a9fa4ded00b9135 ]
    
    Channel numbers of dmic supports 4 channels, modify channels_max
    regarding to this issue.
    
    Signed-off-by: Jack Yu <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: Intel: hda-dai: fix channel map configuration for aggregated dailink [+ + +]
Author: Pierre-Louis Bossart <[email protected]>
Date:   Tue Apr 2 10:18:12 2024 -0500

    ASoC: SOF: Intel: hda-dai: fix channel map configuration for aggregated dailink
    
    [ Upstream commit 831045513c8a2ef14c3cf39b33d1ccedf588c4a8 ]
    
    The existing code derives the channel map used to program the HDaudio
    link DMA from the hw_params, but that is not quite right in the case
    of aggregation. The code in soc-pcm.c splits the hw_params depending
    on the codec_ch_map, and we need to reconstruct the channel-map to
    insert the data in the right places.
    
    This issue is seen only on amplifier feedback capture where the data
    from the second amplifier was replaced by that of the first amplifier.
    
    Note that the loop iterator of the macro for_each_rtd_cpu_dais() is
    reused in a following loop. This is different to all existing usages
    of that macro, hence the use of a boolean flag to avoid an access to
    an uninitialized variable.
    
    Fixes: 2960ee5c4814 ("ASoC: SOF: Intel: hda-dai: add helpers for SoundWire callbacks")
    Reviewed-by: Bard Liao <[email protected]>
    Reviewed-by: Rander Wang <[email protected]>
    Signed-off-by: Pierre-Louis Bossart <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: Intel: lnl: Correct rom_status_reg [+ + +]
Author: Peter Ujfalusi <[email protected]>
Date:   Wed Apr 3 13:52:06 2024 +0300

    ASoC: SOF: Intel: lnl: Correct rom_status_reg
    
    [ Upstream commit b852574c671a9983dd51c81582c8c5085f3dc382 ]
    
    ACE2 architecture changed the place where the ROM updates the status code
    from the shared SRAM window (and HFFLGP1QW0 in ACE1) to HFDSC register for
    the status and HFDEC (HFDSC + 4) for the error code.
    
    The rom_status_reg is not used on LNL because it was wrongly assigned based
    on older platform convention (SRAM window) and it was giving inconsistent
    readings.
    
    Add new header file for lnl specific register definitions.
    
    Fixes: 64a63d9914a5 ("ASoC: SOF: Intel: LNL: Add support for Lunarlake platform")
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Reviewed-by: Rander Wang <[email protected]>
    Reviewed-by: Kai Vehmanen <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Liam Girdwood <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: Intel: mtl: Correct rom_status_reg [+ + +]
Author: Peter Ujfalusi <[email protected]>
Date:   Wed Apr 3 13:52:05 2024 +0300

    ASoC: SOF: Intel: mtl: Correct rom_status_reg
    
    [ Upstream commit 1f1b820dc3c65b6883da3130ba3b8624dcbf87db ]
    
    ACE1 architecture changed the place where the ROM updates the status code
    from the shared SRAM window to HFFLGP1QW0 register for the status and
    HFFLGP1QW0 + 4 for the error code.
    
    The rom_status_reg is not used on MTL because it was wrongly assigned based
    on older platform convention (SRAM window) and it was giving inconsistent
    readings.
    
    Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)")
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Reviewed-by: Rander Wang <[email protected]>
    Reviewed-by: Kai Vehmanen <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Liam Girdwood <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: Intel: mtl: Disable interrupts when firmware boot failed [+ + +]
Author: Peter Ujfalusi <[email protected]>
Date:   Wed Apr 3 13:52:07 2024 +0300

    ASoC: SOF: Intel: mtl: Disable interrupts when firmware boot failed
    
    [ Upstream commit 26187f44aabdf3df7609b7c78724a059c230a2ad ]
    
    In case of error during the firmware boot we need to disable the interrupts
    which were enabled as part of the boot sequence.
    
    Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)")
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Reviewed-by: Rander Wang <[email protected]>
    Reviewed-by: Kai Vehmanen <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Liam Girdwood <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: Intel: mtl: Implement firmware boot state check [+ + +]
Author: Peter Ujfalusi <[email protected]>
Date:   Wed Apr 3 13:52:08 2024 +0300

    ASoC: SOF: Intel: mtl: Implement firmware boot state check
    
    [ Upstream commit 6b1c1c47e76f0161bda2b1ac2e86a219fe70244f ]
    
    With the corrected rom_status_reg values we can now add a check for target
    boot status for firmware booting.
    With the check now we can identify failed firmware boots (IMR boots) and
    we can use the fallback to purge boot the DSP.
    
    Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)")
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Reviewed-by: Rander Wang <[email protected]>
    Reviewed-by: Kai Vehmanen <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Liam Girdwood <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: ipc4-pcm: Introduce generic sof_ipc4_pcm_stream_priv [+ + +]
Author: Peter Ujfalusi <[email protected]>
Date:   Tue Apr 9 14:00:35 2024 +0300

    ASoC: SOF: ipc4-pcm: Introduce generic sof_ipc4_pcm_stream_priv
    
    [ Upstream commit 551af3280c16166244425bbb1d73028f3a907e1f ]
    
    Using the sof_ipc4_timestamp_info struct directly as sps->private data
    is too restrictive, add a new generic sof_ipc4_pcm_stream_priv struct
    containing the time_info to allow new information to be stored in a
    generic way.
    
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Ranjani Sridharan <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: ipc4-pcm: Use consistent name for snd_sof_pcm_stream pointer [+ + +]
Author: Peter Ujfalusi <[email protected]>
Date:   Tue Apr 9 14:00:33 2024 +0300

    ASoC: SOF: ipc4-pcm: Use consistent name for snd_sof_pcm_stream pointer
    
    [ Upstream commit 965e49cdf8c19f21b8308adeded3a8139cff5c84 ]
    
    Throughout the file the pointer for snd_sof_pcm_stream is named either
    'stream' or (wrongly) 'spcm' which confuses the reader.
    
    Use 'sps' for the pointer name as it is the most common name used in SOF
    codebase.
    
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Ranjani Sridharan <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: ipc4-pcm: Use consistent name for sof_ipc4_timestamp_info pointer [+ + +]
Author: Peter Ujfalusi <[email protected]>
Date:   Tue Apr 9 14:00:34 2024 +0300

    ASoC: SOF: ipc4-pcm: Use consistent name for sof_ipc4_timestamp_info pointer
    
    [ Upstream commit 36e980050b0733829e4e0f97b97f7907ba9f00bb ]
    
    The pointer to sof_ipc4_timestamp_info named most of the time as
    'time_info' only to be named as 'stream_info' or 'info' in two function.
    
    Use the consistent name of 'time_info' throughout the file.
    
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Ranjani Sridharan <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: SOF: pcm: Restrict DSP D0i3 during S0ix to IPC3 [+ + +]
Author: Ranjani Sridharan <[email protected]>
Date:   Mon Apr 8 14:41:46 2024 -0500

    ASoC: SOF: pcm: Restrict DSP D0i3 during S0ix to IPC3
    
    [ Upstream commit 90a2353080eedec855d63f6aadfda14104ee9b06 ]
    
    Introduce a new field in struct sof_ipc_pcm_ops that can be used to
    restrict DSP D0i3 during S0ix suspend to IPC3. With IPC4, all streams
    must be stopped before S0ix suspend.
    
    Reviewed-by: Uday M Bhat <[email protected]>
    Reviewed-by: Bard Liao <[email protected]>
    Signed-off-by: Ranjani Sridharan <[email protected]>
    Signed-off-by: Pierre-Louis Bossart <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: tracing: Export SND_SOC_DAPM_DIR_OUT to its value [+ + +]
Author: Steven Rostedt <[email protected]>
Date:   Tue Apr 16 00:03:03 2024 -0400

    ASoC: tracing: Export SND_SOC_DAPM_DIR_OUT to its value
    
    [ Upstream commit 58300f8d6a48e58d1843199be743f819e2791ea3 ]
    
    The string SND_SOC_DAPM_DIR_OUT is printed in the snd_soc_dapm_path trace
    event instead of its value:
    
       (((REC->path_dir) == SND_SOC_DAPM_DIR_OUT) ? "->" : "<-")
    
    User space cannot parse this, as it has no idea what SND_SOC_DAPM_DIR_OUT
    is. Use TRACE_DEFINE_ENUM() to convert it to its value:
    
       (((REC->path_dir) == 1) ? "->" : "<-")
    
    So that user space tools, such as perf and trace-cmd, can parse it
    correctly.
    
    Reported-by: Luca Ceresoli <[email protected]>
    Fixes: 6e588a0d839b5 ("ASoC: dapm: Consolidate path trace events")
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ax25: Fix reference count leak issue of net_device [+ + +]
Author: Duoming Zhou <[email protected]>
Date:   Thu May 9 17:37:02 2024 +0800

    ax25: Fix reference count leak issue of net_device
    
    [ Upstream commit 36e56b1b002bb26440403053f19f9e1a8bc075b2 ]
    
    There is a reference count leak issue of the object "net_device" in
    ax25_dev_device_down(). When the ax25 device is shutting down, the
    ax25_dev_device_down() drops the reference count of net_device one
    or zero times depending on if we goto unlock_put or not, which will
    cause memory leak.
    
    In order to solve the above issue, decrease the reference count of
    net_device after dev->ax25_ptr is set to null.
    
    Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs")
    Suggested-by: Dan Carpenter <[email protected]>
    Signed-off-by: Duoming Zhou <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/7ce3b23a40d9084657ba1125432f0ecc380cbc80.1715247018.git.duoming@zju.edu.cn
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ax25: Fix reference count leak issues of ax25_dev [+ + +]
Author: Duoming Zhou <[email protected]>
Date:   Thu May 9 17:36:47 2024 +0800

    ax25: Fix reference count leak issues of ax25_dev
    
    [ Upstream commit b505e0319852b08a3a716b64620168eab21f4ced ]
    
    The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference
    count leak issue of the object "ax25_dev".
    
    Memory leak issue in ax25_addr_ax25dev():
    
    The reference count of the object "ax25_dev" can be increased multiple
    times in ax25_addr_ax25dev(). This will cause a memory leak.
    
    Memory leak issues in ax25_dev_device_down():
    
    The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and
    then increase the reference count when ax25_dev is added to ax25_dev_list.
    As a result, the reference count of ax25_dev is 2. But when the device is
    shutting down. The ax25_dev_device_down() drops the reference count once
    or twice depending on if we goto unlock_put or not, which will cause
    memory leak.
    
    As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer
    to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the
    issue of ax25_dev_device_down(), increase the reference count of ax25_dev
    once in ax25_dev_device_up() and decrease the reference count of ax25_dev
    after it is removed from the ax25_dev_list.
    
    Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs")
    Suggested-by: Dan Carpenter <[email protected]>
    Signed-off-by: Duoming Zhou <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/361bbf2a4b091e120006279ec3b382d73c4a0c17.1715247018.git.duoming@zju.edu.cn
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ax25: Use kernel universal linked list to implement ax25_dev_list [+ + +]
Author: Duoming Zhou <[email protected]>
Date:   Thu May 9 17:36:33 2024 +0800

    ax25: Use kernel universal linked list to implement ax25_dev_list
    
    [ Upstream commit a7d6e36b9ad052926ba2ecba3a59d8bb67dabcb4 ]
    
    The origin ax25_dev_list implements its own single linked list,
    which is complicated and error-prone. For example, when deleting
    the node of ax25_dev_list in ax25_dev_device_down(), we have to
    operate on the head node and other nodes separately.
    
    This patch uses kernel universal linked list to replace original
    ax25_dev_list, which make the operation of ax25_dev_list easier.
    
    We should do "dev->ax25_ptr = ax25_dev;" and "dev->ax25_ptr = NULL;"
    while holding the spinlock, otherwise the ax25_dev_device_up() and
    ax25_dev_device_down() could race.
    
    Suggested-by: Dan Carpenter <[email protected]>
    Signed-off-by: Duoming Zhou <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/85bba3af651ca0e1a519da8d0d715b949891171c.1715247018.git.duoming@zju.edu.cn
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: b505e0319852 ("ax25: Fix reference count leak issues of ax25_dev")
    Signed-off-by: Sasha Levin <[email protected]>

 
bitops: add missing prototype check [+ + +]
Author: Alexander Lobakin <[email protected]>
Date:   Wed Mar 27 16:23:41 2024 +0100

    bitops: add missing prototype check
    
    [ Upstream commit 72cc1980a0ef3ccad0d539e7dace63d0d7d432a4 ]
    
    Commit 8238b4579866 ("wait_on_bit: add an acquire memory barrier") added
    a new bitop, test_bit_acquire(), with proper wrapping in order to try to
    optimize it at compile-time, but missed the list of bitops used for
    checking their prototypes a bit below.
    The functions added have consistent prototypes, so that no more changes
    are required and no functional changes take place.
    
    Fixes: 8238b4579866 ("wait_on_bit: add an acquire memory barrier")
    Reviewed-by: Przemek Kitszel <[email protected]>
    Signed-off-by: Alexander Lobakin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
block: fix and simplify blkdevparts= cmdline parsing [+ + +]
Author: INAGAKI Hiroshi <[email protected]>
Date:   Sun Apr 21 16:39:52 2024 +0900

    block: fix and simplify blkdevparts= cmdline parsing
    
    [ Upstream commit bc2e07dfd2c49aaa4b52302cf7b55cf94e025f79 ]
    
    Fix the cmdline parsing of the "blkdevparts=" parameter using strsep(),
    which makes the code simpler.
    
    Before commit 146afeb235cc ("block: use strscpy() to instead of
    strncpy()"), we used a strncpy() to copy a block device name and partition
    names. The commit simply replaced a strncpy() and NULL termination with
    a strscpy(). It did not update calculations of length passed to strscpy().
    While the length passed to strncpy() is just a length of valid characters
    without NULL termination ('\0'), strscpy() takes it as a length of the
    destination buffer, including a NULL termination.
    
    Since the source buffer is not necessarily NULL terminated, the current
    code copies "length - 1" characters and puts a NULL character in the
    destination buffer. It replaces the last character with NULL and breaks
    the parsing.
    
    As an example, that buffer will be passed to parse_parts() and breaks
    parsing sub-partitions due to the missing ')' at the end, like the
    following.
    
    example (Check Point V-80 & OpenWrt):
    
    - Linux Kernel 6.6
    
      [    0.000000] Kernel command line: console=ttyS0,115200 earlycon=uart8250,mmio32,0xf0512000 crashkernel=30M mvpp2x.queue_mode=1 blkdevparts=mmcblk1:48M@10M(kernel-1),1M(dtb-1),720M(rootfs-1),48M(kernel-2),1M(dtb-2),720M(rootfs-2),300M(default_sw),650M(logs),1M(preset_cfg),1M(adsl),-(storage) maxcpus=4
      ...
      [    0.884016] mmc1: new HS200 MMC card at address 0001
      [    0.889951] mmcblk1: mmc1:0001 004GA0 3.69 GiB
      [    0.895043] cmdline partition format is invalid.
      [    0.895704]  mmcblk1: p1
      [    0.903447] mmcblk1boot0: mmc1:0001 004GA0 2.00 MiB
      [    0.908667] mmcblk1boot1: mmc1:0001 004GA0 2.00 MiB
      [    0.913765] mmcblk1rpmb: mmc1:0001 004GA0 512 KiB, chardev (248:0)
    
      1. "48M@10M(kernel-1),..." is passed to strscpy() with length=17
         from parse_parts()
      2. strscpy() returns -E2BIG and the destination buffer has
         "48M@10M(kernel-1\0"
      3. "48M@10M(kernel-1\0" is passed to parse_subpart()
      4. parse_subpart() fails to find ')' when parsing a partition name,
         and returns error
    
    - Linux Kernel 6.1
    
      [    0.000000] Kernel command line: console=ttyS0,115200 earlycon=uart8250,mmio32,0xf0512000 crashkernel=30M mvpp2x.queue_mode=1 blkdevparts=mmcblk1:48M@10M(kernel-1),1M(dtb-1),720M(rootfs-1),48M(kernel-2),1M(dtb-2),720M(rootfs-2),300M(default_sw),650M(logs),1M(preset_cfg),1M(adsl),-(storage) maxcpus=4
      ...
      [    0.953142] mmc1: new HS200 MMC card at address 0001
      [    0.959114] mmcblk1: mmc1:0001 004GA0 3.69 GiB
      [    0.964259]  mmcblk1: p1(kernel-1) p2(dtb-1) p3(rootfs-1) p4(kernel-2) p5(dtb-2) 6(rootfs-2) p7(default_sw) p8(logs) p9(preset_cfg) p10(adsl) p11(storage)
      [    0.979174] mmcblk1boot0: mmc1:0001 004GA0 2.00 MiB
      [    0.984674] mmcblk1boot1: mmc1:0001 004GA0 2.00 MiB
      [    0.989926] mmcblk1rpmb: mmc1:0001 004GA0 512 KiB, chardev (248:0
    
    By the way, strscpy() takes a length of destination buffer and it is
    often confusing when copying characters with a specified length. Using
    strsep() helps to separate the string by the specified character. Then,
    we can use strscpy() naturally with the size of the destination buffer.
    
    Separating the string on the fly is also useful to omit the redundant
    string copy, reducing memory usage and improve the code readability.
    
    Fixes: 146afeb235cc ("block: use strscpy() to instead of strncpy()")
    Suggested-by: Naohiro Aota <[email protected]>
    Signed-off-by: INAGAKI Hiroshi <[email protected]>
    Reviewed-by: Daniel Golle <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block: refine the EOF check in blkdev_iomap_begin [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Fri May 3 10:10:42 2024 +0200

    block: refine the EOF check in blkdev_iomap_begin
    
    [ Upstream commit 0c12028aec837f5a002009bbf68d179d506510e8 ]
    
    blkdev_iomap_begin rounds down the offset to the logical block size
    before stashing it in iomap->offset and checking that it still is
    inside the inode size.
    
    Check the i_size check to the raw pos value so that we don't try a
    zero size write if iter->pos is unaligned.
    
    Fixes: 487c607df790 ("block: use iomap for writes to block devices")
    Reported-by: [email protected]
    Signed-off-by: Christoph Hellwig <[email protected]>
    Tested-by: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block: support to account io_ticks precisely [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Thu May 9 20:37:16 2024 +0800

    block: support to account io_ticks precisely
    
    [ Upstream commit 99dc422335d8b2bd4d105797241d3e715bae90e9 ]
    
    Currently, io_ticks is accounted based on sampling, specifically
    update_io_ticks() will always account io_ticks by 1 jiffies from
    bdev_start_io_acct()/blk_account_io_start(), and the result can be
    inaccurate, for example(HZ is 250):
    
    Test script:
    fio -filename=/dev/sda -bs=4k -rw=write -direct=1 -name=test -thinktime=4ms
    
    Test result: util is about 90%, while the disk is really idle.
    
    This behaviour is introduced by commit 5b18b5a73760 ("block: delete
    part_round_stats and switch to less precise counting"), however, there
    was a key point that is missed that this patch also improve performance
    a lot:
    
    Before the commit:
    part_round_stats:
      if (part->stamp != now)
       stats |= 1;
    
      part_in_flight()
      -> there can be lots of task here in 1 jiffies.
      part_round_stats_single()
       __part_stat_add()
      part->stamp = now;
    
    After the commit:
    update_io_ticks:
      stamp = part->bd_stamp;
      if (time_after(now, stamp))
       if (try_cmpxchg())
        __part_stat_add()
        -> only one task can reach here in 1 jiffies.
    
    Hence in order to account io_ticks precisely, we only need to know if
    there are IO inflight at most once in one jiffies. Noted that for
    rq-based device, iterating tags should not be used here because
    'tags->lock' is grabbed in blk_mq_find_and_get_req(), hence
    part_stat_lock_inc/dec() and part_in_flight() is used to trace inflight.
    The additional overhead is quite little:
    
     - per cpu add/dec for each IO for rq-based device;
     - per cpu sum for each jiffies;
    
    And it's verified by null-blk that there are no performance degration
    under heavy IO pressure.
    
    Fixes: 5b18b5a73760 ("block: delete part_round_stats and switch to less precise counting")
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Bluetooth: compute LE flow credits based on recvbuf space [+ + +]
Author: Sebastian Urban <[email protected]>
Date:   Wed May 1 12:08:58 2024 +0200

    Bluetooth: compute LE flow credits based on recvbuf space
    
    [ Upstream commit ce60b9231b66710b6ee24042ded26efee120ecfc ]
    
    Previously LE flow credits were returned to the
    sender even if the socket's receive buffer was
    full. This meant that no back-pressure
    was applied to the sender, thus it continued to
    send data, resulting in data loss without any
    error being reported. Furthermore, the amount
    of credits was essentially fixed to a small
    amount, leading to reduced performance.
    
    This is fixed by computing the number of returned
    LE flow credits based on the estimated available
    space in the receive buffer of an L2CAP socket.
    Consequently, if the receive buffer is full, no
    credits are returned until the buffer is read and
    thus cleared by user-space.
    
    Since the computation of available receive buffer
    space can only be performed approximately (due to
    sk_buff overhead) and the receive buffer size may
    be changed by user-space after flow credits have
    been sent, superfluous received data is temporary
    stored within l2cap_pinfo. This is necessary
    because Bluetooth LE provides no retransmission
    mechanism once the data has been acked by the
    physical layer.
    
    If receive buffer space estimation is not possible
    at the moment, we fall back to providing credits
    for one full packet as before. This is currently
    the case during connection setup, when MPS is not
    yet available.
    
    Fixes: b1c325c23d75 ("Bluetooth: Implement returning of LE L2CAP credits")
    Signed-off-by: Sebastian Urban <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: HCI: Remove HCI_AMP support [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Mon May 6 18:33:52 2024 -0400

    Bluetooth: HCI: Remove HCI_AMP support
    
    [ Upstream commit 84a4bb6548a29326564f0e659fb8064503ecc1c7 ]
    
    Since BT_HS has been remove HCI_AMP controllers no longer has any use so
    remove it along with the capability of creating AMP controllers.
    
    Since we no longer need to differentiate between AMP and Primary
    controllers, as only HCI_PRIMARY is left, this also remove
    hdev->dev_type altogether.
    
    Fixes: e7b02296fb40 ("Bluetooth: Remove BT_HS")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_conn, hci_sync: Use __counted_by() to avoid -Wfamnae warnings [+ + +]
Author: Gustavo A. R. Silva <[email protected]>
Date:   Fri Apr 26 16:52:46 2024 -0600

    Bluetooth: hci_conn, hci_sync: Use __counted_by() to avoid -Wfamnae warnings
    
    [ Upstream commit c4585edf708edb5277a3cc4b8581ccb833f3307d ]
    
    Prepare for the coming implementation by GCC and Clang of the
    __counted_by attribute. Flexible array members annotated with
    __counted_by can have their accesses bounds-checked at run-time
    via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE
    (for strcpy/memcpy-family functions).
    
    Also, -Wflex-array-member-not-at-end is coming in GCC-14, and we are
    getting ready to enable it globally.
    
    So, use the `DEFINE_FLEX()` helper for multiple on-stack definitions
    of a flexible structure where the size of the flexible-array member
    is known at compile-time, and refactor the rest of the code,
    accordingly.
    
    Notice that, due to the use of `__counted_by()` in `struct
    hci_cp_le_create_cis`, the for loop in function `hci_cs_le_create_cis()`
    had to be modified. Once the index `i`, through which `cp->cis[i]` is
    accessed, falls in the interval [0, cp->num_cis), `cp->num_cis` cannot
    be decremented all the way down to zero while accessing `cp->cis[]`:
    
    net/bluetooth/hci_event.c:4310:
    4310    for (i = 0; cp->num_cis; cp->num_cis--, i++) {
                    ...
    4314            handle = __le16_to_cpu(cp->cis[i].cis_handle);
    
    otherwise, only half (one iteration before `cp->num_cis == i`) or half
    plus one (one iteration before `cp->num_cis < i`) of the items in the
    array will be accessed before running into an out-of-bounds issue. So,
    in order to avoid this, set `cp->num_cis` to zero just after the for
    loop.
    
    Also, make use of `aux_num_cis` variable to update `cmd->num_cis` after
    a `list_for_each_entry_rcu()` loop.
    
    With these changes, fix the following warnings:
    net/bluetooth/hci_sync.c:1239:56: warning: structure containing a flexible
    array member is not at the end of another structure
    [-Wflex-array-member-not-at-end]
    net/bluetooth/hci_sync.c:1415:51: warning: structure containing a flexible
    array member is not at the end of another structure
    [-Wflex-array-member-not-at-end]
    net/bluetooth/hci_sync.c:1731:51: warning: structure containing a flexible
    array member is not at the end of another structure
    [-Wflex-array-member-not-at-end]
    net/bluetooth/hci_sync.c:6497:45: warning: structure containing a flexible
    array member is not at the end of another structure
    [-Wflex-array-member-not-at-end]
    
    Link: https://github.com/KSPP/linux/issues/202
    Signed-off-by: Gustavo A. R. Silva <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Stable-dep-of: e77f43d531af ("Bluetooth: hci_core: Fix not handling hdev->le_num_of_adv_sets=1")
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_core: Fix not handling hdev->le_num_of_adv_sets=1 [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Mon May 13 16:07:55 2024 -0400

    Bluetooth: hci_core: Fix not handling hdev->le_num_of_adv_sets=1
    
    [ Upstream commit e77f43d531af41e9ce299eab10dcae8fa5dbc293 ]
    
    If hdev->le_num_of_adv_sets is set to 1 it means that only handle 0x00
    can be used, but since the MGMT interface instances start from 1
    (instance 0 means all instances in case of MGMT_OP_REMOVE_ADVERTISING)
    the code needs to map the instance to handle otherwise users will not be
    able to advertise as instance 1 would attempt to use handle 0x01.
    
    Fixes: 1d0fac2c38ed ("Bluetooth: Use controller sets when available")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_event: Remove code to removed CONFIG_BT_HS [+ + +]
Author: Lukas Bulwahn <[email protected]>
Date:   Wed Feb 7 14:42:11 2024 +0100

    Bluetooth: hci_event: Remove code to removed CONFIG_BT_HS
    
    [ Upstream commit f4b0c2b4cd78b75acde56c2ee5aa732b6fb2a6a9 ]
    
    Commit cec9f3c5561d ("Bluetooth: Remove BT_HS") removes config BT_HS, but
    misses two "ifdef BT_HS" blocks in hci_event.c.
    
    Remove this dead code from this removed config option.
    
    Signed-off-by: Lukas Bulwahn <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Stable-dep-of: 84a4bb6548a2 ("Bluetooth: HCI: Remove HCI_AMP support")
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: ISO: Add hcon for listening bis sk [+ + +]
Author: Iulia Tanasescu <[email protected]>
Date:   Fri Feb 23 15:14:41 2024 +0200

    Bluetooth: ISO: Add hcon for listening bis sk
    
    [ Upstream commit 02171da6e86a73e1b343b36722f5d9d5c04b3539 ]
    
    This creates a hcon instance at bis listen, before the PA sync
    procedure is started.
    
    Signed-off-by: Iulia Tanasescu <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Stable-dep-of: a5b862c6a221 ("Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()")
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: ISO: Clean up returns values in iso_connect_ind() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Sat Mar 2 11:30:43 2024 +0300

    Bluetooth: ISO: Clean up returns values in iso_connect_ind()
    
    [ Upstream commit 18d88f0fd8c0fade7ae08c2778d6c6447b11f16a ]
    
    This function either returns 0 or HCI_LM_ACCEPT.  Make it clearer which
    returns are which and delete the "lm" variable because it is no longer
    required.
    
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Stable-dep-of: a5b862c6a221 ("Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()")
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: ISO: Make iso_get_sock_listen generic [+ + +]
Author: Iulia Tanasescu <[email protected]>
Date:   Tue Apr 2 14:39:30 2024 +0300

    Bluetooth: ISO: Make iso_get_sock_listen generic
    
    [ Upstream commit 311527e9dafdcae0c5a20d62f4f84ad01b33b5f4 ]
    
    This makes iso_get_sock_listen more generic, to return matching socket
    in the state provided as argument.
    
    Signed-off-by: Iulia Tanasescu <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Stable-dep-of: a5b862c6a221 ("Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()")
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: qca: Fix error code in qca_read_fw_build_info() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Sat May 4 14:25:43 2024 +0300

    Bluetooth: qca: Fix error code in qca_read_fw_build_info()
    
    [ Upstream commit a189f0ee6685457528db7a36ded3085e5d13ddc3 ]
    
    Return -ENOMEM on allocation failure.  Don't return success.
    
    Fixes: cda0d6a198e2 ("Bluetooth: qca: fix info leak when fetching fw build id")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Johan Hovold <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: Remove usage of the deprecated ida_simple_xx() API [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Mon Jan 15 21:12:19 2024 +0100

    Bluetooth: Remove usage of the deprecated ida_simple_xx() API
    
    [ Upstream commit 9c16d0c8d93e3d2a95c5ed927b061f244db75579 ]
    
    ida_alloc() and ida_free() should be preferred to the deprecated
    ida_simple_get() and ida_simple_remove().
    
    Note that the upper limit of ida_simple_get() is exclusive, but the one of
    ida_alloc_max() is inclusive. So a -1 has been added when needed.
    
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Stable-dep-of: 84a4bb6548a2 ("Bluetooth: HCI: Remove HCI_AMP support")
    Signed-off-by: Sasha Levin <[email protected]>

 
bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq [+ + +]
Author: Michal Schmidt <[email protected]>
Date:   Tue May 7 12:39:28 2024 +0200

    bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq
    
    [ Upstream commit 78cfd17142ef70599d6409cbd709d94b3da58659 ]
    
    Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called
    with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0.
    In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called.
    roundup_pow_of_two is documented as undefined for 0.
    
    Fix it in the one caller that had this combination.
    
    The undefined behavior was detected by UBSAN:
      UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
      shift exponent 64 is too large for 64-bit type 'long unsigned int'
      CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4
      Hardware name: Abacus electric, s.r.o. - [email protected] Super Server/H12SSW-iN, BIOS 2.7 10/25/2023
      Call Trace:
       <TASK>
       dump_stack_lvl+0x5d/0x80
       ubsan_epilogue+0x5/0x30
       __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec
       __roundup_pow_of_two+0x25/0x35 [bnxt_re]
       bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]
       bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]
       bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __kmalloc+0x1b6/0x4f0
       ? create_qp.part.0+0x128/0x1c0 [ib_core]
       ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]
       create_qp.part.0+0x128/0x1c0 [ib_core]
       ib_create_qp_kernel+0x50/0xd0 [ib_core]
       create_mad_qp+0x8e/0xe0 [ib_core]
       ? __pfx_qp_event_handler+0x10/0x10 [ib_core]
       ib_mad_init_device+0x2be/0x680 [ib_core]
       add_client_context+0x10d/0x1a0 [ib_core]
       enable_device_and_get+0xe0/0x1d0 [ib_core]
       ib_register_device+0x53c/0x630 [ib_core]
       ? srso_alias_return_thunk+0x5/0xfbef5
       bnxt_re_probe+0xbd8/0xe50 [bnxt_re]
       ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]
       auxiliary_bus_probe+0x49/0x80
       ? driver_sysfs_add+0x57/0xc0
       really_probe+0xde/0x340
       ? pm_runtime_barrier+0x54/0x90
       ? __pfx___driver_attach+0x10/0x10
       __driver_probe_device+0x78/0x110
       driver_probe_device+0x1f/0xa0
       __driver_attach+0xba/0x1c0
       bus_for_each_dev+0x8f/0xe0
       bus_add_driver+0x146/0x220
       driver_register+0x72/0xd0
       __auxiliary_driver_register+0x6e/0xd0
       ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]
       bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]
       ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]
       do_one_initcall+0x5b/0x310
       do_init_module+0x90/0x250
       init_module_from_file+0x86/0xc0
       idempotent_init_module+0x121/0x2b0
       __x64_sys_finit_module+0x5e/0xb0
       do_syscall_64+0x82/0x160
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? syscall_exit_to_user_mode_prepare+0x149/0x170
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? syscall_exit_to_user_mode+0x75/0x230
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? do_syscall_64+0x8e/0x160
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __count_memcg_events+0x69/0x100
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? count_memcg_events.constprop.0+0x1a/0x30
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? handle_mm_fault+0x1f0/0x300
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? do_user_addr_fault+0x34e/0x640
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? srso_alias_return_thunk+0x5/0xfbef5
       entry_SYSCALL_64_after_hwframe+0x76/0x7e
      RIP: 0033:0x7f4e5132821d
      Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48
      RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d
      RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b
      RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0
      R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d
      R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60
       </TASK>
      ---[ end trace ]---
    
    Fixes: 0c4dcd602817 ("RDMA/bnxt_re: Refactor hardware queue memory allocation")
    Signed-off-by: Michal Schmidt <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Acked-by: Selvin Xavier <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf, x86: Fix PROBE_MEM runtime load check [+ + +]
Author: Puranjay Mohan <[email protected]>
Date:   Wed Apr 24 10:02:09 2024 +0000

    bpf, x86: Fix PROBE_MEM runtime load check
    
    [ Upstream commit b599d7d26d6ad1fc9975218574bc2ca6d0293cfd ]
    
    When a load is marked PROBE_MEM - e.g. due to PTR_UNTRUSTED access - the
    address being loaded from is not necessarily valid. The BPF jit sets up
    exception handlers for each such load which catch page faults and 0 out
    the destination register.
    
    If the address for the load is outside kernel address space, the load
    will escape the exception handling and crash the kernel. To prevent this
    from happening, the emits some instruction to verify that addr is > end
    of userspace addresses.
    
    x86 has a legacy vsyscall ABI where a page at address 0xffffffffff600000
    is mapped with user accessible permissions. The addresses in this page
    are considered userspace addresses by the fault handler. Therefore, a
    BPF program accessing this page will crash the kernel.
    
    This patch fixes the runtime checks to also check that the PROBE_MEM
    address is below VSYSCALL_ADDR.
    
    Example BPF program:
    
     SEC("fentry/tcp_v4_connect")
     int BPF_PROG(fentry_tcp_v4_connect, struct sock *sk)
     {
            *(volatile unsigned long *)&sk->sk_tsq_flags;
            return 0;
     }
    
    BPF Assembly:
    
     0: (79) r1 = *(u64 *)(r1 +0)
     1: (79) r1 = *(u64 *)(r1 +344)
     2: (b7) r0 = 0
     3: (95) exit
    
                                   x86-64 JIT
                                   ==========
    
                BEFORE                                    AFTER
                ------                                    -----
    
     0:   nopl   0x0(%rax,%rax,1)             0:   nopl   0x0(%rax,%rax,1)
     5:   xchg   %ax,%ax                      5:   xchg   %ax,%ax
     7:   push   %rbp                         7:   push   %rbp
     8:   mov    %rsp,%rbp                    8:   mov    %rsp,%rbp
     b:   mov    0x0(%rdi),%rdi               b:   mov    0x0(%rdi),%rdi
    -------------------------------------------------------------------------------
     f:   movabs $0x100000000000000,%r11      f:   movabs $0xffffffffff600000,%r10
    19:   add    $0x2a0,%rdi                 19:   mov    %rdi,%r11
    20:   cmp    %r11,%rdi                   1c:   add    $0x2a0,%r11
    23:   jae    0x0000000000000029          23:   sub    %r10,%r11
    25:   xor    %edi,%edi                   26:   movabs $0x100000000a00000,%r10
    27:   jmp    0x000000000000002d          30:   cmp    %r10,%r11
    29:   mov    0x0(%rdi),%rdi              33:   ja     0x0000000000000039
    --------------------------------\        35:   xor    %edi,%edi
    2d:   xor    %eax,%eax           \       37:   jmp    0x0000000000000040
    2f:   leave                       \      39:   mov    0x2a0(%rdi),%rdi
    30:   ret                          \--------------------------------------------
                                             40:   xor    %eax,%eax
                                             42:   leave
                                             43:   ret
    
    Signed-off-by: Puranjay Mohan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE [+ + +]
Author: Stanislav Fomichev <[email protected]>
Date:   Fri Apr 26 16:16:18 2024 -0700

    bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
    
    [ Upstream commit 543576ec15b17c0c93301ac8297333c7b6e84ac7 ]
    
    bpf_prog_attach uses attach_type_to_prog_type to enforce proper
    attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses
    bpf_prog_get and relies on bpf_prog_attach_check_attach_type
    to properly verify prog_type <> attach_type association.
    
    Add missing attach_type enforcement for the link_create case.
    Otherwise, it's currently possible to attach cgroup_skb prog
    types to other cgroup hooks.
    
    Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment")
    Link: https://lore.kernel.org/bpf/[email protected]/
    Reported-by: [email protected]
    Signed-off-by: Stanislav Fomichev <[email protected]>
    Acked-by: Eduard Zingerman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix verifier assumptions about socket->sk [+ + +]
Author: Alexei Starovoitov <[email protected]>
Date:   Fri Apr 26 17:25:44 2024 -0700

    bpf: Fix verifier assumptions about socket->sk
    
    [ Upstream commit 0db63c0b86e981a1e97d2596d64ceceba1a5470e ]
    
    The verifier assumes that 'sk' field in 'struct socket' is valid
    and non-NULL when 'socket' pointer itself is trusted and non-NULL.
    That may not be the case when socket was just created and
    passed to LSM socket_accept hook.
    Fix this verifier assumption and adjust tests.
    
    Reported-by: Liam Wisehart <[email protected]>
    Acked-by: Kumar Kartikeya Dwivedi <[email protected]>
    Fixes: 6fcd486b3a0a ("bpf: Refactor RCU enforcement in the verifier.")
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Pack struct bpf_fib_lookup [+ + +]
Author: Anton Protopopov <[email protected]>
Date:   Wed Apr 3 14:33:03 2024 +0200

    bpf: Pack struct bpf_fib_lookup
    
    [ Upstream commit f91717007217d975aa975ddabd91ae1a107b9bff ]
    
    The struct bpf_fib_lookup is supposed to be of size 64. A recent commit
    59b418c7063d ("bpf: Add a check for struct bpf_fib_lookup size") added
    a static assertion to check this property so that future changes to the
    structure will not accidentally break this assumption.
    
    As it immediately turned out, on some 32-bit arm systems, when AEABI=n,
    the total size of the structure was equal to 68, see [1]. This happened
    because the bpf_fib_lookup structure contains a union of two 16-bit
    fields:
    
        union {
                __u16 tot_len;
                __u16 mtu_result;
        };
    
    which was supposed to compile to a 16-bit-aligned 16-bit field. On the
    aforementioned setups it was instead both aligned and padded to 32-bits.
    
    Declare this inner union as __attribute__((packed, aligned(2))) such
    that it always is of size 2 and is aligned to 16 bits.
    
      [1] https://lore.kernel.org/all/CA+G9fYtsoP51f-oP_Sp5MOq-Ffv8La2RztNpwvE6+R1VtFiLrw@mail.gmail.com/#t
    
    Reported-by: Naresh Kamboju <[email protected]>
    Fixes: e1850ea9bd9e ("bpf: bpf_fib_lookup return MTU value as output when looked up")
    Signed-off-by: Anton Protopopov <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Reviewed-by: Alexander Lobakin <[email protected]>
    Acked-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: prevent r10 register from being marked as precise [+ + +]
Author: Andrii Nakryiko <[email protected]>
Date:   Thu Apr 4 14:45:35 2024 -0700

    bpf: prevent r10 register from being marked as precise
    
    [ Upstream commit 1f2a74b41ea8b902687eb97c4e7e3f558801865b ]
    
    r10 is a special register that is not under BPF program's control and is
    always effectively precise. The rest of precision logic assumes that
    only r0-r9 SCALAR registers are marked as precise, so prevent r10 from
    being marked precise.
    
    This can happen due to signed cast instruction allowing to do something
    like `r0 = (s8)r10;`, which later, if r0 needs to be precise, would lead
    to an attempt to mark r10 as precise.
    
    Prevent this with an extra check during instruction backtracking.
    
    Fixes: 8100928c8814 ("bpf: Support new sign-extension mov insns")
    Reported-by: [email protected]
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpftool: Fix missing pids during link show [+ + +]
Author: Yonghong Song <[email protected]>
Date:   Mon Mar 11 19:32:49 2024 -0700

    bpftool: Fix missing pids during link show
    
    [ Upstream commit fe879bb42f8a6513ed18e9d22efb99cb35590201 ]
    
    Current 'bpftool link' command does not show pids, e.g.,
      $ tools/build/bpftool/bpftool link
      ...
      4: tracing  prog 23
            prog_type lsm  attach_type lsm_mac
            target_obj_id 1  target_btf_id 31320
    
    Hack the following change to enable normal libbpf debug output,
    #  --- a/tools/bpf/bpftool/pids.c
    #  +++ b/tools/bpf/bpftool/pids.c
    #  @@ -121,9 +121,9 @@ int build_obj_refs_table(struct hashmap **map, enum bpf_obj_type type)
    #          /* we don't want output polluted with libbpf errors if bpf_iter is not
    #           * supported
    #           */
    #  -       default_print = libbpf_set_print(libbpf_print_none);
    #  +       /* default_print = libbpf_set_print(libbpf_print_none); */
    #          err = pid_iter_bpf__load(skel);
    #  -       libbpf_set_print(default_print);
    #  +       /* libbpf_set_print(default_print); */
    
    Rerun the above bpftool command:
      $ tools/build/bpftool/bpftool link
      libbpf: prog 'iter': BPF program load failed: Permission denied
      libbpf: prog 'iter': -- BEGIN PROG LOAD LOG --
      0: R1=ctx() R10=fp0
      ; struct task_struct *task = ctx->task; @ pid_iter.bpf.c:69
      0: (79) r6 = *(u64 *)(r1 +8)          ; R1=ctx() R6_w=ptr_or_null_task_struct(id=1)
      ; struct file *file = ctx->file; @ pid_iter.bpf.c:68
      ...
      ; struct bpf_link *link = (struct bpf_link *) file->private_data; @ pid_iter.bpf.c:103
      80: (79) r3 = *(u64 *)(r8 +432)       ; R3_w=scalar() R8=ptr_file()
      ; if (link->type == bpf_core_enum_value(enum bpf_link_type___local, @ pid_iter.bpf.c:105
      81: (61) r1 = *(u32 *)(r3 +12)
      R3 invalid mem access 'scalar'
      processed 39 insns (limit 1000000) max_states_per_insn 0 total_states 3 peak_states 3 mark_read 2
      -- END PROG LOAD LOG --
      libbpf: prog 'iter': failed to load: -13
      ...
    
    The 'file->private_data' returns a 'void' type and this caused subsequent 'link->type'
    (insn #81) failed in verification.
    
    To fix the issue, restore the previous BPF_CORE_READ so old kernels can also work.
    With this patch, the 'bpftool link' runs successfully with 'pids'.
      $ tools/build/bpftool/bpftool link
      ...
      4: tracing  prog 23
            prog_type lsm  attach_type lsm_mac
            target_obj_id 1  target_btf_id 31320
            pids systemd(1)
    
    Fixes: 44ba7b30e84f ("bpftool: Use a local copy of BPF_LINK_TYPE_PERF_EVENT in pid_iter.bpf.c")
    Signed-off-by: Yonghong Song <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Tested-by: Quentin Monnet <[email protected]>
    Reviewed-by: Quentin Monnet <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpftool: Mount bpffs on provided dir instead of parent dir [+ + +]
Author: Sahil Siddiq <[email protected]>
Date:   Fri Apr 5 00:52:19 2024 +0530

    bpftool: Mount bpffs on provided dir instead of parent dir
    
    [ Upstream commit 478a535ae54ad3831371904d93b5dfc403222e17 ]
    
    When pinning programs/objects under PATH (eg: during "bpftool prog
    loadall") the bpffs is mounted on the parent dir of PATH in the
    following situations:
    - the given dir exists but it is not bpffs.
    - the given dir doesn't exist and the parent dir is not bpffs.
    
    Mounting on the parent dir can also have the unintentional side-
    effect of hiding other files located under the parent dir.
    
    If the given dir exists but is not bpffs, then the bpffs should
    be mounted on the given dir and not its parent dir.
    
    Similarly, if the given dir doesn't exist and its parent dir is not
    bpffs, then the given dir should be created and the bpffs should be
    mounted on this new dir.
    
    Fixes: 2a36c26fe3b8 ("bpftool: Support bpffs mountpoint as pin path for prog loadall")
    Signed-off-by: Sahil Siddiq <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]/T/#t
    Link: https://lore.kernel.org/bpf/[email protected]
    
    Closes: https://github.com/libbpf/bpftool/issues/100
    
    Changes since v1:
     - Split "mount_bpffs_for_pin" into two functions.
       This is done to improve maintainability and readability.
    
    Changes since v2:
    - mount_bpffs_for_pin: rename to "create_and_mount_bpffs_dir".
    - mount_bpffs_given_file: rename to "mount_bpffs_given_file".
    - create_and_mount_bpffs_dir:
      - introduce "dir_exists" boolean.
      - remove new dir if "mnt_fs" fails.
    - improve error handling and error messages.
    
    Changes since v3:
    - Rectify function name.
    - Improve error messages and formatting.
    - mount_bpffs_for_file:
      - Check if dir exists before block_mount check.
    
    Changes since v4:
    - Use strdup instead of strcpy.
    - create_and_mount_bpffs_dir:
      - Use S_IRWXU instead of 0700.
    - Improve error handling and formatting.
    
    Signed-off-by: Sasha Levin <[email protected]>

 
btrfs: take the cleaner_mutex earlier in qgroup disable [+ + +]
Author: Josef Bacik <[email protected]>
Date:   Fri Apr 19 14:38:48 2024 -0400

    btrfs: take the cleaner_mutex earlier in qgroup disable
    
    [ Upstream commit 0f2b8098d72a93890e69aa24ec549ef4bc34f4db ]
    
    One of my CI runs popped the following lockdep splat
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.9.0-rc4+ #1 Not tainted
    ------------------------------------------------------
    btrfs/471533 is trying to acquire lock:
    ffff92ba46980850 (&fs_info->cleaner_mutex){+.+.}-{3:3}, at: btrfs_quota_disable+0x54/0x4c0
    
    but task is already holding lock:
    ffff92ba46980bd0 (&fs_info->subvol_sem){++++}-{3:3}, at: btrfs_ioctl+0x1c8f/0x2600
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #2 (&fs_info->subvol_sem){++++}-{3:3}:
           down_read+0x42/0x170
           btrfs_rename+0x607/0xb00
           btrfs_rename2+0x2e/0x70
           vfs_rename+0xaf8/0xfc0
           do_renameat2+0x586/0x600
           __x64_sys_rename+0x43/0x50
           do_syscall_64+0x95/0x180
           entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    -> #1 (&sb->s_type->i_mutex_key#16){++++}-{3:3}:
           down_write+0x3f/0xc0
           btrfs_inode_lock+0x40/0x70
           prealloc_file_extent_cluster+0x1b0/0x370
           relocate_file_extent_cluster+0xb2/0x720
           relocate_data_extent+0x107/0x160
           relocate_block_group+0x442/0x550
           btrfs_relocate_block_group+0x2cb/0x4b0
           btrfs_relocate_chunk+0x50/0x1b0
           btrfs_balance+0x92f/0x13d0
           btrfs_ioctl+0x1abf/0x2600
           __x64_sys_ioctl+0x97/0xd0
           do_syscall_64+0x95/0x180
           entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    -> #0 (&fs_info->cleaner_mutex){+.+.}-{3:3}:
           __lock_acquire+0x13e7/0x2180
           lock_acquire+0xcb/0x2e0
           __mutex_lock+0xbe/0xc00
           btrfs_quota_disable+0x54/0x4c0
           btrfs_ioctl+0x206b/0x2600
           __x64_sys_ioctl+0x97/0xd0
           do_syscall_64+0x95/0x180
           entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    other info that might help us debug this:
    
    Chain exists of:
      &fs_info->cleaner_mutex --> &sb->s_type->i_mutex_key#16 --> &fs_info->subvol_sem
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&fs_info->subvol_sem);
                                   lock(&sb->s_type->i_mutex_key#16);
                                   lock(&fs_info->subvol_sem);
      lock(&fs_info->cleaner_mutex);
    
     *** DEADLOCK ***
    
    2 locks held by btrfs/471533:
     #0: ffff92ba4319e420 (sb_writers#14){.+.+}-{0:0}, at: btrfs_ioctl+0x3b5/0x2600
     #1: ffff92ba46980bd0 (&fs_info->subvol_sem){++++}-{3:3}, at: btrfs_ioctl+0x1c8f/0x2600
    
    stack backtrace:
    CPU: 1 PID: 471533 Comm: btrfs Kdump: loaded Not tainted 6.9.0-rc4+ #1
    Call Trace:
     <TASK>
     dump_stack_lvl+0x77/0xb0
     check_noncircular+0x148/0x160
     ? lock_acquire+0xcb/0x2e0
     __lock_acquire+0x13e7/0x2180
     lock_acquire+0xcb/0x2e0
     ? btrfs_quota_disable+0x54/0x4c0
     ? lock_is_held_type+0x9a/0x110
     __mutex_lock+0xbe/0xc00
     ? btrfs_quota_disable+0x54/0x4c0
     ? srso_return_thunk+0x5/0x5f
     ? lock_acquire+0xcb/0x2e0
     ? btrfs_quota_disable+0x54/0x4c0
     ? btrfs_quota_disable+0x54/0x4c0
     btrfs_quota_disable+0x54/0x4c0
     btrfs_ioctl+0x206b/0x2600
     ? srso_return_thunk+0x5/0x5f
     ? __do_sys_statfs+0x61/0x70
     __x64_sys_ioctl+0x97/0xd0
     do_syscall_64+0x95/0x180
     ? srso_return_thunk+0x5/0x5f
     ? reacquire_held_locks+0xd1/0x1f0
     ? do_user_addr_fault+0x307/0x8a0
     ? srso_return_thunk+0x5/0x5f
     ? lock_acquire+0xcb/0x2e0
     ? srso_return_thunk+0x5/0x5f
     ? srso_return_thunk+0x5/0x5f
     ? find_held_lock+0x2b/0x80
     ? srso_return_thunk+0x5/0x5f
     ? lock_release+0xca/0x2a0
     ? srso_return_thunk+0x5/0x5f
     ? do_user_addr_fault+0x35c/0x8a0
     ? srso_return_thunk+0x5/0x5f
     ? trace_hardirqs_off+0x4b/0xc0
     ? srso_return_thunk+0x5/0x5f
     ? lockdep_hardirqs_on_prepare+0xde/0x190
     ? srso_return_thunk+0x5/0x5f
    
    This happens because when we call rename we already have the inode mutex
    held, and then we acquire the subvol_sem if we are a subvolume.  This
    makes the dependency
    
    inode lock -> subvol sem
    
    When we're running data relocation we will preallocate space for the
    data relocation inode, and we always run the relocation under the
    ->cleaner_mutex.  This now creates the dependency of
    
    cleaner_mutex -> inode lock (from the prealloc) -> subvol_sem
    
    Qgroup delete is doing this in the opposite order, it is acquiring the
    subvol_sem and then it is acquiring the cleaner_mutex, which results in
    this lockdep splat.  This deadlock can't happen in reality, because we
    won't ever rename the data reloc inode, nor is the data reloc inode a
    subvolume.
    
    However this is fairly easy to fix, simply take the cleaner mutex in the
    case where we are disabling qgroups before we take the subvol_sem.  This
    resolves the lockdep splat.
    
    Reviewed-by: Filipe Manana <[email protected]>
    Signed-off-by: Josef Bacik <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
clk: mediatek: mt8365-mm: fix DPI0 parent [+ + +]
Author: Alexandre Mergnat <[email protected]>
Date:   Thu Apr 18 16:17:00 2024 +0200

    clk: mediatek: mt8365-mm: fix DPI0 parent
    
    [ Upstream commit 4c0c087772d7e29bc2489ddb068d5167140bfc38 ]
    
    To have a working display through DPI, a workaround has been
    implemented downstream to add "mm_dpi0_dpi0" and "dpi0_sel" to
    the DPI node. Shortly, that add an extra clock.
    
    It seems consistent to have the "dpi0_sel" as parent.
    Additionnaly, "vpll_dpix" isn't used/managed.
    
    Then, set the "mm_dpi0_dpi0" parent clock to "dpi0_sel".
    
    The new clock tree is:
    
    clk26m
      lvdspll
        lvdspll_X (2, 4, 8, 16)
          dpi0_sel
            mm_dpi0_dpi0
    
    Fixes: d46adccb7966 ("clk: mediatek: add driver for MT8365 SoC")
    Signed-off-by: Alexandre Mergnat <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: mediatek: pllfh: Don't log error for missing fhctl node [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Fri Mar 8 15:29:56 2024 -0500

    clk: mediatek: pllfh: Don't log error for missing fhctl node
    
    [ Upstream commit bb7b3c8e7180f36de75cdea200ab7127f93f58cc ]
    
    Support for fhctl clocks in apmixedsys was introduced at a later point
    and to this moment only one mt6795 based platform has a fhctl DT node
    present. Therefore the fhctl support in apmixedsys should be seen as
    optional and not cause an error when it is missing.
    
    Change the message's log level to warning. The warning level is chosen
    so that it will still alert the fact that fhctl support might be
    unintentionally missing, but without implying that this is necessarily
    an issue.
    
    Even if the FHCTL DT nodes are added to all current platforms moving
    forward, since those changes won't be backported, this ensures stable
    kernel releases won't have live with this error.
    
    Fixes: d7964de8a8ea ("clk: mediatek: Add new clock driver to handle FHCTL hardware")
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: apss-ipq-pll: fix PLL rate for IPQ5018 [+ + +]
Author: Gabor Juhos <[email protected]>
Date:   Tue Mar 26 14:34:11 2024 +0100

    clk: qcom: apss-ipq-pll: fix PLL rate for IPQ5018
    
    [ Upstream commit c55f7ee2ec239b6afd8639c7ac06493876deb0ea ]
    
    According to ipq5018.dtsi, the maximum supported rate by the
    CPU is 1.008 GHz on the IPQ5018 platform, however the current
    configuration of the PLL results in 1.2 GHz rate.
    
    Change the 'L' value in the PLL configuration to limit the
    rate to 1.008 GHz. The downstream kernel also uses the same
    value [1]. Also add a comment to indicate the desired
    frequency.
    
    [1] https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4/drivers/clk/qcom/apss-ipq5018.c?ref_type=heads#L151
    
    Fixes: 50492f929486 ("clk: qcom: apss-ipq-pll: add support for IPQ5018")
    Signed-off-by: Gabor Juhos <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: clk-alpha-pll: remove invalid Stromer register offset [+ + +]
Author: Gabor Juhos <[email protected]>
Date:   Mon Mar 11 19:45:19 2024 +0100

    clk: qcom: clk-alpha-pll: remove invalid Stromer register offset
    
    [ Upstream commit 4f2bc4acbb1916b8cd2ce4bb3ba7b1cd7cb705fa ]
    
    The offset of the CONFIG_CTL_U register defined for the Stromer
    PLL is wrong. It is not aligned on a 4 bytes boundary which might
    causes errors in regmap operations.
    
    Maybe the intention behind of using the 0xff value was to indicate
    that the register is not implemented in the PLL, but this is not
    verified anywhere in the code. Moreover, this value is not used
    even in other register offset arrays despite that those PLLs also
    have unimplemented registers.
    
    Additionally, on the Stromer PLLs the current code only touches
    the CONFIG_CTL_U register if the result of pll_has_64bit_config()
    is true which condition is not affected by the change.
    
    Due to the reasons above, simply remove the CONFIG_CTL_U entry
    from the Stromer specific array.
    
    Fixes: e47a4f55f240 ("clk: qcom: clk-alpha-pll: Add support for Stromer PLLs")
    Signed-off-by: Gabor Juhos <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: dispcc-sm6350: fix DisplayPort clocks [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Apr 24 04:39:30 2024 +0300

    clk: qcom: dispcc-sm6350: fix DisplayPort clocks
    
    [ Upstream commit 1113501cfb46d5c0eb960f0a8a9f6c0f91dc6fb6 ]
    
    On SM6350 DisplayPort link clocks use frequency tables inherited from
    the vendor kernel, it is not applicable in the upstream kernel. Drop
    frequency tables and use clk_byte2_ops for those clocks.
    
    This fixes frequency selection in the OPP core (which otherwise attempts
    to use invalid 810 KHz as DP link rate), also fixing the following
    message:
    msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22
    
    Fixes: 837519775f1d ("clk: qcom: Add display clock controller driver for SM6350")
    Reviewed-by: Neil Armstrong <[email protected]>
    Tested-by: Luca Weiss <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: dispcc-sm8450: fix DisplayPort clocks [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Apr 24 04:39:29 2024 +0300

    clk: qcom: dispcc-sm8450: fix DisplayPort clocks
    
    [ Upstream commit e801038a02ce1e8c652a0b668dd233a4ee48aeb7 ]
    
    On SM8450 DisplayPort link clocks use frequency tables inherited from
    the vendor kernel, it is not applicable in the upstream kernel. Drop
    frequency tables and use clk_byte2_ops for those clocks.
    
    This fixes frequency selection in the OPP core (which otherwise attempts
    to use invalid 810 KHz as DP link rate), also fixing the following
    message:
    msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22
    
    Fixes: 16fb89f92ec4 ("clk: qcom: Add support for Display Clock Controller on SM8450")
    Reviewed-by: Neil Armstrong <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: dispcc-sm8550: fix DisplayPort clocks [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Apr 24 04:39:31 2024 +0300

    clk: qcom: dispcc-sm8550: fix DisplayPort clocks
    
    [ Upstream commit e90b5139da8465a15c3820b4b67ca9468dce93b4 ]
    
    On SM8550 DisplayPort link clocks use frequency tables inherited from
    the vendor kernel, it is not applicable in the upstream kernel. Drop
    frequency tables and use clk_byte2_ops for those clocks.
    
    This fixes frequency selection in the OPP core (which otherwise attempts
    to use invalid 810 KHz as DP link rate), also fixing the following
    message:
    msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22
    
    Fixes: 90114ca11476 ("clk: qcom: add SM8550 DISPCC driver")
    Reviewed-by: Neil Armstrong <[email protected]>
    Tested-by: Neil Armstrong <[email protected]> # on SM8550-HDK
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: dispcc-sm8650: fix DisplayPort clocks [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Apr 24 04:39:32 2024 +0300

    clk: qcom: dispcc-sm8650: fix DisplayPort clocks
    
    [ Upstream commit 615a292ee4d51303246278f3fa33cc38700fe00e ]
    
    On SM8650 DisplayPort link clocks use frequency tables inherited from
    the vendor kernel, it is not applicable in the upstream kernel. Drop
    frequency tables and use clk_byte2_ops for those clocks.
    
    This fixes frequency selection in the OPP core (which otherwise attempts
    to use invalid 810 KHz as DP link rate), also fixing the following
    message:
    msm-dp-display af54000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22
    
    Fixes: 9e939f008338 ("clk: qcom: add the SM8650 Display Clock Controller driver")
    Reviewed-by: Neil Armstrong <[email protected]>
    Tested-by: Neil Armstrong <[email protected]> # on SM8650-HDK
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: Fix SC_CAMCC_8280XP dependencies [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Mon Mar 18 08:18:10 2024 -0700

    clk: qcom: Fix SC_CAMCC_8280XP dependencies
    
    [ Upstream commit e00f2540a581f8b8c165e5ae8afe52e4ad038550 ]
    
    CONFIG_SC_GCC_8280XP depends on ARM64 but it is selected by
    CONFIG_SC_CAMCC_8280XP, which can be selected on ARM, resulting in a
    Kconfig warning.
    
    WARNING: unmet direct dependencies detected for SC_GCC_8280XP
      Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_QCOM [=y] && (ARM64 || COMPILE_TEST [=n])
      Selected by [y]:
      - SC_CAMCC_8280XP [=y] && COMMON_CLK [=y] && COMMON_CLK_QCOM [=y]
    
    Add the same dependencies to CONFIG_SC_CAMCC_8280XP to resolve the
    warning.
    
    Fixes: ff93872a9c61 ("clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC")
    Signed-off-by: Nathan Chancellor <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: Fix SM_GPUCC_8650 dependencies [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Mon Mar 18 08:18:11 2024 -0700

    clk: qcom: Fix SM_GPUCC_8650 dependencies
    
    [ Upstream commit 07fb0a76bb757990b99fc2ab78ad7d1709cc441d ]
    
    CONFIG_SM_GCC_8650 depends on ARM64 but it is selected by
    CONFIG_SM_GPUCC_8650, which can be selected on ARM, resulting in a
    Kconfig warning.
    
    WARNING: unmet direct dependencies detected for SM_GCC_8650
      Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_QCOM [=y] && (ARM64 || COMPILE_TEST [=n])
      Selected by [y]:
      - SM_GPUCC_8650 [=y] && COMMON_CLK [=y] && COMMON_CLK_QCOM [=y]
    
    Add the same dependencies to CONFIG_SM_GPUCC_8650 to resolve the
    warning.
    
    Fixes: 8676fd4f3874 ("clk: qcom: add the SM8650 GPU Clock Controller driver")
    Signed-off-by: Nathan Chancellor <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: mmcc-msm8998: fix venus clock issue [+ + +]
Author: Marc Gonzalez <[email protected]>
Date:   Thu Apr 25 17:07:07 2024 +0200

    clk: qcom: mmcc-msm8998: fix venus clock issue
    
    [ Upstream commit e20ae5ae9f0c843aded4f06f3d1cab7384789e92 ]
    
    Right now, msm8998 video decoder (venus) is non-functional:
    
    $ time mpv --hwdec=v4l2m2m-copy --vd-lavc-software-fallback=no --vo=null --no-audio --untimed --length=30 --quiet demo-480.webm
     (+) Video --vid=1 (*) (vp9 854x480 29.970fps)
         Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
    [ffmpeg/video] vp9_v4l2m2m: output VIDIOC_REQBUFS failed: Connection timed out
    [ffmpeg/video] vp9_v4l2m2m: no v4l2 output context's buffers
    [ffmpeg/video] vp9_v4l2m2m: can't configure decoder
    Could not open codec.
    Software decoding fallback is disabled.
    Exiting... (Quit)
    
    Bryan O'Donoghue suggested the proper fix:
    - Set required register offsets in venus GDSC structs.
    - Set HW_CTRL flag.
    
    $ time mpv --hwdec=v4l2m2m-copy --vd-lavc-software-fallback=no --vo=null --no-audio --untimed --length=30 --quiet demo-480.webm
     (+) Video --vid=1 (*) (vp9 854x480 29.970fps)
         Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
    [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
    [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
    ...
    Using hardware decoding (v4l2m2m-copy).
    VO: [null] 854x480 nv12
    Exiting... (End of file)
    real    0m3.315s
    user    0m1.277s
    sys     0m0.453s
    
    NOTES:
    
    GDSC = Globally Distributed Switch Controller
    
    Use same code as mmcc-msm8996 with:
    s/venus_gdsc/video_top_gdsc/
    s/venus_core0_gdsc/video_subcore0_gdsc/
    s/venus_core1_gdsc/video_subcore1_gdsc/
    
    https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/include/dt-bindings/clock/msm-clocks-hwio-8996.h
    https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/include/dt-bindings/clock/msm-clocks-hwio-8998.h
    
    0x1024 = MMSS_VIDEO GDSCR (undocumented)
    0x1028 = MMSS_VIDEO_CORE_CBCR
    0x1030 = MMSS_VIDEO_AHB_CBCR
    0x1034 = MMSS_VIDEO_AXI_CBCR
    0x1038 = MMSS_VIDEO_MAXI_CBCR
    0x1040 = MMSS_VIDEO_SUBCORE0 GDSCR (undocumented)
    0x1044 = MMSS_VIDEO_SUBCORE1 GDSCR (undocumented)
    0x1048 = MMSS_VIDEO_SUBCORE0_CBCR
    0x104c = MMSS_VIDEO_SUBCORE1_CBCR
    
    Fixes: d14b15b5931c2b ("clk: qcom: Add MSM8998 Multimedia Clock Controller (MMCC) driver")
    Reviewed-by: Bryan O'Donoghue <[email protected]>
    Signed-off-by: Marc Gonzalez <[email protected]>
    Reviewed-by: Jeffrey Hugo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: renesas: r8a779a0: Fix CANFD parent clock [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Apr 16 17:00:51 2024 +0200

    clk: renesas: r8a779a0: Fix CANFD parent clock
    
    [ Upstream commit 3b23118bdbd898dc2f4de8f549d598d492c42ba8 ]
    
    According to Figure 52A.1 ("RS-CANFD Module Block Diagram (in classical
    CAN mode)") in the R-Car V3U Series User’s Manual Rev. 0.5, the parent
    clock for the CANFD peripheral module clock is the S3D2 clock.
    
    Fixes: 9b621b6adff53346 ("clk: renesas: r8a779a0: Add CANFD module clock")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/aef9300f44c9141b1465343f91c5cc7303249b6e.1713279523.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <[email protected]>

clk: renesas: r9a07g043: Add clock and reset entry for PLIC [+ + +]
Author: Lad Prabhakar <[email protected]>
Date:   Wed Apr 3 21:09:52 2024 +0100

    clk: renesas: r9a07g043: Add clock and reset entry for PLIC
    
    [ Upstream commit 44019387fce230beda35b83da3a2c9fc5787704e ]
    
    Add the missing clock and reset entry for PLIC. Also add
    R9A07G043_NCEPLIC_ACLK to the critical clocks list.
    
    Fixes: 95d48d270305ad2c ("clk: renesas: r9a07g043: Add support for RZ/Five SoC")
    Signed-off-by: Lad Prabhakar <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: rs9: fix wrong default value for clock amplitude [+ + +]
Author: Catalin Popescu <[email protected]>
Date:   Mon Apr 15 16:03:48 2024 +0200

    clk: rs9: fix wrong default value for clock amplitude
    
    [ Upstream commit 1758c68c81b8b881818fcebaaeb91055362a82f8 ]
    
    According to 9FGV0241, 9FGV0441 & 9FGV0841 datasheets, the default
    value for the clock amplitude is 0.8V, while the driver assumes 0.7V.
    
    Additionally, define constants for default values for both clock
    amplitude and spread spectrum and use them.
    
    Fixes: 892e0ddea1aa ("clk: rs9: Add Renesas 9-series PCIe clock generator driver")
    Signed-off-by: Catalin Popescu <[email protected]>
    Reviewed-by: Marek Vasut <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: samsung: exynosautov9: fix wrong pll clock id value [+ + +]
Author: Jaewon Kim <[email protected]>
Date:   Thu Mar 28 18:10:00 2024 +0900

    clk: samsung: exynosautov9: fix wrong pll clock id value
    
    [ Upstream commit 04ee3a0b44e3d18cf6b0c712d14b98624877fd26 ]
    
    All PLL id values of CMU_TOP were incorrectly set to FOUT_SHARED0_PLL.
    It modified to the correct PLL clock id value.
    
    Fixes: 6587c62f69dc ("clk: samsung: add top clock support for Exynos Auto v9 SoC")
    Signed-off-by: Jaewon Kim <[email protected]>
    Reviewed-by: Sam Protsenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cppc_cpufreq: Fix possible null pointer dereference [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Mon Apr 8 12:35:36 2024 +0300

    cppc_cpufreq: Fix possible null pointer dereference
    
    [ Upstream commit cf7de25878a1f4508c69dc9f6819c21ba177dbfe ]
    
    cppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called from
    different places with various parameters. So cpufreq_cpu_get() can return
    null as 'policy' in some circumstances.
    Fix this bug by adding null return check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: a28b2bfc099c ("cppc_cpufreq: replace per-cpu data array with a list")
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n [+ + +]
Author: Sean Christopherson <[email protected]>
Date:   Fri Apr 19 17:05:55 2024 -0700

    cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n
    
    [ Upstream commit ce0abef6a1d540acef85068e0e82bdf1fbeeb0e9 ]
    
    Explicitly disallow enabling mitigations at runtime for kernels that were
    built with CONFIG_CPU_MITIGATIONS=n, as some architectures may omit code
    entirely if mitigations are disabled at compile time.
    
    E.g. on x86, a large pile of Kconfigs are buried behind CPU_MITIGATIONS,
    and trying to provide sane behavior for retroactively enabling mitigations
    is extremely difficult, bordering on impossible.  E.g. page table isolation
    and call depth tracking require build-time support, BHI mitigations will
    still be off without additional kernel parameters, etc.
    
      [ bp: Touchups. ]
    
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Acked-by: Borislav Petkov (AMD) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
cpufreq: brcmstb-avs-cpufreq: ISO C90 forbids mixed declarations [+ + +]
Author: Portia Stephens <[email protected]>
Date:   Wed Apr 24 15:02:20 2024 +1000

    cpufreq: brcmstb-avs-cpufreq: ISO C90 forbids mixed declarations
    
    [ Upstream commit fa7bd98f3c8b33fb68c6b2bc69cff32b63db69f8 ]
    
    There is a compile warning because a NULL pointer check was added before
    a struct was declared. This moves the NULL pointer check to after the
    struct is declared and moves the struct assignment to after the NULL
    pointer check.
    
    Fixes: f661017e6d32 ("cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value")
    Signed-off-by: Portia Stephens <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

cpufreq: exit() callback is optional [+ + +]
Author: Viresh Kumar <[email protected]>
Date:   Fri Apr 12 11:19:20 2024 +0530

    cpufreq: exit() callback is optional
    
    [ Upstream commit b8f85833c05730d631576008daaa34096bc7f3ce ]
    
    The exit() callback is optional and shouldn't be called without checking
    a valid pointer first.
    
    Also, we must clear freq_table pointer even if the exit() callback isn't
    present.
    
    Signed-off-by: Viresh Kumar <[email protected]>
    Fixes: 91a12e91dc39 ("cpufreq: Allow light-weight tear down and bring up of CPUs")
    Fixes: f339f3541701 ("cpufreq: Rearrange locking in cpufreq_remove_dev()")
    Reported-by: Lizhe <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
crypto: bcm - Fix pointer arithmetic [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Fri Mar 22 23:59:15 2024 +0300

    crypto: bcm - Fix pointer arithmetic
    
    [ Upstream commit 2b3460cbf454c6b03d7429e9ffc4fe09322eb1a9 ]
    
    In spu2_dump_omd() value of ptr is increased by ciph_key_len
    instead of hash_iv_len which could lead to going beyond the
    buffer boundaries.
    Fix this bug by changing ciph_key_len to hash_iv_len.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: ccp - drop platform ifdef checks [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Apr 3 10:06:42 2024 +0200

    crypto: ccp - drop platform ifdef checks
    
    [ Upstream commit 42c2d7d02977ef09d434b1f5b354f5bc6c1027ab ]
    
    When both ACPI and OF are disabled, the dev_vdata variable is unused:
    
    drivers/crypto/ccp/sp-platform.c:33:34: error: unused variable 'dev_vdata' [-Werror,-Wunused-const-variable]
    
    This is not a useful configuration, and there is not much point in saving
    a few bytes when only one of the two is enabled, so just remove all
    these ifdef checks and rely on of_match_node() and acpi_match_device()
    returning NULL when these subsystems are disabled.
    
    Fixes: 6c5063434098 ("crypto: ccp - Add ACPI support")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Acked-by: Tom Lendacky <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: octeontx2 - add missing check for dma_map_single [+ + +]
Author: Chen Ni <[email protected]>
Date:   Mon Apr 8 01:59:14 2024 +0000

    crypto: octeontx2 - add missing check for dma_map_single
    
    [ Upstream commit 6a6d6a3a328a59ed0d8ae2e65696ef38e49133a0 ]
    
    Add check for dma_map_single() and return error if it fails in order
    to avoid invalid dma address.
    
    Fixes: e92971117c2c ("crypto: octeontx2 - add ctx_val workaround")
    Signed-off-by: Chen Ni <[email protected]>
    Reviewed-by: Bharat Bhushan <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - improve error logging to be consistent across features [+ + +]
Author: Adam Guerin <[email protected]>
Date:   Fri Apr 12 13:24:03 2024 +0100

    crypto: qat - improve error logging to be consistent across features
    
    [ Upstream commit d281a28bd2a94d72c440457e05a2f04a52f15947 ]
    
    Improve error logging in rate limiting feature. Staying consistent with
    the error logging found in the telemetry feature.
    
    Fixes: d9fb8408376e ("crypto: qat - add rate limiting feature to qat_4xxx")
    Signed-off-by: Adam Guerin <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - improve error message in adf_get_arbiter_mapping() [+ + +]
Author: Adam Guerin <[email protected]>
Date:   Fri Apr 12 13:24:02 2024 +0100

    crypto: qat - improve error message in adf_get_arbiter_mapping()
    
    [ Upstream commit 4a4fc6c0c7fe29f2538013a57ebd7813ec6c12a8 ]
    
    Improve error message to be more readable.
    
    Fixes: 5da6a2d5353e ("crypto: qat - generate dynamically arbiter mappings")
    Signed-off-by: Adam Guerin <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - specify firmware files for 402xx [+ + +]
Author: Giovanni Cabiddu <[email protected]>
Date:   Mon Apr 22 15:13:17 2024 +0100

    crypto: qat - specify firmware files for 402xx
    
    [ Upstream commit a3dc1f2b6b932a13f139d3be3c765155542c1070 ]
    
    The 4xxx driver can probe 4xxx and 402xx devices. However, the driver
    only specifies the firmware images required for 4xxx.
    This might result in external tools missing these binaries, if required,
    in the initramfs.
    
    Specify the firmware image used by 402xx with the MODULE_FIRMWARE()
    macros in the 4xxx driver.
    
    Fixes: a3e8c919b993 ("crypto: qat - add support for 402xx devices")
    Signed-off-by: Giovanni Cabiddu <[email protected]>
    Reviewed-by: Damian Muszynski <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: qat - validate slices count returned by FW [+ + +]
Author: Lucas Segarra Fernandez <[email protected]>
Date:   Tue Apr 16 12:33:37 2024 +0200

    crypto: qat - validate slices count returned by FW
    
    [ Upstream commit 483fd65ce29317044d1d00757e3fd23503b6b04c ]
    
    The function adf_send_admin_tl_start() enables the telemetry (TL)
    feature on a QAT device by sending the ICP_QAT_FW_TL_START message to
    the firmware. This triggers the FW to start writing TL data to a DMA
    buffer in memory and returns an array containing the number of
    accelerators of each type (slices) supported by this HW.
    The pointer to this array is stored in the adf_tl_hw_data data
    structure called slice_cnt.
    
    The array slice_cnt is then used in the function tl_print_dev_data()
    to report in debugfs only statistics about the supported accelerators.
    An incorrect value of the elements in slice_cnt might lead to an out
    of bounds memory read.
    At the moment, there isn't an implementation of FW that returns a wrong
    value, but for robustness validate the slice count array returned by FW.
    
    Fixes: 69e7649f7cc2 ("crypto: qat - add support for device telemetry")
    Signed-off-by: Lucas Segarra Fernandez <[email protected]>
    Reviewed-by: Damian Muszynski <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: x86/nh-avx2 - add missing vzeroupper [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Fri Apr 5 20:26:08 2024 -0400

    crypto: x86/nh-avx2 - add missing vzeroupper
    
    [ Upstream commit 4ad096cca942959871d8ff73826d30f81f856f6e ]
    
    Since nh_avx2() uses ymm registers, execute vzeroupper before returning
    from it.  This is necessary to avoid reducing the performance of SSE
    code.
    
    Fixes: 0f961f9f670e ("crypto: x86/nhpoly1305 - add AVX2 accelerated NHPoly1305")
    Signed-off-by: Eric Biggers <[email protected]>
    Acked-by: Tim Chen <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: x86/sha256-avx2 - add missing vzeroupper [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Fri Apr 5 20:26:09 2024 -0400

    crypto: x86/sha256-avx2 - add missing vzeroupper
    
    [ Upstream commit 57ce8a4e162599cf9adafef1f29763160a8e5564 ]
    
    Since sha256_transform_rorx() uses ymm registers, execute vzeroupper
    before returning from it.  This is necessary to avoid reducing the
    performance of SSE code.
    
    Fixes: d34a460092d8 ("crypto: sha256 - Optimized sha256 x86_64 routine using AVX2's RORX instructions")
    Signed-off-by: Eric Biggers <[email protected]>
    Acked-by: Tim Chen <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: x86/sha512-avx2 - add missing vzeroupper [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Fri Apr 5 20:26:10 2024 -0400

    crypto: x86/sha512-avx2 - add missing vzeroupper
    
    [ Upstream commit 6a24fdfe1edbafacdacd53516654d99068f20eec ]
    
    Since sha512_transform_rorx() uses ymm registers, execute vzeroupper
    before returning from it.  This is necessary to avoid reducing the
    performance of SSE code.
    
    Fixes: e01d69cb0195 ("crypto: sha512 - Optimized SHA512 x86_64 assembly routine using AVX instructions.")
    Signed-off-by: Eric Biggers <[email protected]>
    Acked-by: Tim Chen <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dev_printk: Add and use dev_no_printk() [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Wed Feb 28 15:00:03 2024 +0100

    dev_printk: Add and use dev_no_printk()
    
    [ Upstream commit c26ec799042a3888935d59b599f33e41efedf5f8 ]
    
    When printk-indexing is enabled, each dev_printk() invocation emits a
    pi_entry structure.  This is even true when the dev_printk() is
    protected by an always-false check, as is typically the case for debug
    messages: while the actual code to print the message is optimized out by
    the compiler, the pi_entry structure is still emitted.
    
    Avoid emitting pi_entry structures for unavailable dev_printk() kernel
    messages by:
      1. Introducing a dev_no_printk() helper, mimicked after the existing
         no_printk() helper, which calls _dev_printk() instead of
         dev_printk(),
      2. Replacing all "if (0) dev_printk(...)" constructs by calls to the
         new helper.
    
    This reduces the size of an arm64 defconfig kernel with
    CONFIG_PRINTK_INDEX=y by 957 KiB.
    
    Fixes: ad7d61f159db7397 ("printk: index: Add indexing support to dev_printk")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Reviewed-by: Xiubo Li <[email protected]>
    Reviewed-by: Chris Down <[email protected]>
    Reviewed-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/8583d54f1687c801c6cda8edddf2cf0344c6e883.1709127473.git.geert+renesas@glider.be
    Signed-off-by: Petr Mladek <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dlm: fix user space lock decision to copy lvb [+ + +]
Author: Alexander Aring <[email protected]>
Date:   Thu Mar 28 11:48:33 2024 -0400

    dlm: fix user space lock decision to copy lvb
    
    [ Upstream commit ad191e0eeebf64a60ca2d16ca01a223d2b1dd25e ]
    
    This patch fixes the copy lvb decision for user space lock requests.
    Checking dlm_lvb_operations is done earlier, where granted/requested
    lock modes are available to use in the matrix.
    
    The decision had been moved to the wrong location, where granted mode
    and requested mode where the same, which causes the dlm_lvb_operations
    matix to produce the wrong copy decision. For PW or EX requests, the
    caller could get invalid lvb data.
    
    Fixes: 61bed0baa4db ("fs: dlm: use a non-static queue for callbacks")
    Signed-off-by: Alexander Aring <[email protected]>
    Signed-off-by: David Teigland <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dm-delay: fix hung task introduced by kthread mode [+ + +]
Author: Joel Colledge <[email protected]>
Date:   Mon May 6 09:25:23 2024 +0200

    dm-delay: fix hung task introduced by kthread mode
    
    [ Upstream commit d14646f23300a5fc85be867bafdc0702c2002789 ]
    
    If the worker thread is not woken due to a bio, then it is not woken at
    all. This causes the hung task check to trigger. This occurs, for
    instance, when no bios are submitted. Also when a delay of 0 is
    configured, delay_bio() returns without waking the worker.
    
    Prevent the hung task check from triggering by creating the thread with
    kthread_run() instead of using kthread_create() directly.
    
    Fixes: 70bbeb29fab0 ("dm delay: for short delays, use kthread instead of timers and wq")
    Signed-off-by: Joel Colledge <[email protected]>
    Reviewed-by: Benjamin Marzinski <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dm-delay: fix max_delay calculations [+ + +]
Author: Benjamin Marzinski <[email protected]>
Date:   Mon May 6 17:55:44 2024 -0400

    dm-delay: fix max_delay calculations
    
    [ Upstream commit 64eb88d6caee2c8eb806a68dab3f184f14f818a4 ]
    
    delay_ctr() pointlessly compared max_delay in cases where multiple delay
    classes were initialized identically. Also, when write delays were
    configured different than read delays, delay_ctr() never compared their
    value against max_delay. Fix these issues.
    
    Fixes: 70bbeb29fab0 ("dm delay: for short delays, use kthread instead of timers and wq")
    Signed-off-by: Benjamin Marzinski <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dm-delay: fix workqueue delay_timer race [+ + +]
Author: Benjamin Marzinski <[email protected]>
Date:   Tue May 7 17:16:23 2024 -0400

    dm-delay: fix workqueue delay_timer race
    
    [ Upstream commit 8d24790ed08ab4e619ce58ed4a1b353ab77ffdc5 ]
    
    delay_timer could be pending when delay_dtr() is called. It needs to be
    shut down before kdelayd_wq is destroyed, so it won't try queueing more
    work to kdelayd_wq while that's getting destroyed.
    
    Also the del_timer_sync() call in delay_presuspend() doesn't protect
    against the timer getting immediately rearmed by the queued call to
    flush_delayed_bios(), but there's no real harm if that does happen.
    timer_delete() is less work, and is basically just as likely to stop a
    pointless call to flush_delayed_bios().
    
    Fixes: 26b9f228703f ("dm: delay target")
    Signed-off-by: Benjamin Marzinski <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dmaengine: xilinx: xdma: Clarify kdoc in XDMA driver [+ + +]
Author: Miquel Raynal <[email protected]>
Date:   Wed Mar 27 10:58:50 2024 +0100

    dmaengine: xilinx: xdma: Clarify kdoc in XDMA driver
    
    [ Upstream commit 7a71c6dc21d5ae83ab27c39a67845d6d23ac271f ]
    
    Clarify the kernel doc of xdma_fill_descs(), especially how big chunks
    will be handled.
    
    Signed-off-by: Miquel Raynal <[email protected]>
    Signed-off-by: Louis Chauvet <[email protected]>
    Link: https://lore.kernel.org/stable/20240327-digigram-xdma-fixes-v1-3-45f4a52c0283%40bootlin.com
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dpll: fix return value check for kmemdup [+ + +]
Author: Chen Ni <[email protected]>
Date:   Mon May 13 11:28:24 2024 +0800

    dpll: fix return value check for kmemdup
    
    [ Upstream commit ad506586cb69292b6ac59ab95468aadd54b19ab7 ]
    
    The return value of kmemdup() is dst->freq_supported, not
    src->freq_supported. Update the check accordingly.
    
    Fixes: 830ead5fb0c5 ("dpll: fix pin dump crash for rebound module")
    Signed-off-by: Chen Ni <[email protected]>
    Reviewed-by: Przemek Kitszel <[email protected]>
    Reviewed-by: Arkadiusz Kubalewski <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset() [+ + +]
Author: Hao Chen <[email protected]>
Date:   Thu Apr 25 20:46:27 2024 +0800

    drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()
    
    [ Upstream commit 582c1aeee0a9e73010cf1c4cef338709860deeb0 ]
    
    pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()
    fails, the irq vector is not freed, which leads to a memory leak.
    
    Replace the devm_add_action with devm_add_action_or_reset to ensure
    the irq vector can be destroyed when it fails.
    
    Fixes: 66637ab137b4 ("drivers/perf: hisi: add driver for HNS3 PMU")
    Signed-off-by: Hao Chen <[email protected]>
    Signed-off-by: Junhao He <[email protected]>
    Reviewed-by: Jijie Shao <[email protected]>
    Acked-by: Jonathan Cameron <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group [+ + +]
Author: Junhao He <[email protected]>
Date:   Thu Apr 25 20:46:26 2024 +0800

    drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group
    
    [ Upstream commit 81bdd60a3d1d3b05e6cc6674845afb1694dd3a0e ]
    
    The perf tool allows users to create event groups through following
    cmd [1], but the driver does not check whether the array index is out
    of bounds when writing data to the event_group array. If the number of
    events in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, the
    memory write overflow of event_group array occurs.
    
    Add array index check to fix the possible array out of bounds violation,
    and return directly when write new events are written to array bounds.
    
    There are 9 different events in an event_group.
    [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}
    
    Fixes: 66637ab137b4 ("drivers/perf: hisi: add driver for HNS3 PMU")
    Signed-off-by: Junhao He <[email protected]>
    Signed-off-by: Hao Chen <[email protected]>
    Acked-by: Jonathan Cameron <[email protected]>
    Reviewed-by: Jijie Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group [+ + +]
Author: Junhao He <[email protected]>
Date:   Thu Apr 25 20:46:25 2024 +0800

    drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group
    
    [ Upstream commit 77fce82678ea5fd51442e62febec2004f79e041b ]
    
    The perf tool allows users to create event groups through following
    cmd [1], but the driver does not check whether the array index is out of
    bounds when writing data to the event_group array. If the number of events
    in an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write
    overflow of event_group array occurs.
    
    Add array index check to fix the possible array out of bounds violation,
    and return directly when write new events are written to array bounds.
    
    There are 9 different events in an event_group.
    [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'
    
    Fixes: 8404b0fbc7fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU")
    Signed-off-by: Junhao He <[email protected]>
    Reviewed-by: Jijie Shao <[email protected]>
    Acked-by: Jonathan Cameron <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map() [+ + +]
Author: David Hildenbrand <[email protected]>
Date:   Wed Apr 10 17:55:25 2024 +0200

    drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()
    
    [ Upstream commit 3d6586008f7b638f91f3332602592caa8b00b559 ]
    
    Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes".
    
    Patch #1 fixes a bunch of issues I spotted in the acrn driver.  It
    compiles, that's all I know.  I'll appreciate some review and testing from
    acrn folks.
    
    Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding
    more sanity checks, and improving the documentation.  Gave it a quick test
    on x86-64 using VM_PAT that ends up using follow_pte().
    
    This patch (of 3):
    
    We currently miss handling various cases, resulting in a dangerous
    follow_pte() (previously follow_pfn()) usage.
    
    (1) We're not checking PTE write permissions.
    
    Maybe we should simply always require pte_write() like we do for
    pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for
    ACRN_MEM_ACCESS_WRITE for now.
    
    (2) We're not rejecting refcounted pages.
    
    As we are not using MMU notifiers, messing with refcounted pages is
    dangerous and can result in use-after-free. Let's make sure to reject them.
    
    (3) We are only looking at the first PTE of a bigger range.
    
    We only lookup a single PTE, but memmap->len may span a larger area.
    Let's loop over all involved PTEs and make sure the PFN range is
    actually contiguous. Reject everything else: it couldn't have worked
    either way, and rather made use access PFNs we shouldn't be accessing.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 8a6e85f75a83 ("virt: acrn: obtain pa from VMA with PFNMAP flag")
    Signed-off-by: David Hildenbrand <[email protected]>
    Cc: Alex Williamson <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Fei Li <[email protected]>
    Cc: Gerald Schaefer <[email protected]>
    Cc: Heiko Carstens <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Paolo Bonzini <[email protected]>
    Cc: Yonghua Huang <[email protected]>
    Cc: Sean Christopherson <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/display: Add dtbclk access to dcn315 [+ + +]
Author: Swapnil Patel <[email protected]>
Date:   Tue Apr 2 21:07:46 2024 -0400

    drm/amd/display: Add dtbclk access to dcn315
    
    [ Upstream commit a01b64f31d65bdc917d1afb4cec9915beb6931be ]
    
    [Why & How]
    
    Currently DCN315 clk manager is missing code to enable/disable dtbclk.
    Because of this, "optimized_required" flag is constantly set
    and this prevents FreeSync from engaging for certain high bandwidth
    display Modes which require DTBCLK.
    
    Reviewed-by: Dmytro Laktyushkin <[email protected]>
    Acked-by: Aurabindo Pillai <[email protected]>
    Signed-off-by: Swapnil Patel <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Add VCO speed parameter for DCN31 FPU [+ + +]
Author: Rodrigo Siqueira <[email protected]>
Date:   Thu Apr 18 11:19:03 2024 -0600

    drm/amd/display: Add VCO speed parameter for DCN31 FPU
    
    [ Upstream commit 0e62103bdcbc88281e16add299a946fb3bd02fbe ]
    
    Add VCO speed parameters in the bounding box array.
    
    Acked-by: Wayne Lin <[email protected]>
    Signed-off-by: Rodrigo Siqueira <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Allocate zero bw after bw alloc enable [+ + +]
Author: Meenakshikumar Somasundaram <[email protected]>
Date:   Wed Apr 10 10:46:35 2024 -0400

    drm/amd/display: Allocate zero bw after bw alloc enable
    
    [ Upstream commit 46fe9cb1a9e62f4e6229f48ae303ef8e6c1fdc64 ]
    
    [Why]
    During DP tunnel creation, CM preallocates BW and reduces
    estimated BW of other DPIA. CM release preallocation only
    when allocation is complete. Display mode validation logic
    validates timings based on bw available per host router.
    In multi display setup, this causes bw allocation failure
    when allocation greater than estimated bw.
    
    [How]
    Do zero alloc to make the CM to release preallocation and
    update estimated BW correctly for all DPIAs per host router.
    
    Reviewed-by: PeiChen Huang <[email protected]>
    Acked-by: Aurabindo Pillai <[email protected]>
    Signed-off-by: Meenakshikumar Somasundaram <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Disable seamless boot on 128b/132b encoding [+ + +]
Author: Sung Joon Kim <[email protected]>
Date:   Thu Apr 18 16:59:36 2024 -0400

    drm/amd/display: Disable seamless boot on 128b/132b encoding
    
    [ Upstream commit 6f0c228ed9184287031a66b46a79e5a3d2e73a86 ]
    
    [why]
    preOS will not support display mode programming and link training
    for UHBR rates.
    
    [how]
    If we detect a sink that's UHBR capable, disable seamless boot
    
    Reviewed-by: Anthony Koo <[email protected]>
    Acked-by: Wayne Lin <[email protected]>
    Signed-off-by: Sung Joon Kim <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Ensure that dmcub support flag is set for DCN20 [+ + +]
Author: Rodrigo Siqueira <[email protected]>
Date:   Thu Apr 11 17:38:08 2024 -0600

    drm/amd/display: Ensure that dmcub support flag is set for DCN20
    
    [ Upstream commit be53bd4f00aa4c7db9f41116224c027b4cfce8e3 ]
    
    In the DCN20 resource initialization, ensure that DMCUB support starts
    configured as true.
    
    Signed-off-by: Rodrigo Siqueira <[email protected]>
    Acked-by: Aurabindo Pillai <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Fix DC mode screen flickering on DCN321 [+ + +]
Author: Leo Ma <[email protected]>
Date:   Thu Apr 11 17:17:04 2024 -0400

    drm/amd/display: Fix DC mode screen flickering on DCN321
    
    [ Upstream commit ce649bd2d834db83ecc2756a362c9a1ec61658a5 ]
    
    [Why && How]
    Screen flickering saw on 4K@60 eDP with high refresh rate external
    monitor when booting up in DC mode. DC Mode Capping is disabled
    which caused wrong UCLK being used.
    
    Reviewed-by: Alvin Lee <[email protected]>
    Acked-by: Wayne Lin <[email protected]>
    Signed-off-by: Leo Ma <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Fix potential index out of bounds in color transformation function [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Mon Feb 26 18:38:08 2024 +0530

    drm/amd/display: Fix potential index out of bounds in color transformation function
    
    [ Upstream commit 63ae548f1054a0b71678d0349c7dc9628ddd42ca ]
    
    Fixes index out of bounds issue in the color transformation function.
    The issue could occur when the index 'i' exceeds the number of transfer
    function points (TRANSFER_FUNC_POINTS).
    
    The fix adds a check to ensure 'i' is within bounds before accessing the
    transfer function points. If 'i' is out of bounds, an error message is
    logged and the function returns false to indicate an error.
    
    Reported by smatch:
    drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
    drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
    drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max
    
    Fixes: b629596072e5 ("drm/amd/display: Build unity lut for shaper")
    Cc: Vitaly Prosyak <[email protected]>
    Cc: Charlene Liu <[email protected]>
    Cc: Harry Wentland <[email protected]>
    Cc: Rodrigo Siqueira <[email protected]>
    Cc: Roman Li <[email protected]>
    Cc: Aurabindo Pillai <[email protected]>
    Cc: Tom Chung <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Tom Chung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Remove redundant condition in dcn35_calc_blocks_to_gate() [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Sat Feb 24 09:23:53 2024 +0530

    drm/amd/display: Remove redundant condition in dcn35_calc_blocks_to_gate()
    
    [ Upstream commit a43dbeaba81eb645a12a004c67722c632ed0d94b ]
    
    pipe_ctx->plane_res.mpcc_inst is of a type that can only hold values
    between 0 and 255, so it's always greater than or equal to 0.
    
    Thus the condition 'pipe_ctx->plane_res.mpcc_inst >= 0' was always true
    and has been removed.
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn35/dcn35_hwseq.c:1023 dcn35_calc_blocks_to_gate() warn: always true condition '(pipe_ctx->plane_res.mpcc_inst >= 0) => (0-255 >= 0)'
    
    Fixes: 6f8b7565cca4 ("drm/amd/display: Add DCN35 HWSEQ")
    Cc: Qingqing Zhuo <[email protected]>
    Cc: Harry Wentland <[email protected]>
    Cc: Rodrigo Siqueira <[email protected]>
    Cc: Roman Li <[email protected]>
    Cc: Aurabindo Pillai <[email protected]>
    Cc: Tom Chung <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Rodrigo Siqueira <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Set color_mgmt_changed to true on unsuspend [+ + +]
Author: Joshua Ashton <[email protected]>
Date:   Thu Nov 2 04:21:55 2023 +0000

    drm/amd/display: Set color_mgmt_changed to true on unsuspend
    
    [ Upstream commit 2eb9dd497a698dc384c0dd3e0311d541eb2e13dd ]
    
    Otherwise we can end up with a frame on unsuspend where color management
    is not applied when userspace has not committed themselves.
    
    Fixes re-applying color management on Steam Deck/Gamescope on S3 resume.
    
    Signed-off-by: Joshua Ashton <[email protected]>
    Reviewed-by: Harry Wentland <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/pm: Restore config space after reset [+ + +]
Author: Lijo Lazar <[email protected]>
Date:   Fri Apr 12 13:11:14 2024 +0530

    drm/amd/pm: Restore config space after reset
    
    [ Upstream commit 30d1cda8ce31ab49051ff7159280c542a738b23d ]
    
    During mode-2 reset, pci config space registers are affected at device
    side. However, certain platforms have switches which assign virtual BAR
    addresses and returns the same even after device is reset. This
    affects pci_restore_state() as it doesn't issue another config write, if
    the value read is same as the saved value.
    
    Add a workaround to write saved config space values from driver side.
    Presently, these switches are in platforms with SMU v13.0.6 SOCs, hence
    restrict the workaround only to those.
    
    Signed-off-by: Lijo Lazar <[email protected]>
    Reviewed-by: Asad Kamal <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/mes: fix use-after-free issue [+ + +]
Author: Jack Xiao <[email protected]>
Date:   Mon Apr 22 16:22:54 2024 +0800

    drm/amdgpu/mes: fix use-after-free issue
    
    [ Upstream commit 948255282074d9367e01908b3f5dcf8c10fc9c3d ]
    
    Delete fence fallback timer to fix the ramdom
    use-after-free issue.
    
    v2: move to amdgpu_mes.c
    
    Signed-off-by: Jack Xiao <[email protected]>
    Acked-by: Lijo Lazar <[email protected]>
    Acked-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu: Fix the ring buffer size for queue VM flush [+ + +]
Author: Prike Liang <[email protected]>
Date:   Mon Mar 25 15:33:34 2024 +0800

    drm/amdgpu: Fix the ring buffer size for queue VM flush
    
    [ Upstream commit fe93b0927bc58cb1d64230f45744e527d9d8482c ]
    
    Here are the corrections needed for the queue ring buffer size
    calculation for the following cases:
    - Remove the KIQ VM flush ring usage.
    - Add the invalidate TLBs packet for gfx10 and gfx11 queue.
    - There's no VM flush and PFP sync, so remove the gfx9 real
      ring and compute ring buffer usage.
    
    Signed-off-by: Prike Liang <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: Fix VRAM memory accounting [+ + +]
Author: Mukul Joshi <[email protected]>
Date:   Tue Apr 23 14:40:37 2024 -0400

    drm/amdgpu: Fix VRAM memory accounting
    
    [ Upstream commit f06446ef23216090d1ee8ede1a7d7ae430c22dcc ]
    
    Subtract the VRAM pinned memory when checking for available memory
    in amdgpu_amdkfd_reserve_mem_limit function since that memory is not
    available for use.
    
    Signed-off-by: Mukul Joshi <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: Update BO eviction priorities [+ + +]
Author: Felix Kuehling <[email protected]>
Date:   Thu Apr 18 13:56:42 2024 -0400

    drm/amdgpu: Update BO eviction priorities
    
    [ Upstream commit b0b13d532105e0e682d95214933bb8483a063184 ]
    
    Make SVM BOs more likely to get evicted than other BOs. These BOs
    opportunistically use available VRAM, but can fall back relatively
    seamlessly to system memory. It also avoids SVM migrations evicting
    other, more important BOs as they will evict other SVM allocations
    first.
    
    Signed-off-by: Felix Kuehling <[email protected]>
    Acked-by: Mukul Joshi <[email protected]>
    Tested-by: Mukul Joshi <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdkfd: Add VRAM accounting for SVM migration [+ + +]
Author: Mukul Joshi <[email protected]>
Date:   Thu Apr 18 15:13:58 2024 -0400

    drm/amdkfd: Add VRAM accounting for SVM migration
    
    [ Upstream commit 1e214f7faaf5d842754cd5cfcd76308bfedab3b5 ]
    
    Do VRAM accounting when doing migrations to vram to make sure
    there is enough available VRAM and migrating to VRAM doesn't evict
    other possible non-unified memory BOs. If migrating to VRAM fails,
    driver can fall back to using system memory seamlessly.
    
    Signed-off-by: Mukul Joshi <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdkfd: Flush the process wq before creating a kfd_process [+ + +]
Author: Lancelot SIX <[email protected]>
Date:   Wed Apr 10 14:14:13 2024 +0100

    drm/amdkfd: Flush the process wq before creating a kfd_process
    
    [ Upstream commit f5b9053398e70a0c10aa9cb4dd5910ab6bc457c5 ]
    
    There is a race condition when re-creating a kfd_process for a process.
    This has been observed when a process under the debugger executes
    exec(3).  In this scenario:
    - The process executes exec.
     - This will eventually release the process's mm, which will cause the
       kfd_process object associated with the process to be freed
       (kfd_process_free_notifier decrements the reference count to the
       kfd_process to 0).  This causes kfd_process_ref_release to enqueue
       kfd_process_wq_release to the kfd_process_wq.
    - The debugger receives the PTRACE_EVENT_EXEC notification, and tries to
      re-enable AMDGPU traps (KFD_IOC_DBG_TRAP_ENABLE).
     - When handling this request, KFD tries to re-create a kfd_process.
       This eventually calls kfd_create_process and kobject_init_and_add.
    
    At this point the call to kobject_init_and_add can fail because the
    old kfd_process.kobj has not been freed yet by kfd_process_wq_release.
    
    This patch proposes to avoid this race by making sure to drain
    kfd_process_wq before creating a new kfd_process object.  This way, we
    know that any cleanup task is done executing when we reach
    kobject_init_and_add.
    
    Signed-off-by: Lancelot SIX <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/arm/malidp: fix a possible null pointer dereference [+ + +]
Author: Huai-Yuan Liu <[email protected]>
Date:   Sun Apr 7 14:30:53 2024 +0800

    drm/arm/malidp: fix a possible null pointer dereference
    
    [ Upstream commit a1f95aede6285dba6dd036d907196f35ae3a11ea ]
    
    In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
    no check is performed. In order to prevent null pointer dereferencing,
    ensure that mw_state is checked before calling
    __drm_atomic_helper_connector_reset.
    
    Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector")
    Signed-off-by: Huai-Yuan Liu <[email protected]>
    Signed-off-by: Liviu Dudau <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/bridge: anx7625: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Mon Apr 15 17:49:29 2024 -0400

    drm/bridge: anx7625: Don't log an error when DSI host can't be found
    
    [ Upstream commit ef4a9204d594fe959cdbc7418273caf4001535c8 ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: 269332997a16 ("drm/bridge: anx7625: Return -EPROBE_DEFER if the dsi host was not found")
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-1-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: anx7625: Update audio status while detecting [+ + +]
Author: Hsin-Te Yuan <[email protected]>
Date:   Tue Apr 16 07:21:35 2024 +0000

    drm/bridge: anx7625: Update audio status while detecting
    
    [ Upstream commit a665b4e60369867cddf50f37f16169a3e2f434ad ]
    
    Previously, the audio status was not updated during detection, leading
    to a persistent audio despite hot plugging events. To resolve this
    issue, update the audio status during detection.
    
    Fixes: 566fef1226c1 ("drm/bridge: anx7625: add HDMI audio function")
    Signed-off-by: Hsin-Te Yuan <[email protected]>
    Reviewed-by: Robert Foss <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: dpc3433: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Mon Apr 15 17:49:35 2024 -0400

    drm/bridge: dpc3433: Don't log an error when DSI host can't be found
    
    [ Upstream commit 24f4f575214de776539d346b99b8717bffa8ebba ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Also move the "failed to attach" error message so that it's only printed
    when the devm_mipi_dsi_attach() call fails.
    
    Fixes: 6352cd451ddb ("drm: bridge: Add TI DLPC3433 DSI to DMD bridge")
    Suggested-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-7-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: Fix improper bridge init order with pre_enable_prev_first [+ + +]
Author: Jagan Teki <[email protected]>
Date:   Tue Mar 28 22:37:51 2023 +0530

    drm/bridge: Fix improper bridge init order with pre_enable_prev_first
    
    [ Upstream commit e18aeeda0b6905c333df5a0566b99f5c84426098 ]
    
    For a given bridge pipeline if any bridge sets pre_enable_prev_first
    flag then the pre_enable for the previous bridge will be called before
    pre_enable of this bridge and opposite is done for post_disable.
    
    These are the potential bridge flags to alter bridge init order in order
    to satisfy the MIPI DSI host and downstream panel or bridge to function.
    However the existing pre_enable_prev_first logic with associated bridge
    ordering has broken for both pre_enable and post_disable calls.
    
    [pre_enable]
    
    The altered bridge ordering has failed if two consecutive bridges on a
    given pipeline enables the pre_enable_prev_first flag.
    
    Example:
    - Panel
    - Bridge 1
    - Bridge 2 pre_enable_prev_first
    - Bridge 3
    - Bridge 4 pre_enable_prev_first
    - Bridge 5 pre_enable_prev_first
    - Bridge 6
    - Encoder
    
    In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first.
    
    The logic looks for a bridge which enabled pre_enable_prev_first flag
    on each iteration and assigned the previou bridge to limit pointer
    if the bridge doesn't enable pre_enable_prev_first flags.
    
    If control found Bridge 2 is pre_enable_prev_first then the iteration
    looks for Bridge 3 and found it is not pre_enable_prev_first and assigns
    it's previous Bridge 4 to limit pointer and calls pre_enable of Bridge 3
    and Bridge 2 and assign iter pointer with limit which is Bridge 4.
    
    Here is the actual problem, for the next iteration control look for
    Bridge 5 instead of Bridge 4 has iter pointer in previous iteration
    moved to Bridge 4 so this iteration skips the Bridge 4. The iteration
    found Bridge 6 doesn't pre_enable_prev_first flags so the limit assigned
    to Encoder. From next iteration Encoder skips as it is the last bridge
    for reverse order pipeline.
    
    So, the resulting pre_enable bridge order would be,
    - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5.
    
    This patch fixes this by assigning limit to next pointer instead of
    previous bridge since the iteration always looks for bridge that does
    NOT request prev so assigning next makes sure the last bridge on a
    given iteration what exactly the limit bridge is.
    
    So, the resulting pre_enable bridge order with fix would be,
    - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4,
      Encoder.
    
    [post_disable]
    
    The altered bridge ordering has failed if two consecutive bridges on a
    given pipeline enables the pre_enable_prev_first flag.
    
    Example:
    - Panel
    - Bridge 1
    - Bridge 2 pre_enable_prev_first
    - Bridge 3
    - Bridge 4 pre_enable_prev_first
    - Bridge 5 pre_enable_prev_first
    - Bridge 6
    - Encoder
    
    In this example Bridge 5 and Bridge 4 have pre_enable_prev_first.
    
    The logic looks for a bridge which enabled pre_enable_prev_first flags
    on each iteration and assigned the previou bridge to next and next to
    limit pointer if the bridge does enable pre_enable_prev_first flag.
    
    If control starts from Bridge 6 then it found next Bridge 5 is
    pre_enable_prev_first and immediately the next assigned to previous
    Bridge 6 and limit assignments to next Bridge 6 and call post_enable
    of Bridge 6 even though the next consecutive Bridge 5 is enabled with
    pre_enable_prev_first. This clearly misses the logic to find the state
    of next conducive bridge as everytime the next and limit assigns
    previous bridge if given bridge enabled pre_enable_prev_first.
    
    So, the resulting post_disable bridge order would be,
    - Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1,
      Panel.
    
    This patch fixes this by assigning next with previou bridge only if the
    bridge doesn't enable pre_enable_prev_first flag and the next further
    assign it to limit. This way we can find the bridge that NOT requested
    prev to disable last.
    
    So, the resulting pre_enable bridge order with fix would be,
    - Encoder, Bridge 4, Bridge 5, Bridge 6, Bridge 2, Bridge 3, Bridge 1,
      Panel.
    
    Validated the bridge init ordering by incorporating dummy bridges in
    the sun6i-mipi-dsi pipeline
    
    Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order")
    Signed-off-by: Jagan Teki <[email protected]>
    Tested-by: Michael Trimarchi <[email protected]>
    Reviewed-by: Dave Stevenson <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: icn6211: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Mon Apr 15 17:49:30 2024 -0400

    drm/bridge: icn6211: Don't log an error when DSI host can't be found
    
    [ Upstream commit 275fafe58faa7fdb10fa245412696ecef676aac5 ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: 8dde6f7452a1 ("drm: bridge: icn6211: Add I2C configuration support")
    Suggested-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-2-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: lt8912b: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Mon Apr 15 17:49:31 2024 -0400

    drm/bridge: lt8912b: Don't log an error when DSI host can't be found
    
    [ Upstream commit b3b4695ff47c4964d4ccb930890c9ffd8e455e20 ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
    Suggested-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-3-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: lt9611: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Mon Apr 15 17:49:32 2024 -0400

    drm/bridge: lt9611: Don't log an error when DSI host can't be found
    
    [ Upstream commit cd0a2c6a081ff67007323725b9ff07d9934b1ed8 ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
    Suggested-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-4-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: lt9611uxc: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Mon Apr 15 17:49:33 2024 -0400

    drm/bridge: lt9611uxc: Don't log an error when DSI host can't be found
    
    [ Upstream commit 6d9e877cde7e9b516a9a99751b8222c87557436d ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
    Suggested-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-5-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: tc358775: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Mon Apr 15 17:49:34 2024 -0400

    drm/bridge: tc358775: Don't log an error when DSI host can't be found
    
    [ Upstream commit 272377aa0e3dddeec3f568c8bb9d12c7a79d8ef5 ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
    Suggested-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-6-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/ci: update device type for volteer devices [+ + +]
Author: Vignesh Raman <[email protected]>
Date:   Thu Mar 7 07:48:41 2024 +0530

    drm/ci: update device type for volteer devices
    
    [ Upstream commit a2c71b711e7efc6478976233768bdbc3386e6dce ]
    
    Volteer devices in the collabora lab are categorized under the
    asus-cx9400-volteer device type. The majority of these units
    has an Intel Core i5-1130G7 CPU, while some of them have a
    Intel Core i7-1160G7 CPU instead. So due to this difference,
    new device type template is added for the Intel Core i5-1130G7
    and i7-1160G7 variants of the Acer Chromebook Spin 514 (CP514-2H)
    volteer Chromebooks. So update the same in drm-ci.
    
    https://gitlab.collabora.com/lava/lava/-/merge_requests/149
    
    Fixes: 0119c894ab0d ("drm: Add initial ci/ subdirectory")
    Reviewed-by: David Heidelberg <[email protected]>
    Signed-off-by: Vignesh Raman <[email protected]>
    Acked-by: Helen Koike <[email protected]>
    Signed-off-by: Helen Koike <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/dp: Don't attempt AUX transfers when eDP panels are not powered [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Fri Feb 2 14:11:16 2024 -0800

    drm/dp: Don't attempt AUX transfers when eDP panels are not powered
    
    [ Upstream commit 8df1ddb5bf11ab820ad991e164dab82c0960add9 ]
    
    If an eDP panel is not powered on then any attempts to talk to it over
    the DP AUX channel will timeout. Unfortunately these attempts may be
    quite slow. Userspace can initiate these attempts either via a
    /dev/drm_dp_auxN device or via the created i2c device.
    
    Making the DP AUX drivers timeout faster is a difficult proposition.
    In theory we could just poll the panel's HPD line in the AUX transfer
    function and immediately return an error there. However, this is
    easier said than done. For one thing, there's no hard requirement to
    hook the HPD line up for eDP panels and it's OK to just delay a fixed
    amount. For another thing, the HPD line may not be fast to probe. On
    parade-ps8640 we need to wait for the bridge chip's firmware to boot
    before we can get the HPD line and this is a slow process.
    
    The fact that the transfers are taking so long to timeout is causing
    real problems. The open source fwupd daemon sometimes scans DP busses
    looking for devices whose firmware need updating. If it happens to
    scan while a panel is turned off this scan can take a long time. The
    fwupd daemon could try to be smarter and only scan when eDP panels are
    turned on, but we can also improve the behavior in the kernel.
    
    Let's let eDP panels drivers specify that a panel is turned off and
    then modify the common AUX transfer code not to attempt a transfer in
    this case.
    
    Tested-by: Steev Klimaszewski <[email protected]>
    Reviewed-by: Hsin-Yi Wang <[email protected]>
    Tested-by: Eizan Miyamoto <[email protected]>
    Acked-by: Neil Armstrong <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240202141109.1.I24277520ac754ea538c9b14578edc94e1df11b48@changeid
    Stable-dep-of: 5e842d55bad7 ("drm/panel: atna33xc20: Fix unbalanced regulator in the case HPD doesn't assert")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/edid: Parse topology block for all DispID structure v1.x [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Wed Apr 10 21:01:39 2024 +0300

    drm/edid: Parse topology block for all DispID structure v1.x
    
    [ Upstream commit e0a200ab4b72afd581bd6f82fc1ef510a4fb5478 ]
    
    DisplayID spec v1.3 revision history notes do claim that
    the toplogy block was added in v1.3 so requiring structure
    v1.2 would seem correct, but there is at least one EDID in
    edid.tv with a topology block and structure v1.0. And
    there are also EDIDs with DisplayID structure v1.3 which
    seems to be totally incorrect as DisplayID spec v1.3 lists
    structure v1.2 as the only legal value.
    
    Unfortunately I couldn't find copies of DisplayID spec
    v1.0-v1.2 anywhere (even on vesa.org), so I'll have to
    go on empirical evidence alone.
    
    We used to parse the topology block on all v1.x
    structures until the check for structure v2.0 was added.
    Let's go back to doing that as the evidence does suggest
    that there are DisplayIDs in the wild that would miss
    out on the topology stuff otherwise.
    
    Also toss out DISPLAY_ID_STRUCTURE_VER_12 entirely as
    it doesn't appear we can really use it for anything.
    
    I *think* we could technically skip all the structure
    version checks as the block tags shouldn't conflict
    between v2.0 and v1.x. But no harm in having a bit of
    extra sanity checks I guess.
    
    So far I'm not aware of any user reported regressions
    from overly strict check, but I do know that it broke
    igt/kms_tiled_display's fake DisplayID as that one
    gets generated with structure v1.0.
    
    Cc: Jani Nikula <[email protected]>
    Cc: Dmitry Osipenko <[email protected]>
    Fixes: c5a486af9df7 ("drm/edid: parse Tiled Display Topology Data Block for DisplayID 2.0")
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Acked-by: Jani Nikula <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/etnaviv: fix tx clock gating on some GC7000 variants [+ + +]
Author: Derek Foreman <[email protected]>
Date:   Mon Mar 18 07:32:07 2024 -0500

    drm/etnaviv: fix tx clock gating on some GC7000 variants
    
    [ Upstream commit d7a5c9de99b3a9a43dce49f2084eb69b5f6a9752 ]
    
    commit 4bce244272513 ("drm/etnaviv: disable tx clock gating for GC7000
    rev6203") accidentally applied the fix for i.MX8MN errata ERR050226 to
    GC2000 instead of GC7000, failing to disable tx clock gating for GC7000
    rev 0x6023 as intended.
    
    Additional clean-up further propagated this issue, partially breaking
    the clock gating fixes added for GC7000 rev 6202 in commit 432f51e7deeda
    ("drm/etnaviv: add clock gating workaround for GC7000 r6202").
    
    Signed-off-by: Derek Foreman <[email protected]>
    Signed-off-by: Lucas Stach <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/imagination: avoid -Woverflow warning [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Mar 22 14:01:09 2024 +0100

    drm/imagination: avoid -Woverflow warning
    
    [ Upstream commit 07b9d0144fff9af08b8dcd0ae134510bfd539e42 ]
    
    The array size calculation in pvr_vm_mips_fini() appears to be incorrect based on
    taking the size of the pointer rather than the size of the array, which manifests
    as a warning about signed integer overflow:
    
    In file included from include/linux/kernel.h:16,
                     from drivers/gpu/drm/imagination/pvr_rogue_fwif.h:10,
                     from drivers/gpu/drm/imagination/pvr_ccb.h:7,
                     from drivers/gpu/drm/imagination/pvr_device.h:7,
                     from drivers/gpu/drm/imagination/pvr_vm_mips.c:4:
    drivers/gpu/drm/imagination/pvr_vm_mips.c: In function 'pvr_vm_mips_fini':
    include/linux/array_size.h:11:25: error: overflow in conversion from 'long unsigned int' to 'int' changes value from '18446744073709551615' to '-1' [-Werror=overflow]
       11 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
          |                         ^
    drivers/gpu/drm/imagination/pvr_vm_mips.c:106:24: note: in expansion of macro 'ARRAY_SIZE'
      106 |         for (page_nr = ARRAY_SIZE(mips_data->pt_pages) - 1; page_nr >= 0; page_nr--) {
          |                        ^~~~~~~~~~
    
    Just use the number of array elements directly here, and in the corresponding
    init function for consistency.
    
    Fixes: 927f3e0253c1 ("drm/imagination: Implement MIPS firmware processor and MMU support")
    Reviewed-by: Donald Robson <[email protected]>
    Link: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Matt Coster <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/lcdif: Do not disable clocks on already suspended hardware [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Mon Feb 26 09:26:27 2024 +0100

    drm/lcdif: Do not disable clocks on already suspended hardware
    
    [ Upstream commit 172695f145fb4798ab605e8a73f6e87711930124 ]
    
    In case the LCDIF is enabled in DT but unused, the clocks used by the
    LCDIF are not enabled. Those clocks may even have a use count of 0 in
    case there are no other users of those clocks. This can happen e.g. in
    case the LCDIF drives HDMI bridge which has no panel plugged into the
    HDMI connector.
    
    Do not attempt to disable clocks in the suspend callback and re-enable
    clocks in the resume callback unless the LCDIF is enabled and was in
    use before the system entered suspend, otherwise the driver might end
    up trying to disable clocks which are already disabled with use count
    0, and would trigger a warning from clock core about this condition.
    
    Note that the lcdif_rpm_suspend() and lcdif_rpm_resume() functions
    internally perform the clocks disable and enable operations and act
    as runtime PM hooks too.
    
    Reviewed-by: Liu Ying <[email protected]>
    Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
    Signed-off-by: Marek Vasut <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/mediatek: Add 0 size check to mtk_drm_gem_obj [+ + +]
Author: Justin Green <[email protected]>
Date:   Thu Mar 7 13:00:51 2024 -0500

    drm/mediatek: Add 0 size check to mtk_drm_gem_obj
    
    [ Upstream commit 1e4350095e8ab2577ee05f8c3b044e661b5af9a0 ]
    
    Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
    of 0 bytes. Currently, no such check exists and the kernel will panic if
    a userspace application attempts to allocate a 0x0 GBM buffer.
    
    Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
    verifying that we now return EINVAL.
    
    Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
    Signed-off-by: Justin Green <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: CK Hu <[email protected]>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/
    Signed-off-by: Chun-Kuang Hu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/mediatek: Init `ddp_comp` with devm_kcalloc() [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Thu Mar 28 09:22:49 2024 -0700

    drm/mediatek: Init `ddp_comp` with devm_kcalloc()
    
    [ Upstream commit 01a2c5123e27b3c4685bf2fc4c2e879f6e0c7b33 ]
    
    In the case where `conn_routes` is true we allocate an extra slot in
    the `ddp_comp` array but mtk_drm_crtc_create() never seemed to
    initialize it in the test case I ran. For me, this caused a later
    crash when we looped through the array in mtk_drm_crtc_mode_valid().
    This showed up for me when I booted with `slub_debug=FZPUA` which
    poisons the memory initially. Without `slub_debug` I couldn't
    reproduce, presumably because the later code handles the value being
    NULL and in most cases (not guaranteed in all cases) the memory the
    allocator returned started out as 0.
    
    It really doesn't hurt to initialize the array with devm_kcalloc()
    since the array is small and the overhead of initting a handful of
    elements to 0 is small. In general initting memory to zero is a safer
    practice and usually it's suggested to only use the non-initting alloc
    functions if you really need to.
    
    Let's switch the function to use an allocation function that zeros the
    memory. For me, this avoids the crash.
    
    Fixes: 01389b324c97 ("drm/mediatek: Add connector dynamic selection capability")
    Signed-off-by: Douglas Anderson <[email protected]>
    Reviewed-by: CK Hu <[email protected]>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/20240328092248.1.I2e73c38c0f264ee2fa4a09cdd83994e37ba9f541@changeid/
    Signed-off-by: Chun-Kuang Hu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/meson: vclk: fix calculation of 59.94 fractional rates [+ + +]
Author: Christian Hewitt <[email protected]>
Date:   Tue Jan 9 23:07:04 2024 +0000

    drm/meson: vclk: fix calculation of 59.94 fractional rates
    
    [ Upstream commit bfbc68e4d8695497f858a45a142665e22a512ea3 ]
    
    Playing 4K media with 59.94 fractional rate (typically VP9) causes the screen to lose
    sync with the following error reported in the system log:
    
    [   89.610280] Fatal Error, invalid HDMI vclk freq 593406
    
    Modetest shows the following:
    
    3840x2160 59.94 3840 4016 4104 4400 2160 2168 2178 2250 593407 flags: xxxx, xxxx,
    drm calculated value -------------------------------------^
    
    Change the fractional rate calculation to stop DIV_ROUND_CLOSEST rounding down which
    results in vclk freq failing to match correctly.
    
    Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup")
    Signed-off-by: Christian Hewitt <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/mipi-dsi: use correct return type for the DSC functions [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Mon Apr 8 02:53:51 2024 +0300

    drm/mipi-dsi: use correct return type for the DSC functions
    
    [ Upstream commit de1c705c50326acaceaf1f02bc5bf6f267c572bd ]
    
    The functions mipi_dsi_compression_mode() and
    mipi_dsi_picture_parameter_set() return 0-or-error rather than a buffer
    size. Follow example of other similar MIPI DSI functions and use int
    return type instead of size_t.
    
    Fixes: f4dea1aaa9a1 ("drm/dsi: add helpers for DSI compression mode and PPS packets")
    Reviewed-by: Marijn Suijten <[email protected]>
    Reviewed-by: Jessica Zhang <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/dp: allow voltage swing / pre emphasis of 3 [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Sat Feb 3 15:47:25 2024 +0200

    drm/msm/dp: allow voltage swing / pre emphasis of 3
    
    [ Upstream commit 22578178e5dd6d3aa4490879df8b6c2977d980be ]
    
    Both dp_link_adjust_levels() and dp_ctrl_update_vx_px() limit swing and
    pre-emphasis to 2, while the real maximum value for the sum of the
    voltage swing and pre-emphasis is 3. Fix the DP code to remove this
    limitation.
    
    Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Kuogee Hsieh <[email protected]>
    Tested-by: Kuogee Hsieh <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/577006/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/dp: Avoid a long timeout for AUX transfer if nothing connected [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Fri Mar 15 14:36:29 2024 -0700

    drm/msm/dp: Avoid a long timeout for AUX transfer if nothing connected
    
    [ Upstream commit 5d1a7493343cc00d9019880b686e4e0a0f649531 ]
    
    As documented in the description of the transfer() function of
    "struct drm_dp_aux", the transfer() function can be called at any time
    regardless of the state of the DP port. Specifically if the kernel has
    the DP AUX character device enabled and userspace accesses
    "/dev/drm_dp_auxN" directly then the AUX transfer function will be
    called regardless of whether a DP device is connected.
    
    For eDP panels we have a special rule where we wait (with a 5 second
    timeout) for HPD to go high. This rule was important before all panels
    drivers were converted to call wait_hpd_asserted() and actually can be
    removed in a future commit.
    
    For external DP devices we never checked for HPD. That means that
    trying to access the DP AUX character device (AKA `hexdump -C
    /dev/drm_dp_auxN`) would very, very slowly timeout. Specifically on my
    system:
      $ time hexdump -C /dev/drm_dp_aux0
      hexdump: /dev/drm_dp_aux0: Connection timed out
      real    0m8.200s
    We want access to the drm_dp_auxN character device to fail faster than
    8 seconds when no DP cable is plugged in.
    
    Let's add a test to make transfers fail right away if a device isn't
    plugged in. Rather than testing the HPD line directly, we have the
    dp_display module tell us when AUX transfers should be enabled so we
    can handle cases where HPD is signaled out of band like with Type C.
    
    Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
    Signed-off-by: Douglas Anderson <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/583127/
    Link: https://lore.kernel.org/r/20240315143621.v2.1.I16aff881c9fe82b5e0fc06ca312da017aa7b5b3e@changeid
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/nouveau/dp: Fix incorrect return code in r535_dp_aux_xfer() [+ + +]
Author: Lyude Paul <[email protected]>
Date:   Fri Mar 15 17:20:56 2024 -0400

    drm/nouveau/dp: Fix incorrect return code in r535_dp_aux_xfer()
    
    [ Upstream commit 97252d0a4bfbb07079503d059f7522d305fe0f7a ]
    
    I've recently been seeing some unexplained GSP errors on my RTX 6000 from
    failed aux transactions:
    
      [  132.915867] nouveau 0000:1f:00.0: gsp: cli:0xc1d00002 obj:0x00730000
      ctrl cmd:0x00731341 failed: 0x0000ffff
    
    While the cause of these is not yet clear, these messages made me notice
    that the aux transactions causing these transactions were succeeding - not
    failing. As it turns out, this is because we're currently not returning the
    correct variable when r535_dp_aux_xfer() hits an error - causing us to
    never propagate GSP errors for failed aux transactions to userspace.
    
    So, let's fix that.
    
    Fixes: 4ae3a20102b2 ("nouveau/gsp: don't free ctrl messages on errors")
    Signed-off-by: Lyude Paul <[email protected]>
    Reviewed-by: Dave Airlie <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/omapdrm: Fix console by implementing fb_dirty [+ + +]
Author: Tony Lindgren <[email protected]>
Date:   Wed Feb 28 08:35:31 2024 +0200

    drm/omapdrm: Fix console by implementing fb_dirty
    
    [ Upstream commit 632bac50544c0929ced9eed41e7d04c08adecbb0 ]
    
    The framebuffer console stopped updating with commit f231af498c29
    ("drm/fb-helper: Disconnect damage worker from update logic").
    
    Let's fix the issue by implementing fb_dirty similar to what was done
    with commit 039a72ce7e57 ("drm/i915/fbdev: Implement fb_dirty for intel
    custom fb helper").
    
    Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update logic")
    Reviewed-by: Thomas Zimmermann <[email protected]>
    Signed-off-by: Tony Lindgren <[email protected]>
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/omapdrm: Fix console with deferred ops [+ + +]
Author: Tony Lindgren <[email protected]>
Date:   Wed Feb 28 08:35:32 2024 +0200

    drm/omapdrm: Fix console with deferred ops
    
    [ Upstream commit 01c0cce88c5480cc2505b79330246ef12eda938f ]
    
    Commit 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
    stopped console from updating for command mode displays because there is
    no damage handling in fb_sys_write() unlike we had earlier in
    drm_fb_helper_sys_write().
    
    Let's fix the issue by adding FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS and
    FB_DMAMEM_HELPERS_DEFERRED as suggested by Thomas. We cannot use the
    FB_DEFAULT_DEFERRED_OPS as fb_deferred_io_mmap() won't work properly
    for write-combine.
    
    Fixes: 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
    Suggested-by: Thomas Zimmermann <[email protected]>
    Reviewed-by: Thomas Zimmermann <[email protected]>
    Signed-off-by: Tony Lindgren <[email protected]>
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/panel: atna33xc20: Fix unbalanced regulator in the case HPD doesn't assert [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Wed Mar 13 14:12:14 2024 -0700

    drm/panel: atna33xc20: Fix unbalanced regulator in the case HPD doesn't assert
    
    [ Upstream commit 5e842d55bad7794823a50f24fd645b58f2ef93ab ]
    
    When the atna33xc20 driver was first written the resume code never
    returned an error. If there was a problem waiting for HPD it just
    printed a warning and moved on. This changed in response to review
    feedback [1] on a future patch but I accidentally didn't account for
    rolling back the regulator enable in the error cases. Do so now.
    
    [1] https://lore.kernel.org/all/[email protected]/
    
    Fixes: 3b5765df375c ("drm/panel: atna33xc20: Take advantage of wait_hpd_asserted() in struct drm_dp_aux")
    Acked-by: Jessica Zhang <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/panel: ltk050h3146w: add MIPI_DSI_MODE_VIDEO to LTK050H3148W flags [+ + +]
Author: Heiko Stuebner <[email protected]>
Date:   Wed Mar 20 14:12:31 2024 +0100

    drm/panel: ltk050h3146w: add MIPI_DSI_MODE_VIDEO to LTK050H3148W flags
    
    [ Upstream commit 80cc8c0d09e6bab3bd016ddaccd0570cadbe1891 ]
    
    Similar to other variants, the LTK050H3148W wants to run in video mode
    when displaying data. So far only the Synopsis DSI driver was using this
    panel and it is always switching to video mode, independent of this flag
    being set.
    
    Other DSI drivers might handle this differently, so add the flag.
    
    Fixes: e5f9d543419c ("drm/panel: ltk050h3146w: add support for Leadtek LTK050H3148W-CTA6 variant")
    Signed-off-by: Heiko Stuebner <[email protected]>
    Reviewed-by: Quentin Schulz <[email protected]>
    Acked-by: Jessica Zhang <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/panel: ltk050h3146w: drop duplicate commands from LTK050H3148W init [+ + +]
Author: Heiko Stuebner <[email protected]>
Date:   Wed Mar 20 14:12:32 2024 +0100

    drm/panel: ltk050h3146w: drop duplicate commands from LTK050H3148W init
    
    [ Upstream commit 55679cc22e60e8ec23b2340248389022798416cd ]
    
    The init sequence specifies the 0x11 and 0x29 dsi commands, which are
    the exit-sleep and display-on commands.
    
    In the actual prepare step the driver already uses the appropriate
    function calls for those, so drop the duplicates.
    
    Fixes: e5f9d543419c ("drm/panel: ltk050h3146w: add support for Leadtek LTK050H3148W-CTA6 variant")
    Signed-off-by: Heiko Stuebner <[email protected]>
    Reviewed-by: Quentin Schulz <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/panel: novatek-nt35950: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
Date:   Mon Apr 15 17:49:36 2024 -0400

    drm/panel: novatek-nt35950: Don't log an error when DSI host can't be found
    
    [ Upstream commit 5ff5505b9a2d827cae3f95dceba258c963138175 ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: 623a3531e9cf ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC panels")
    Suggested-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-8-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <[email protected]>

drm/panel: simple: Add missing Innolux G121X1-L03 format, flags, connector [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Thu Mar 28 11:27:36 2024 +0100

    drm/panel: simple: Add missing Innolux G121X1-L03 format, flags, connector
    
    [ Upstream commit 11ac72d033b9f577e8ba0c7a41d1c312bb232593 ]
    
    The .bpc = 6 implies .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG ,
    add the missing bus_format. Add missing connector type and bus_flags
    as well.
    
    Documentation [1] 1.4 GENERAL SPECIFICATI0NS indicates this panel is
    capable of both RGB 18bit/24bit panel, the current configuration uses
    18bit mode, .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG , .bpc = 6.
    
    Support for the 24bit mode would require another entry in panel-simple
    with .bus_format = MEDIA_BUS_FMT_RGB666_1X7X4_SPWG and .bpc = 8, which
    is out of scope of this fix.
    
    [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf
    
    Fixes: f8fa17ba812b ("drm/panel: simple: Add support for Innolux G121X1-L03")
    Signed-off-by: Marek Vasut <[email protected]>
    Acked-by: Jessica Zhang <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/rockchip: vop2: Do not divide height twice for YUV [+ + +]
Author: Detlev Casanova <[email protected]>
Date:   Sun Apr 14 14:27:06 2024 -0400

    drm/rockchip: vop2: Do not divide height twice for YUV
    
    [ Upstream commit e80c219f52861e756181d7f88b0d341116daac2b ]
    
    For the cbcr format, gt2 and gt4 are computed again after src_h has been
    divided by vsub.
    
    As src_h as already been divided by 2 before, introduce cbcr_src_h and
    cbcr_src_w to keep a copy of those values to be used for cbcr gt2 and
    gt4 computation.
    
    This fixes yuv planes being unaligned vertically when down scaling to
    1080 pixels from 2160.
    
    Signed-off-by: Detlev Casanova <[email protected]>
    Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
    Acked-by: Andy Yan <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Mon Apr 8 15:58:10 2024 +0300

    drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
    
    [ Upstream commit 935a92a1c400285545198ca2800a4c6c519c650a ]
    
    In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is
    assigned to mhdp_state->current_mode, and there is a dereference of it in
    drm_mode_set_name(), which will lead to a NULL pointer dereference on
    failure of drm_mode_duplicate().
    
    Fix this bug add a check of mhdp_state->current_mode.
    
    Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge")
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Reviewed-by: Robert Foss <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm: vc4: Fix possible null pointer dereference [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Tue Apr 9 10:56:22 2024 +0300

    drm: vc4: Fix possible null pointer dereference
    
    [ Upstream commit c534b63bede6cb987c2946ed4d0b0013a52c5ba7 ]
    
    In vc4_hdmi_audio_init() of_get_address() may return
    NULL which is later dereferenced. Fix this bug by adding NULL check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support")
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Signed-off-by: Maxime Ripard <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
dt-bindings: rockchip: grf: Add missing type to 'pcie-phy' node [+ + +]
Author: Rob Herring <[email protected]>
Date:   Mon Apr 1 15:49:58 2024 -0500

    dt-bindings: rockchip: grf: Add missing type to 'pcie-phy' node
    
    [ Upstream commit d41201c90f825f19a46afbfb502f22f612d8ccc4 ]
    
    'pcie-phy' is missing any type. Add 'type: object' to indicate it's a
    node.
    
    Signed-off-by: Rob Herring <[email protected]>
    Reviewed-by: Heiko Stuebner <[email protected]>
    Acked-by: Conor Dooley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dt-bindings: thermal: loongson,ls2k-thermal: Add Loongson-2K0500 compatible [+ + +]
Author: Binbin Zhou <[email protected]>
Date:   Tue Apr 23 09:59:01 2024 +0800

    dt-bindings: thermal: loongson,ls2k-thermal: Add Loongson-2K0500 compatible
    
    [ Upstream commit 25c7d8472f6e90390931e93f59135478af3e5d86 ]
    
    The thermal on the Loongson-2K0500 shares the design with the
    Loongson-2K1000. Define corresponding compatible string, having the
    loongson,ls2k1000-thermal as a fallback.
    
    Signed-off-by: Binbin Zhou <[email protected]>
    Acked-by: Rob Herring <[email protected]>
    Acked-by: Huacai Chen <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/26524a63abd2d032e4c45efe6ce3fedb46841768.1713837379.git.zhoubinbin@loongson.cn
    Stable-dep-of: c8c435368577 ("dt-bindings: thermal: loongson,ls2k-thermal: Fix incorrect compatible definition")
    Signed-off-by: Sasha Levin <[email protected]>

dt-bindings: thermal: loongson,ls2k-thermal: Fix incorrect compatible definition [+ + +]
Author: Binbin Zhou <[email protected]>
Date:   Tue Apr 23 09:59:02 2024 +0800

    dt-bindings: thermal: loongson,ls2k-thermal: Fix incorrect compatible definition
    
    [ Upstream commit c8c4353685778e75e186103411e9d01a4a3f2b90 ]
    
    The temperature output register of the Loongson-2K2000 is defined in the
    chip configuration domain, which is different from the Loongson-2K1000,
    so it can't be fallbacked.
    
    We need to use two groups of registers to describe it: the first group
    is the high and low temperature threshold setting register; the second
    group is the temperature output register.
    
    It is true that this fix will cause ABI corruption, but it is necessary
    otherwise the Loongson-2K2000 temperature sensor will not work properly.
    
    Fixes: 72684d99a854 ("thermal: dt-bindings: add loongson-2 thermal")
    Cc: Yinbo Zhu <[email protected]>
    Signed-off-by: Binbin Zhou <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Huacai Chen <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/5198999d679f1a1c3457385acb9fadfc85da1f1e.1713837379.git.zhoubinbin@loongson.cn
    Signed-off-by: Sasha Levin <[email protected]>

 
ecryptfs: Fix buffer size for tag 66 packet [+ + +]
Author: Brian Kubisiak <[email protected]>
Date:   Sun Mar 17 07:46:00 2024 -0700

    ecryptfs: Fix buffer size for tag 66 packet
    
    [ Upstream commit 85a6a1aff08ec9f5b929d345d066e2830e8818e5 ]
    
    The 'TAG 66 Packet Format' description is missing the cipher code and
    checksum fields that are packed into the message packet. As a result,
    the buffer allocated for the packet is 3 bytes too small and
    write_tag_66_packet() will write up to 3 bytes past the end of the
    buffer.
    
    Fix this by increasing the size of the allocation so the whole packet
    will always fit in the buffer.
    
    This fixes the below kasan slab-out-of-bounds bug:
    
      BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0
      Write of size 1 at addr ffff88800afbb2a5 by task touch/181
    
      CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x4c/0x70
       print_report+0xc5/0x610
       ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
       ? kasan_complete_mode_report_info+0x44/0x210
       ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
       kasan_report+0xc2/0x110
       ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
       __asan_store1+0x62/0x80
       ecryptfs_generate_key_packet_set+0x7d6/0xde0
       ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10
       ? __alloc_pages+0x2e2/0x540
       ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]
       ? dentry_open+0x8f/0xd0
       ecryptfs_write_metadata+0x30a/0x550
       ? __pfx_ecryptfs_write_metadata+0x10/0x10
       ? ecryptfs_get_lower_file+0x6b/0x190
       ecryptfs_initialize_file+0x77/0x150
       ecryptfs_create+0x1c2/0x2f0
       path_openat+0x17cf/0x1ba0
       ? __pfx_path_openat+0x10/0x10
       do_filp_open+0x15e/0x290
       ? __pfx_do_filp_open+0x10/0x10
       ? __kasan_check_write+0x18/0x30
       ? _raw_spin_lock+0x86/0xf0
       ? __pfx__raw_spin_lock+0x10/0x10
       ? __kasan_check_write+0x18/0x30
       ? alloc_fd+0xf4/0x330
       do_sys_openat2+0x122/0x160
       ? __pfx_do_sys_openat2+0x10/0x10
       __x64_sys_openat+0xef/0x170
       ? __pfx___x64_sys_openat+0x10/0x10
       do_syscall_64+0x60/0xd0
       entry_SYSCALL_64_after_hwframe+0x6e/0xd8
      RIP: 0033:0x7f00a703fd67
      Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f
      RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
      RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67
      RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c
      RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000
      R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941
      R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040
       </TASK>
    
      Allocated by task 181:
       kasan_save_stack+0x2f/0x60
       kasan_set_track+0x29/0x40
       kasan_save_alloc_info+0x25/0x40
       __kasan_kmalloc+0xc5/0xd0
       __kmalloc+0x66/0x160
       ecryptfs_generate_key_packet_set+0x6d2/0xde0
       ecryptfs_write_metadata+0x30a/0x550
       ecryptfs_initialize_file+0x77/0x150
       ecryptfs_create+0x1c2/0x2f0
       path_openat+0x17cf/0x1ba0
       do_filp_open+0x15e/0x290
       do_sys_openat2+0x122/0x160
       __x64_sys_openat+0xef/0x170
       do_syscall_64+0x60/0xd0
       entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    
    Fixes: dddfa461fc89 ("[PATCH] eCryptfs: Public key; packet management")
    Signed-off-by: Brian Kubisiak <[email protected]>
    Link: https://lore.kernel.org/r/5j2q56p6qkhezva6b2yuqfrsurmvrrqtxxzrnp3wqu7xrz22i7@hoecdztoplbl
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
EDAC/skx_common: Allow decoding of SGX addresses [+ + +]
Author: Qiuxu Zhuo <[email protected]>
Date:   Mon Apr 8 20:04:19 2024 +0800

    EDAC/skx_common: Allow decoding of SGX addresses
    
    [ Upstream commit e0d335077831196bffe6a634ffe385fc684192ca ]
    
    There are no "struct page" associations with SGX pages, causing the check
    pfn_to_online_page() to fail. This results in the inability to decode the
    SGX addresses and warning messages like:
    
      Invalid address 0x34cc9a98840 in IA32_MC17_ADDR
    
    Add an additional check to allow the decoding of the error address and to
    skip the warning message, if the error address is an SGX address.
    
    Fixes: 1e92af09fab1 ("EDAC/skx_common: Filter out the invalid address")
    Signed-off-by: Qiuxu Zhuo <[email protected]>
    Signed-off-by: Tony Luck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
EDAC/versal: Do not register for NOC errors [+ + +]
Author: Shubhrajyoti Datta <[email protected]>
Date:   Thu Apr 25 17:49:40 2024 +0530

    EDAC/versal: Do not register for NOC errors
    
    [ Upstream commit edbe59428eb0da09958769326a6566d4c9242ae7 ]
    
    The NOC errors are not handled in the driver. Remove the request for
    registration.
    
    Signed-off-by: Shubhrajyoti Datta <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
enetc: avoid truncating error message [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Mar 26 23:38:01 2024 +0100

    enetc: avoid truncating error message
    
    [ Upstream commit 9046d581ed586f3c715357638ca12c0e84402002 ]
    
    As clang points out, the error message in enetc_setup_xdp_prog()
    still does not fit in the buffer and will be truncated:
    
    drivers/net/ethernet/freescale/enetc/enetc.c:2771:3: error: 'snprintf' will always be truncated; specified size is 80, but format string expands to at least 87 [-Werror,-Wformat-truncation]
    
    Replace it with an even shorter message that should fit.
    
    Fixes: f968c56417f0 ("net: enetc: shorten enetc_setup_xdp_prog() error message to fit NETLINK_MAX_FMTMSG_LEN")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
epoll: be better about file lifetimes [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Fri May 3 13:36:09 2024 -0700

    epoll: be better about file lifetimes
    
    [ Upstream commit 4efaa5acf0a1d2b5947f98abb3acf8bfd966422b ]
    
    epoll can call out to vfs_poll() with a file pointer that may race with
    the last 'fput()'. That would make f_count go down to zero, and while
    the ep->mtx locking means that the resulting file pointer tear-down will
    be blocked until the poll returns, it means that f_count is already
    dead, and any use of it won't actually get a reference to the file any
    more: it's dead regardless.
    
    Make sure we have a valid ref on the file pointer before we call down to
    vfs_poll() from the epoll routines.
    
    Link: https://lore.kernel.org/lkml/[email protected]/
    Reported-by: [email protected]
    Reviewed-by: Jens Axboe <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
eth: sungem: remove .ndo_poll_controller to avoid deadlocks [+ + +]
Author: Jakub Kicinski <[email protected]>
Date:   Wed May 8 06:45:04 2024 -0700

    eth: sungem: remove .ndo_poll_controller to avoid deadlocks
    
    [ Upstream commit ac0a230f719b02432d8c7eba7615ebd691da86f4 ]
    
    Erhard reports netpoll warnings from sungem:
    
      netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)
      WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
    
    gem_poll_controller() disables interrupts, which may sleep.
    We can't sleep in netpoll, it has interrupts disabled completely.
    Strangely, gem_poll_controller() doesn't even poll the completions,
    and instead acts as if an interrupt has fired so it just schedules
    NAPI and exits. None of this has been necessary for years, since
    netpoll invokes NAPI directly.
    
    Fixes: fe09bb619096 ("sungem: Spring cleaning and GRO support")
    Reported-and-tested-by: Erhard Furtner <[email protected]>
    Link: https://lore.kernel.org/all/20240428125306.2c3080ef@legion
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ext4: avoid excessive credit estimate in ext4_tmpfile() [+ + +]
Author: Jan Kara <[email protected]>
Date:   Thu Mar 7 12:53:20 2024 +0100

    ext4: avoid excessive credit estimate in ext4_tmpfile()
    
    [ Upstream commit 35a1f12f0ca857fee1d7a04ef52cbd5f1f84de13 ]
    
    A user with minimum journal size (1024 blocks these days) complained
    about the following error triggered by generic/697 test in
    ext4_tmpfile():
    
    run fstests generic/697 at 2024-02-28 05:34:46
    JBD2: vfstest wants too many credits credits:260 rsv_credits:0 max:256
    EXT4-fs error (device loop0) in __ext4_new_inode:1083: error 28
    
    Indeed the credit estimate in ext4_tmpfile() is huge.
    EXT4_MAXQUOTAS_INIT_BLOCKS() is 219, then 10 credits from ext4_tmpfile()
    itself and then ext4_xattr_credits_for_new_inode() adds more credits
    needed for security attributes and ACLs. Now the
    EXT4_MAXQUOTAS_INIT_BLOCKS() is in fact unnecessary because we've
    already initialized quotas with dquot_init() shortly before and so
    EXT4_MAXQUOTAS_TRANS_BLOCKS() is enough (which boils down to 3 credits).
    
    Fixes: af51a2ac36d1 ("ext4: ->tmpfile() support")
    Signed-off-by: Jan Kara <[email protected]>
    Tested-by: Luis Henriques <[email protected]>
    Tested-by: Disha Goel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: fix potential unnitialized variable [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Wed Apr 17 21:10:40 2024 +0300

    ext4: fix potential unnitialized variable
    
    [ Upstream commit 3f4830abd236d0428e50451e1ecb62e14c365e9b ]
    
    Smatch complains "err" can be uninitialized in the caller.
    
        fs/ext4/indirect.c:349 ext4_alloc_branch()
        error: uninitialized symbol 'err'.
    
    Set the error to zero on the success path.
    
    Fixes: 8016e29f4362 ("ext4: fast commit recovery path")
    Signed-off-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: remove the redundant folio_wait_stable() [+ + +]
Author: Zhang Yi <[email protected]>
Date:   Fri Apr 19 10:30:05 2024 +0800

    ext4: remove the redundant folio_wait_stable()
    
    [ Upstream commit df0b5afc62f3368d657a8fe4a8d393ac481474c2 ]
    
    __filemap_get_folio() with FGP_WRITEBEGIN parameter has already wait
    for stable folio, so remove the redundant folio_wait_stable() in
    ext4_da_write_begin(), it was left over from the commit cc883236b792
    ("ext4: drop unnecessary journal handle in delalloc write") that
    removed the retry getting page logic.
    
    Fixes: cc883236b792 ("ext4: drop unnecessary journal handle in delalloc write")
    Signed-off-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fbdev: sh7760fb: allow modular build [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Fri Feb 9 21:39:38 2024 -0800

    fbdev: sh7760fb: allow modular build
    
    [ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]
    
    There is no reason to prohibit sh7760fb from being built as a
    loadable module as suggested by Geert, so change the config symbol
    from bool to tristate to allow that and change the FB dependency as
    needed.
    
    Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
    Suggested-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>
    Cc: Thomas Zimmermann <[email protected]>
    Cc: Javier Martinez Canillas <[email protected]>
    Cc: John Paul Adrian Glaubitz <[email protected]>
    Cc: Sam Ravnborg <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Acked-by: John Paul Adrian Glaubitz <[email protected]>
    Acked-by: Javier Martinez Canillas <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fbdev: shmobile: fix snprintf truncation [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Mar 26 23:38:00 2024 +0100

    fbdev: shmobile: fix snprintf truncation
    
    [ Upstream commit 26c8cfb9d1e4b252336d23dd5127a8cbed414a32 ]
    
    The name of the overlay does not fit into the fixed-length field:
    
    drivers/video/fbdev/sh_mobile_lcdcfb.c:1577:2: error: 'snprintf' will always be truncated; specified size is 16, but format string expands to at least 25
    
    Make it short enough by changing the string.
    
    Fixes: c5deac3c9b22 ("fbdev: sh_mobile_lcdc: Implement overlays support")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fbdev: sisfb: hide unused variables [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Apr 3 10:06:31 2024 +0200

    fbdev: sisfb: hide unused variables
    
    [ Upstream commit 688cf598665851b9e8cb5083ff1d208ce43d10ff ]
    
    Building with W=1 shows that a couple of variables in this driver are only
    used in certain configurations:
    
    drivers/video/fbdev/sis/init301.c:239:28: error: 'SiS_Part2CLVX_6' defined but not used [-Werror=unused-const-variable=]
      239 | static const unsigned char SiS_Part2CLVX_6[] = {   /* 1080i */
          |                            ^~~~~~~~~~~~~~~
    drivers/video/fbdev/sis/init301.c:230:28: error: 'SiS_Part2CLVX_5' defined but not used [-Werror=unused-const-variable=]
      230 | static const unsigned char SiS_Part2CLVX_5[] = {   /* 750p */
          |                            ^~~~~~~~~~~~~~~
    drivers/video/fbdev/sis/init301.c:211:28: error: 'SiS_Part2CLVX_4' defined but not used [-Werror=unused-const-variable=]
      211 | static const unsigned char SiS_Part2CLVX_4[] = {   /* PAL */
          |                            ^~~~~~~~~~~~~~~
    drivers/video/fbdev/sis/init301.c:192:28: error: 'SiS_Part2CLVX_3' defined but not used [-Werror=unused-const-variable=]
      192 | static const unsigned char SiS_Part2CLVX_3[] = {  /* NTSC, 525i, 525p */
          |                            ^~~~~~~~~~~~~~~
    drivers/video/fbdev/sis/init301.c:184:28: error: 'SiS_Part2CLVX_2' defined but not used [-Werror=unused-const-variable=]
      184 | static const unsigned char SiS_Part2CLVX_2[] = {
          |                            ^~~~~~~~~~~~~~~
    drivers/video/fbdev/sis/init301.c:176:28: error: 'SiS_Part2CLVX_1' defined but not used [-Werror=unused-const-variable=]
      176 | static const unsigned char SiS_Part2CLVX_1[] = {
          |                            ^~~~~~~~~~~~~~~
    
    This started showing up after the definitions were moved into the
    source file from the header, which was not flagged by the compiler.
    Move the definition into the appropriate #ifdef block that already
    exists next to them.
    
    Fixes: 5908986ef348 ("video: fbdev: sis: avoid mismatched prototypes")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
firmware: qcom: qcm: fix unused qcom_scm_qseecom_allowlist [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Nov 20 19:56:23 2023 +0100

    firmware: qcom: qcm: fix unused qcom_scm_qseecom_allowlist
    
    [ Upstream commit e478c5fb6aa10af7b7edbff69bc8aef6fbb5f0ed ]
    
    For !OF builds, the qcom_scm_qseecom_allowlist is unused:
    
      drivers/firmware/qcom/qcom_scm.c:1652:34: error: ‘qcom_scm_qseecom_allowlist’ defined but not used [-Werror=unused-const-variable=]
    
    Fixes: 00b1248606ba ("firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Maximilian Luz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

firmware: qcom: scm: Fix __scm and waitq completion variable initialization [+ + +]
Author: Mukesh Ojha <[email protected]>
Date:   Thu Mar 21 20:54:02 2024 +0530

    firmware: qcom: scm: Fix __scm and waitq completion variable initialization
    
    [ Upstream commit 2e4955167ec5c04534cebea9e8273a907e7a75e1 ]
    
    It is possible qcom_scm_is_available() gives wrong indication that
    if __scm is initialized while __scm->dev is not and similar issue
    is also possible with __scm->waitq_comp.
    
    Fix this appropriately by the use of release barrier and read barrier
    that will make sure if __scm is initialized so, is all of its field
    variable.
    
    Fixes: d0f6fa7ba2d6 ("firmware: qcom: scm: Convert SCM to platform driver")
    Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic")
    Signed-off-by: Mukesh Ojha <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

firmware: raspberrypi: Use correct device for DMA mappings [+ + +]
Author: Laurent Pinchart <[email protected]>
Date:   Tue Mar 26 21:58:06 2024 +0200

    firmware: raspberrypi: Use correct device for DMA mappings
    
    [ Upstream commit df518a0ae1b982a4dcf2235464016c0c4576a34d ]
    
    The buffer used to transfer data over the mailbox interface is mapped
    using the client's device. This is incorrect, as the device performing
    the DMA transfer is the mailbox itself. Fix it by using the mailbox
    controller device instead.
    
    This requires including the mailbox_controller.h header to dereference
    the mbox_chan and mbox_controller structures. The header is not meant to
    be included by clients. This could be fixed by extending the client API
    with a function to access the controller's device.
    
    Fixes: 4e3d60656a72 ("ARM: bcm2835: Add the Raspberry Pi firmware driver")
    Signed-off-by: Laurent Pinchart <[email protected]>
    Reviewed-by: Stefan Wahren <[email protected]>
    Tested-by: Ivan T. Ivanov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fpga: dfl-pci: add PCI subdevice ID for Intel D5005 card [+ + +]
Author: Peter Colberg <[email protected]>
Date:   Mon Apr 22 19:02:57 2024 -0400

    fpga: dfl-pci: add PCI subdevice ID for Intel D5005 card
    
    [ Upstream commit bb1dbeceb1c20cfd81271e1bd69892ebd1ee38e0 ]
    
    Add PCI subdevice ID for the Intel D5005 Stratix 10 FPGA card as
    used with the Open FPGA Stack (OFS) FPGA Interface Manager (FIM).
    
    Unlike the Intel D5005 PAC FIM which exposed a separate PCI device ID,
    the OFS FIM reuses the same device ID for all DFL-based FPGA cards
    and differentiates on the subdevice ID. The subdevice ID values were
    chosen as the numeric part of the FPGA card names in hexadecimal.
    
    Signed-off-by: Peter Colberg <[email protected]>
    Reviewed-by: Matthew Gerlach <[email protected]>
    Acked-by: Xu Yilun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Xu Yilun <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs/ntfs3: Break dir enumeration if directory contents error [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Tue Apr 23 17:21:58 2024 +0300

    fs/ntfs3: Break dir enumeration if directory contents error
    
    commit 302e9dca8428979c9c99f2dbb44dc1783f5011c3 upstream.
    
    If we somehow attempt to read beyond the directory size, an error
    is supposed to be returned.
    
    However, in some cases, read requests do not stop and instead enter
    into a loop.
    
    To avoid this, we set the position in the directory to the end.
    
    Signed-off-by: Konstantin Komarov <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

fs/ntfs3: Fix case when index is reused during tree transformation [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Tue Apr 23 15:31:56 2024 +0300

    fs/ntfs3: Fix case when index is reused during tree transformation
    
    commit 05afeeebcac850a016ec4fb1f681ceda11963562 upstream.
    
    In most cases when adding a cluster to the directory index,
    they are placed at the end, and in the bitmap, this cluster corresponds
    to the last bit. The new directory size is calculated as follows:
    
            data_size = (u64)(bit + 1) << indx->index_bits;
    
    In the case of reusing a non-final cluster from the index,
    data_size is calculated incorrectly, resulting in the directory size
    differing from the actual size.
    
    A check for cluster reuse has been added, and the size update is skipped.
    
    Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block")
    Signed-off-by: Konstantin Komarov <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

fs/ntfs3: Remove max link count info display during driver init [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Wed Apr 3 10:08:04 2024 +0300

    fs/ntfs3: Remove max link count info display during driver init
    
    commit a8948b5450e7c65a3a34ebf4ccfcebc19335d4fb upstream.
    
    Removes the output of this purely informational message from the
    kernel buffer:
    
            "ntfs3: Max link count 4000"
    
    Signed-off-by: Konstantin Komarov <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

fs/ntfs3: Taking DOS names into account during link counting [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Wed Apr 17 10:33:06 2024 +0300

    fs/ntfs3: Taking DOS names into account during link counting
    
    commit 110b24eb1a749bea3440f3ca2ff890a26179050a upstream.
    
    When counting and checking hard links in an ntfs file record,
    
      struct MFT_REC {
        struct NTFS_RECORD_HEADER rhdr; // 'FILE'
        __le16 seq;             // 0x10: Sequence number for this record.
    >>  __le16 hard_links;  // 0x12: The number of hard links to record.
        __le16 attr_off;    // 0x14: Offset to attributes.
      ...
    
    the ntfs3 driver ignored short names (DOS names), causing the link count
    to be reduced by 1 and messages to be output to dmesg.
    
    For Windows, such a situation is a minor error, meaning chkdsk does not report
    errors on such a volume, and in the case of using the /f switch, it silently
    corrects them, reporting that no errors were found. This does not affect
    the consistency of the file system.
    
    Nevertheless, the behavior in the ntfs3 driver is incorrect and
    changes the content of the file system. This patch should fix that.
    
    PS: most likely, there has been a confusion of concepts
    MFT_REC::hard_links and inode::__i_nlink.
    
    Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block")
    Signed-off-by: Konstantin Komarov <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ftrace: Fix possible use-after-free issue in ftrace_location() [+ + +]
Author: Zheng Yejian <[email protected]>
Date:   Fri May 10 03:28:59 2024 +0800

    ftrace: Fix possible use-after-free issue in ftrace_location()
    
    commit e60b613df8b6253def41215402f72986fee3fc8d upstream.
    
    KASAN reports a bug:
    
      BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
      Read of size 8 at addr ffff888141d40010 by task insmod/424
      CPU: 8 PID: 424 Comm: insmod Tainted: G        W          6.9.0-rc2+
      [...]
      Call Trace:
       <TASK>
       dump_stack_lvl+0x68/0xa0
       print_report+0xcf/0x610
       kasan_report+0xb5/0xe0
       ftrace_location+0x90/0x120
       register_kprobe+0x14b/0xa40
       kprobe_init+0x2d/0xff0 [kprobe_example]
       do_one_initcall+0x8f/0x2d0
       do_init_module+0x13a/0x3c0
       load_module+0x3082/0x33d0
       init_module_from_file+0xd2/0x130
       __x64_sys_finit_module+0x306/0x440
       do_syscall_64+0x68/0x140
       entry_SYSCALL_64_after_hwframe+0x71/0x79
    
    The root cause is that, in lookup_rec(), ftrace record of some address
    is being searched in ftrace pages of some module, but those ftrace pages
    at the same time is being freed in ftrace_release_mod() as the
    corresponding module is being deleted:
    
               CPU1                       |      CPU2
      register_kprobes() {                | delete_module() {
        check_kprobe_address_safe() {     |
          arch_check_ftrace_location() {  |
            ftrace_location() {           |
              lookup_rec() // USE!        |   ftrace_release_mod() // Free!
    
    To fix this issue:
      1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
      2. Use ftrace_location_range() instead of lookup_rec() in
         ftrace_location();
      3. Call synchronize_rcu() before freeing any ftrace pages both in
         ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().
    
    Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
    
    Cc: [email protected]
    Cc: <[email protected]>
    Cc: <[email protected]>
    Cc: <[email protected]>
    Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization")
    Suggested-by: Steven Rostedt <[email protected]>
    Signed-off-by: Zheng Yejian <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
gfs2: do_xmote fixes [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Mon Apr 15 11:23:04 2024 +0200

    gfs2: do_xmote fixes
    
    [ Upstream commit 9947a06d29c0a30da88cdc6376ca5fd87083e130 ]
    
    Function do_xmote() is called with the glock spinlock held.  Commit
    86934198eefa added a 'goto skip_inval' statement at the beginning of the
    function to further below where the glock spinlock is expected not to be
    held anymore.  Then it added code there that requires the glock spinlock
    to be held.  This doesn't make sense; fix this up by dropping and
    retaking the spinlock where needed.
    
    In addition, when ->lm_lock() returned an error, do_xmote() didn't fail
    the locking operation, and simply left the glock hanging; fix that as
    well.  (This is a much older error.)
    
    Fixes: 86934198eefa ("gfs2: Clear flags when withdraw prevents xmote")
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: Don't forget to complete delayed withdraw [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Fri Jan 26 11:49:44 2024 +0100

    gfs2: Don't forget to complete delayed withdraw
    
    [ Upstream commit b01189333ee91c1ae6cd96dfd1e3a3c2e69202f0 ]
    
    Commit fffe9bee14b0 ("gfs2: Delay withdraw from atomic context")
    switched from gfs2_withdraw() to gfs2_withdraw_delayed() in
    gfs2_ail_error(), but failed to then check if a delayed withdraw had
    occurred.  Fix that by adding the missing check in __gfs2_ail_flush(),
    where the spin locks are already dropped and a withdraw is possible.
    
    Fixes: fffe9bee14b0 ("gfs2: Delay withdraw from atomic context")
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: finish_xmote cleanup [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Fri Apr 12 19:16:58 2024 +0200

    gfs2: finish_xmote cleanup
    
    [ Upstream commit 1cd28e15864054f3c48baee9eecda1c0441c48ac ]
    
    Currently, function finish_xmote() takes and releases the glock
    spinlock.  However, all of its callers immediately take that spinlock
    again, so it makes more sense to take the spin lock before calling
    finish_xmote() already.
    
    With that, thaw_glock() is the only place that sets the GLF_HAVE_REPLY
    flag outside of the glock spinlock, but it also takes that spinlock
    immediately thereafter.  Change that to set the bit when the spinlock is
    already held.  This allows to switch from test_and_clear_bit() to
    test_bit() and clear_bit() in glock_work_func().
    
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Stable-dep-of: 9947a06d29c0 ("gfs2: do_xmote fixes")
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: Fix "ignore unlock failures after withdraw" [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Fri Apr 5 13:47:51 2024 +0200

    gfs2: Fix "ignore unlock failures after withdraw"
    
    [ Upstream commit 5d9231111966b6c5a65016d58dcbeab91055bc91 ]
    
    Commit 3e11e53041502 tries to suppress dlm_lock() lock conversion errors
    that occur when the lockspace has already been released.
    
    It does that by setting and checking the SDF_SKIP_DLM_UNLOCK flag.  This
    conflicts with the intended meaning of the SDF_SKIP_DLM_UNLOCK flag, so
    check whether the lockspace is still allocated instead.
    
    (Given the current DLM API, checking for this kind of error after the
    fact seems easier that than to make sure that the lockspace is still
    allocated before calling dlm_lock().  Changing the DLM API so that users
    maintain the lockspace references themselves would be an option.)
    
    Fixes: 3e11e53041502 ("GFS2: ignore unlock failures after withdraw")
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: Fix potential glock use-after-free on unmount [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Wed Apr 10 04:50:18 2024 +0200

    gfs2: Fix potential glock use-after-free on unmount
    
    [ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
    
    When a DLM lockspace is released and there ares still locks in that
    lockspace, DLM will unlock those locks automatically.  Commit
    fb6791d100d1b started exploiting this behavior to speed up filesystem
    unmount: gfs2 would simply free glocks it didn't want to unlock and then
    release the lockspace.  This didn't take the bast callbacks for
    asynchronous lock contention notifications into account, which remain
    active until until a lock is unlocked or its lockspace is released.
    
    To prevent those callbacks from accessing deallocated objects, put the
    glocks that should not be unlocked on the sd_dead_glocks list, release
    the lockspace, and only then free those glocks.
    
    As an additional measure, ignore unexpected ast and bast callbacks if
    the receiving glock is dead.
    
    Fixes: fb6791d100d1b ("GFS2: skip dlm_unlock calls in unmount")
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Cc: David Teigland <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: Remove ill-placed consistency check [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Wed Apr 10 04:24:56 2024 +0200

    gfs2: Remove ill-placed consistency check
    
    [ Upstream commit 59f60005797b4018d7b46620037e0c53d690795e ]
    
    This consistency check was originally added by commit 9287c6452d2b1
    ("gfs2: Fix occasional glock use-after-free").  It is ill-placed in
    gfs2_glock_free() because if it holds there, it must equally hold in
    __gfs2_glock_put() already.  Either way, the check doesn't seem
    necessary anymore.
    
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount")
    Signed-off-by: Sasha Levin <[email protected]>

 
gpio: nuvoton: Fix sgpio irq handle error [+ + +]
Author: Jim Liu <[email protected]>
Date:   Mon May 6 14:42:44 2024 +0800

    gpio: nuvoton: Fix sgpio irq handle error
    
    [ Upstream commit 7f45fe2ea3b8c85787976293126a4a7133b107de ]
    
    The generic_handle_domain_irq() function calls irq_resolve_mapping().
    Thus delete a duplicative irq_find_mapping() call
    so that a stack trace and an RCU stall will be avoided.
    
    Fixes: c4f8457d17ce ("gpio: nuvoton: Add Nuvoton NPCM sgpio driver")
    Signed-off-by: Jim Liu <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
HID: amd_sfh: Handle "no sensors" in PM operations [+ + +]
Author: Basavaraj Natikar <[email protected]>
Date:   Tue May 7 12:40:44 2024 +0530

    HID: amd_sfh: Handle "no sensors" in PM operations
    
    [ Upstream commit 077e3e3bc84a51891e732507bbbd9acf6e0e4c8b ]
    
    Resume or suspend each sensor device based on the num_hid_devices.
    Therefore, add a check to handle the special case where no sensors are
    present.
    
    Fixes: 93ce5e0231d7 ("HID: amd_sfh: Implement SFH1.1 functionality")
    Signed-off-by: Basavaraj Natikar <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: intel-ish-hid: ipc: Add check for pci_alloc_irq_vectors [+ + +]
Author: Chen Ni <[email protected]>
Date:   Mon Apr 29 16:54:22 2024 +0800

    HID: intel-ish-hid: ipc: Add check for pci_alloc_irq_vectors
    
    [ Upstream commit 6baa4524027fd64d7ca524e1717c88c91a354b93 ]
    
    Add a check for the return value of pci_alloc_irq_vectors() and return
    error if it fails.
    
    [[email protected]: reworded changelog based on Srinivas' suggestion]
    Fixes: 74fbc7d371d9 ("HID: intel-ish-hid: add MSI interrupt support")
    Signed-off-by: Chen Ni <[email protected]>
    Acked-by: Srinivas Pandruvada <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: mcp-2221: cancel delayed_work only when CONFIG_IIO is enabled [+ + +]
Author: Abdelrahman Morsy <[email protected]>
Date:   Tue Apr 2 14:14:06 2024 +0200

    HID: mcp-2221: cancel delayed_work only when CONFIG_IIO is enabled
    
    [ Upstream commit 3cba9cfcc1520a2307a29f6fab887bcfc121c417 ]
    
    If the device is unplugged and CONFIG_IIO is not supported, this will
    result in a warning message at kernel/workqueue.
    
    Only cancel delayed work in mcp2221_remove(), when CONFIG_IIO is enabled.
    
    Signed-off-by: Abdelrahman Morsy <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: nintendo: Fix N64 controller being identified as mouse [+ + +]
Author: Nuno Pereira <[email protected]>
Date:   Mon Feb 26 22:39:31 2024 +0000

    HID: nintendo: Fix N64 controller being identified as mouse
    
    [ Upstream commit 8db8c77059e75a0f418b10ede39dd82a9eb031fa ]
    
    This patch is regarding the recent addition of support for the NSO
    controllers to hid-nintendo. All controllers are working correctly with the
    exception of the N64 controller, which is being identified as a mouse by
    udev. This results in the joystick controlling the mouse cursor and the
    controller not being detected by games.
    
    The reason for this is because the N64's C buttons have been attributed to
    BTN_FORWARD, BTN_BACK, BTN_LEFT, BTN_RIGHT, which are buttons typically
    attributed to mice.
    
    This patch changes those buttons to controller buttons, making the
    controller be correctly identified as such.
    
    Signed-off-by: Nuno Pereira <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hwrng: stm32 - put IP into RPM suspend on failure [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Fri Apr 19 07:01:13 2024 +0200

    hwrng: stm32 - put IP into RPM suspend on failure
    
    [ Upstream commit da62ed5c019cc48648f37c7a07e6a56cf637a795 ]
    
    In case of an irrecoverable failure, put the IP into RPM suspend
    to avoid RPM imbalance. I did not trigger this case, but it seems
    it should be done based on reading the code.
    
    Fixes: b17bc6eb7c2b ("hwrng: stm32 - rework error handling in stm32_rng_read()")
    Signed-off-by: Marek Vasut <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

hwrng: stm32 - repair clock handling [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Fri Apr 19 07:01:14 2024 +0200

    hwrng: stm32 - repair clock handling
    
    [ Upstream commit c819d7b836c5dfca0854d3e56664293601f2176d ]
    
    The clock management in this driver does not seem to be correct. The
    struct hwrng .init callback enables the clock, but there is no matching
    .cleanup callback to disable the clock. The clock get disabled as some
    later point by runtime PM suspend callback.
    
    Furthermore, both runtime PM and sleep suspend callbacks access registers
    first and disable clock which are used for register access second. If the
    IP is already in RPM suspend and the system enters sleep state, the sleep
    callback will attempt to access registers while the register clock are
    already disabled. This bug has been fixed once before already in commit
    9bae54942b13 ("hwrng: stm32 - fix pm_suspend issue"), and regressed in
    commit ff4e46104f2e ("hwrng: stm32 - rework power management sequences") .
    
    Fix this slightly differently, disable register clock at the end of .init
    callback, this way the IP is disabled after .init. On every access to the
    IP, which really is only stm32_rng_read(), do pm_runtime_get_sync() which
    is already done in stm32_rng_read() to bring the IP from RPM suspend, and
    pm_runtime_mark_last_busy()/pm_runtime_put_sync_autosuspend() to put it
    back into RPM suspend.
    
    Change sleep suspend/resume callbacks to enable and disable register clock
    around register access, as those cannot use the RPM suspend/resume callbacks
    due to slightly different initialization in those sleep callbacks. This way,
    the register access should always be performed with clock surely enabled.
    
    Fixes: ff4e46104f2e ("hwrng: stm32 - rework power management sequences")
    Signed-off-by: Marek Vasut <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

hwrng: stm32 - use logical OR in conditional [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Fri Apr 19 07:01:12 2024 +0200

    hwrng: stm32 - use logical OR in conditional
    
    [ Upstream commit 31b57788a5024d3a114b28dad224a93831b90b5f ]
    
    The conditional is used to check whether err is non-zero OR whether
    reg variable is non-zero after clearing bits from it. This should be
    done using logical OR, not bitwise OR, fix it.
    
    Fixes: 6b85a7e141cb ("hwrng: stm32 - implement STM32MP13x support")
    Signed-off-by: Marek Vasut <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
IB/mlx5: Use __iowrite64_copy() for write combining stores [+ + +]
Author: Jason Gunthorpe <[email protected]>
Date:   Thu Apr 11 13:46:19 2024 -0300

    IB/mlx5: Use __iowrite64_copy() for write combining stores
    
    [ Upstream commit ef302283ddfceaba2657923af3f90fd58e6dff06 ]
    
    mlx5 has a built in self-test at driver startup to evaluate if the
    platform supports write combining to generate a 64 byte PCIe TLP or
    not. This has proven necessary because a lot of common scenarios end up
    with broken write combining (especially inside virtual machines) and there
    is other way to learn this information.
    
    This self test has been consistently failing on new ARM64 CPU
    designs (specifically with NVIDIA Grace's implementation of Neoverse
    V2). The C loop around writeq() generates some pretty terrible ARM64
    assembly, but historically this has worked on a lot of existing ARM64 CPUs
    till now.
    
    We see it succeed about 1 time in 10,000 on the worst effected
    systems. The CPU architects speculate that the load instructions
    interspersed with the stores makes the WC buffers statistically flush too
    often and thus the generation of large TLPs becomes infrequent. This makes
    the boot up test unreliable in that it indicates no write-combining,
    however userspace would be fine since it uses a ST4 instruction.
    
    Further, S390 has similar issues where only the special zpci_memcpy_toio()
    will actually generate large TLPs, and the open coded loop does not
    trigger it at all.
    
    Fix both ARM64 and S390 by switching to __iowrite64_copy() which now
    provides architecture specific variants that have a high change of
    generating a large TLP with write combining. x86 continues to use a
    similar writeq loop in the generate __iowrite64_copy().
    
    Fixes: 11f552e21755 ("IB/mlx5: Test write combining support")
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Niklas Schnelle <[email protected]>
    Acked-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ice: Fix package download algorithm [+ + +]
Author: Dan Nowlin <[email protected]>
Date:   Wed May 8 10:19:07 2024 -0700

    ice: Fix package download algorithm
    
    [ Upstream commit 6d51d44ecddb5c2962688ef06e55e4fbc949f04a ]
    
    Previously, the driver assumed that all signature segments would contain
    one or more buffers to download. In the future, there will be signature
    segments that will contain no buffers to download.
    
    Correct download flow to allow for signature segments that have zero
    download buffers and skip the download in this case.
    
    Fixes: 3cbdb0343022 ("ice: Add support for E830 DDP package segment")
    Reviewed-by: Przemek Kitszel <[email protected]>
    Signed-off-by: Dan Nowlin <[email protected]>
    Signed-off-by: Paul Greenwalt <[email protected]>
    Reviewed-by: Paul Menzel <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ice: make ice_vsi_cfg_rxq() static [+ + +]
Author: Maciej Fijalkowski <[email protected]>
Date:   Tue Jan 23 12:58:45 2024 +0100

    ice: make ice_vsi_cfg_rxq() static
    
    [ Upstream commit 3e5fb691faee1d43ee13d4ce2666b0a05e1555b3 ]
    
    Currently, XSK control path in ice driver calls directly
    ice_vsi_cfg_rxq() whereas we have ice_vsi_cfg_single_rxq() for that
    purpose. Use the latter from XSK side and make ice_vsi_cfg_rxq() static.
    
    ice_vsi_cfg_rxq() resides in ice_base.c and is rather big, so to reduce
    the code churn let us move two callers of it from ice_lib.c to
    ice_base.c.
    
    Signed-off-by: Maciej Fijalkowski <[email protected]>
    Acked-by: Magnus Karlsson <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Chandan Kumar Rout <[email protected]> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Stable-dep-of: e77f43d531af ("Bluetooth: hci_core: Fix not handling hdev->le_num_of_adv_sets=1")
    Signed-off-by: Sasha Levin <[email protected]>

ice: make ice_vsi_cfg_txq() static [+ + +]
Author: Maciej Fijalkowski <[email protected]>
Date:   Tue Jan 23 12:58:46 2024 +0100

    ice: make ice_vsi_cfg_txq() static
    
    [ Upstream commit a292ba981324ec790eb671df1c64fae5c98c4b3d ]
    
    Currently, XSK control path in ice driver calls directly
    ice_vsi_cfg_txq() whereas we have ice_vsi_cfg_single_txq() for that
    purpose. Use the latter from XSK side and make ice_vsi_cfg_txq() static.
    
    ice_vsi_cfg_txq() resides in ice_base.c and is rather big, so to reduce
    the code churn let us move the callers of it from ice_lib.c to
    ice_base.c.
    
    This change puts ice_qp_ena() on nice diet due to the checks and
    operations that ice_vsi_cfg_single_{r,t}xq() do internally.
    
    add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-182 (-182)
    Function                                     old     new   delta
    ice_xsk_pool_setup                          2165    1983    -182
    Total: Before=472597, After=472415, chg -0.04%
    
    Signed-off-by: Maciej Fijalkowski <[email protected]>
    Acked-by: Magnus Karlsson <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Chandan Kumar Rout <[email protected]> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Stable-dep-of: e77f43d531af ("Bluetooth: hci_core: Fix not handling hdev->le_num_of_adv_sets=1")
    Signed-off-by: Sasha Levin <[email protected]>

 
idpf: don't skip over ethtool tcp-data-split setting [+ + +]
Author: Michal Schmidt <[email protected]>
Date:   Wed May 15 11:24:14 2024 +0200

    idpf: don't skip over ethtool tcp-data-split setting
    
    [ Upstream commit 67708158e732bf03d076fba1e3d4453fbf8292a2 ]
    
    Disabling tcp-data-split on idpf silently fails:
      # ethtool -G $NETDEV tcp-data-split off
      # ethtool -g $NETDEV | grep 'TCP data split'
      TCP data split:        on
    
    But it works if you also change 'tx' or 'rx':
      # ethtool -G $NETDEV tcp-data-split off tx 256
      # ethtool -g $NETDEV | grep 'TCP data split'
      TCP data split:        off
    
    The bug is in idpf_set_ringparam, where it takes a shortcut out if the
    TX and RX sizes are not changing. Fix it by checking also if the
    tcp-data-split setting remains unchanged. Only then can the soft reset
    be skipped.
    
    Fixes: 9b1aa3ef2328 ("idpf: add get/set for Ethtool's header split ringparam")
    Reported-by: Xu Du <[email protected]>
    Closes: https://issues.redhat.com/browse/RHEL-36182
    Signed-off-by: Michal Schmidt <[email protected]>
    Reviewed-by: Alexander Lobakin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Input: amimouse - mark driver struct with __refdata to prevent section mismatch [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Tue Apr 30 11:46:32 2024 -0700

    Input: amimouse - mark driver struct with __refdata to prevent section mismatch
    
    [ Upstream commit 0537c8eef4f699aacdeb67c6181c66cccd63c7f5 ]
    
    As described in the added code comment, a reference to .exit.text is ok
    for drivers registered via module_platform_driver_probe(). Make this
    explicit to prevent the following section mismatch warning
    
            WARNING: modpost: drivers/input/mouse/amimouse: section mismatch in reference: amimouse_driver+0x8 (section: .data) -> amimouse_remove (section: .exit.text)
    
    that triggers on an allmodconfig W=1 build.
    
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/2e3783106bf6bd9a7bdeb12b706378fb16316471.1711748999.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Input: try trimming too long modalias strings [+ + +]
Author: Dmitry Torokhov <[email protected]>
Date:   Mon Apr 29 14:50:41 2024 -0700

    Input: try trimming too long modalias strings
    
    commit 0774d19038c496f0c3602fb505c43e1b2d8eed85 upstream.
    
    If an input device declares too many capability bits then modalias
    string for such device may become too long and not fit into uevent
    buffer, resulting in failure of sending said uevent. This, in turn,
    may prevent userspace from recognizing existence of such devices.
    
    This is typically not a concern for real hardware devices as they have
    limited number of keys, but happen with synthetic devices such as
    ones created by xen-kbdfront driver, which creates devices as being
    capable of delivering all possible keys, since it doesn't know what
    keys the backend may produce.
    
    To deal with such devices input core will attempt to trim key data,
    in the hope that the rest of modalias string will fit in the given
    buffer. When trimming key data it will indicate that it is not
    complete by placing "+," sign, resulting in conversions like this:
    
    old: k71,72,73,74,78,7A,7B,7C,7D,8E,9E,A4,AD,E0,E1,E4,F8,174,
    new: k71,72,73,74,78,7A,7B,7C,+,
    
    This should allow existing udev rules continue to work with existing
    devices, and will also allow writing more complex rules that would
    recognize trimmed modalias and check input device characteristics by
    other means (for example by parsing KEY= data in uevent or parsing
    input device sysfs attributes).
    
    Note that the driver core may try adding more uevent environment
    variables once input core is done adding its own, so when forming
    modalias we can not use the entire available buffer, so we reduce
    it by somewhat an arbitrary amount (96 bytes).
    
    Reported-by: Jason Andryuk <[email protected]>
    Reviewed-by: Peter Hutterer <[email protected]>
    Tested-by: Jason Andryuk <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Input: xpad - add support for ASUS ROG RAIKIRI [+ + +]
Author: Vicki Pfau <[email protected]>
Date:   Wed Apr 3 20:53:45 2024 -0700

    Input: xpad - add support for ASUS ROG RAIKIRI
    
    [ Upstream commit be81415a32ef6d8a8a85529fcfac03d05b3e757d ]
    
    Add the VID/PID for ASUS ROG RAIKIRI to xpad_device and the VID to xpad_table
    
    Signed-off-by: Vicki Pfau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
io-wq: write next_work before dropping acct_lock [+ + +]
Author: Gabriel Krisman Bertazi <[email protected]>
Date:   Mon Apr 15 22:10:53 2024 -0400

    io-wq: write next_work before dropping acct_lock
    
    [ Upstream commit 068c27e32e51e94e4a9eb30ae85f4097a3602980 ]
    
    Commit 361aee450c6e ("io-wq: add intermediate work step between pending
    list and active work") closed a race between a cancellation and the work
    being removed from the wq for execution.  To ensure the request is
    always reachable by the cancellation, we need to move it within the wq
    lock, which also synchronizes the cancellation.  But commit
    42abc95f05bf ("io-wq: decouple work_list protection from the big
    wqe->lock") replaced the wq lock here and accidentally reintroduced the
    race by releasing the acct_lock too early.
    
    In other words:
    
            worker                |     cancellation
    work = io_get_next_work()     |
    raw_spin_unlock(&acct->lock); |
                                  |
                                  | io_acct_cancel_pending_work
                                  | io_wq_worker_cancel()
    worker->next_work = work
    
    Using acct_lock is still enough since we synchronize on it on
    io_acct_cancel_pending_work.
    
    Fixes: 42abc95f05bf ("io-wq: decouple work_list protection from the big wqe->lock")
    Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring/net: ensure async prep handlers always initialize ->done_io [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Fri Mar 15 16:36:23 2024 -0600

    io_uring/net: ensure async prep handlers always initialize ->done_io
    
    [ Upstream commit f3a640cca951ef9715597e68f5363afc0f452a88 ]
    
    If we get a request with IOSQE_ASYNC set, then we first run the prep
    async handlers. But if we then fail setting it up and want to post
    a CQE with -EINVAL, we use ->done_io. This was previously guarded with
    REQ_F_PARTIAL_IO, and the normal setup handlers do set it up before any
    potential errors, but we need to cover the async setup too.
    
    Fixes: 9817ad85899f ("io_uring/net: remove dependency on REQ_F_PARTIAL_IO for sr->done_io")
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

io_uring/net: fix sendzc lazy wake polling [+ + +]
Author: Pavel Begunkov <[email protected]>
Date:   Tue Apr 30 16:42:30 2024 +0100

    io_uring/net: fix sendzc lazy wake polling
    
    [ Upstream commit ef42b85a5609cd822ca0a68dd2bef2b12b5d1ca3 ]
    
    SEND[MSG]_ZC produces multiple CQEs via notifications, LAZY_WAKE doesn't
    handle it and so disable LAZY_WAKE for sendzc polling. It should be
    fine, sends are not likely to be polled in the first place.
    
    Fixes: 6ce4a93dbb5b ("io_uring/poll: use IOU_F_TWQ_LAZY_WAKE for wakeups")
    Signed-off-by: Pavel Begunkov <[email protected]>
    Link: https://lore.kernel.org/r/5b360fb352d91e3aec751d75c87dfb4753a084ee.1714488419.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

io_uring/net: remove dependency on REQ_F_PARTIAL_IO for sr->done_io [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Thu Mar 7 12:43:22 2024 -0700

    io_uring/net: remove dependency on REQ_F_PARTIAL_IO for sr->done_io
    
    [ Upstream commit 9817ad85899fb695f875610fb743cb18cf087582 ]
    
    Ensure that prep handlers always initialize sr->done_io before any
    potential failure conditions, and with that, we now it's always been
    set even for the failure case.
    
    With that, we don't need to use the REQ_F_PARTIAL_IO flag to gate on that.
    Additionally, we should not overwrite req->cqe.res unless sr->done_io is
    actually positive.
    
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: ef42b85a5609 ("io_uring/net: fix sendzc lazy wake polling")
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring: fail NOP if non-zero op flags is passed in [+ + +]
Author: Ming Lei <[email protected]>
Date:   Fri May 10 11:50:27 2024 +0800

    io_uring: fail NOP if non-zero op flags is passed in
    
    commit 3d8f874bd620ce03f75a5512847586828ab86544 upstream.
    
    The NOP op flags should have been checked from beginning like any other
    opcode, otherwise NOP may not be extended with the op flags.
    
    Given both liburing and Rust io-uring crate always zeros SQE op flags, just
    ignore users which play raw NOP uring interface without zeroing SQE, because
    NOP is just for test purpose. Then we can save one NOP2 opcode.
    
    Suggested-by: Jens Axboe <[email protected]>
    Fixes: 2b188cc1bb85 ("Add io_uring IO interface")
    Cc: [email protected]
    Signed-off-by: Ming Lei <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

io_uring: use the right type for work_llist empty check [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Mon Mar 25 18:53:33 2024 -0600

    io_uring: use the right type for work_llist empty check
    
    [ Upstream commit 22537c9f79417fed70b352d54d01d2586fee9521 ]
    
    io_task_work_pending() uses wq_list_empty() on ctx->work_llist, but it's
    not an io_wq_work_list, it's a struct llist_head. They both have
    ->first as head-of-list, and it turns out the checks are identical. But
    be proper and use the right helper.
    
    Fixes: dac6a0eae793 ("io_uring: ensure iopoll runs local task work as well")
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iommu: Undo pasid attachment only for the devices that have succeeded [+ + +]
Author: Yi Liu <[email protected]>
Date:   Thu Mar 28 05:29:57 2024 -0700

    iommu: Undo pasid attachment only for the devices that have succeeded
    
    [ Upstream commit b025dea63cded0d82bccd591fa105d39efc6435d ]
    
    There is no error handling now in __iommu_set_group_pasid(), it relies on
    its caller to loop all the devices to undo the pasid attachment. This is
    not self-contained and has drawbacks. It would result in unnecessary
    remove_dev_pasid() calls on the devices that have not been attached to the
    new domain. But the remove_dev_pasid() callback would get the new domain
    from the group->pasid_array. So for such devices, the iommu driver won't
    find the attachment under the domain, hence unable to do cleanup. This may
    not be a real problem today. But it depends on the implementation of the
    underlying iommu driver. e.g. the intel iommu driver would warn for such
    devices. Such warnings are unnecessary.
    
    To solve the above problem, it is necessary to handle the error within
    __iommu_set_group_pasid(). It only loops the devices that have attached
    to the new domain, and undo it.
    
    Fixes: 16603704559c ("iommu: Add attach/detach_dev_pasid iommu interfaces")
    Suggested-by: Jason Gunthorpe <[email protected]>
    Reviewed-by: Jason Gunthorpe <[email protected]>
    Reviewed-by: Kevin Tian <[email protected]>
    Signed-off-by: Yi Liu <[email protected]>
    Reviewed-by: Lu Baolu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipv6: sr: add missing seg6_local_exit [+ + +]
Author: Hangbin Liu <[email protected]>
Date:   Thu May 9 21:18:10 2024 +0800

    ipv6: sr: add missing seg6_local_exit
    
    [ Upstream commit 3321687e321307629c71b664225b861ebf3e5753 ]
    
    Currently, we only call seg6_local_exit() in seg6_init() if
    seg6_local_init() failed. But forgot to call it in seg6_exit().
    
    Fixes: d1df6fd8a1d2 ("ipv6: sr: define core operations for seg6local lightweight tunnel")
    Signed-off-by: Hangbin Liu <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: sr: fix incorrect unregister order [+ + +]
Author: Hangbin Liu <[email protected]>
Date:   Thu May 9 21:18:11 2024 +0800

    ipv6: sr: fix incorrect unregister order
    
    [ Upstream commit 6e370a771d2985107e82d0f6174381c1acb49c20 ]
    
    Commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and
    null-ptr-deref") changed the register order in seg6_init(). But the
    unregister order in seg6_exit() is not updated.
    
    Fixes: 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref")
    Signed-off-by: Hangbin Liu <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: sr: fix invalid unregister error path [+ + +]
Author: Hangbin Liu <[email protected]>
Date:   Thu May 9 21:18:12 2024 +0800

    ipv6: sr: fix invalid unregister error path
    
    [ Upstream commit 160e9d2752181fcf18c662e74022d77d3164cd45 ]
    
    The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL
    is not defined. In that case if seg6_hmac_init() fails, the
    genl_unregister_family() isn't called.
    
    This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control
    lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible
    use-after-free and null-ptr-deref") replaced unregister_pernet_subsys()
    with genl_unregister_family() in this error path.
    
    Fixes: 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support")
    Reported-by: Guillaume Nault <[email protected]>
    Signed-off-by: Hangbin Liu <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
irqchip/alpine-msi: Fix off-by-one in allocation error path [+ + +]
Author: Zenghui Yu <[email protected]>
Date:   Wed Mar 27 22:23:05 2024 +0800

    irqchip/alpine-msi: Fix off-by-one in allocation error path
    
    [ Upstream commit ff3669a71afa06208de58d6bea1cc49d5e3fcbd1 ]
    
    When alpine_msix_gic_domain_alloc() fails, there is an off-by-one in the
    number of interrupts to be freed.
    
    Fix it by passing the number of successfully allocated interrupts, instead
    of the relative index of the last allocated one.
    
    Fixes: 3841245e8498 ("irqchip/alpine-msi: Fix freeing of interrupts on allocation error path")
    Signed-off-by: Zenghui Yu <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
irqchip/loongson-pch-msi: Fix off-by-one on allocation error path [+ + +]
Author: Zenghui Yu <[email protected]>
Date:   Wed Mar 27 22:23:34 2024 +0800

    irqchip/loongson-pch-msi: Fix off-by-one on allocation error path
    
    [ Upstream commit b327708798809328f21da8dc14cc8883d1e8a4b3 ]
    
    When pch_msi_parent_domain_alloc() returns an error, there is an off-by-one
    in the number of interrupts to be freed.
    
    Fix it by passing the number of successfully allocated interrupts, instead of the
    relative index of the last allocated one.
    
    Fixes: 632dcc2c75ef ("irqchip: Add Loongson PCH MSI controller")
    Signed-off-by: Zenghui Yu <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Jiaxun Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
jffs2: prevent xattr node from overflowing the eraseblock [+ + +]
Author: Ilya Denisyev <[email protected]>
Date:   Fri Apr 12 18:53:54 2024 +0300

    jffs2: prevent xattr node from overflowing the eraseblock
    
    [ Upstream commit c6854e5a267c28300ff045480b5a7ee7f6f1d913 ]
    
    Add a check to make sure that the requested xattr node size is no larger
    than the eraseblock minus the cleanmarker.
    
    Unlike the usual inode nodes, the xattr nodes aren't split into parts
    and spread across multiple eraseblocks, which means that a xattr node
    must not occupy more than one eraseblock. If the requested xattr value is
    too large, the xattr node can spill onto the next eraseblock, overwriting
    the nodes and causing errors such as:
    
    jffs2: argh. node added in wrong place at 0x0000b050(2)
    jffs2: nextblock 0x0000a000, expected at 0000b00c
    jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,
    read=0xfc892c93, calc=0x000000
    jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed
    at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}
    jffs2: Node at 0x0000000c with length 0x00001044 would run over the
    end of the erase block
    jffs2: Perhaps the file system was created with the wrong erase size?
    jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
    at 0x00000010: 0x1044 instead
    
    This breaks the filesystem and can lead to KASAN crashes such as:
    
    BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0
    Read of size 4 at addr ffff88802c31e914 by task repro/830
    CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
    BIOS Arch Linux 1.16.3-1-1 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0xc6/0x120
     print_report+0xc4/0x620
     ? __virt_addr_valid+0x308/0x5b0
     kasan_report+0xc1/0xf0
     ? jffs2_sum_add_kvec+0x125e/0x15d0
     ? jffs2_sum_add_kvec+0x125e/0x15d0
     jffs2_sum_add_kvec+0x125e/0x15d0
     jffs2_flash_direct_writev+0xa8/0xd0
     jffs2_flash_writev+0x9c9/0xef0
     ? __x64_sys_setxattr+0xc4/0x160
     ? do_syscall_64+0x69/0x140
     ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
     [...]
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: aa98d7cf59b5 ("[JFFS2][XATTR] XATTR support on JFFS2 (version. 5)")
    Signed-off-by: Ilya Denisyev <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KEYS: asymmetric: Add missing dependencies of FIPS_SIGNATURE_SELFTEST [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Mon Apr 22 14:10:41 2024 -0700

    KEYS: asymmetric: Add missing dependencies of FIPS_SIGNATURE_SELFTEST
    
    commit 9d2fd8bdc12f403a5c35c971936a0e1d5cb5108e upstream.
    
    Since the signature self-test uses RSA and SHA-256, it must only be
    enabled when those algorithms are enabled.  Otherwise it fails and
    panics the kernel on boot-up.
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-lkp/[email protected]
    Fixes: 3cde3174eb91 ("certs: Add FIPS selftests")
    Cc: [email protected]
    Cc: Simo Sorce <[email protected]>
    Cc: David Howells <[email protected]>
    Signed-off-by: Eric Biggers <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KEYS: asymmetric: Add missing dependency on CRYPTO_SIG [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Mon Apr 22 14:08:45 2024 -0700

    KEYS: asymmetric: Add missing dependency on CRYPTO_SIG
    
    commit dcaa86b904ea3761e62c849957dd0904e126bf4a upstream.
    
    Make ASYMMETRIC_PUBLIC_KEY_SUBTYPE select CRYPTO_SIG to avoid build
    errors like the following, which were possible with
    CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y && CONFIG_CRYPTO_SIG=n:
    
        ld: vmlinux.o: in function `public_key_verify_signature':
        (.text+0x306280): undefined reference to `crypto_alloc_sig'
        ld: (.text+0x306300): undefined reference to `crypto_sig_set_pubkey'
        ld: (.text+0x306324): undefined reference to `crypto_sig_verify'
        ld: (.text+0x30636c): undefined reference to `crypto_sig_set_privkey'
    
    Fixes: 63ba4d67594a ("KEYS: asymmetric: Use new crypto interface without scatterlists")
    Cc: [email protected]
    Signed-off-by: Eric Biggers <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ksmbd: avoid to send duplicate oplock break notifications [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Thu May 9 15:25:39 2024 +0900

    ksmbd: avoid to send duplicate oplock break notifications
    
    commit c91ecba9e421e4f2c9219cf5042fa63a12025310 upstream.
    
    This patch fixes generic/011 when oplocks is enable.
    
    Avoid to send duplicate oplock break notifications like smb2 leases
    case.
    
    Fixes: 97c2ec64667b ("ksmbd: avoid to send duplicate lease break notifications")
    Cc: [email protected]
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: ignore trailing slashes in share paths [+ + +]
Author: Nandor Kracser <[email protected]>
Date:   Tue May 21 22:56:17 2024 +0900

    ksmbd: ignore trailing slashes in share paths
    
    commit 405ee4097c4bc3e70556520aed5ba52a511c2266 upstream.
    
    Trailing slashes in share paths (like: /home/me/Share/) caused permission
    issues with shares for clients on iOS and on Android TV for me,
    but otherwise they work fine with plain old Samba.
    
    Cc: [email protected]
    Signed-off-by: Nandor Kracser <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
kunit/fortify: Fix mismatched kvalloc()/vfree() usage [+ + +]
Author: Kees Cook <[email protected]>
Date:   Thu Apr 25 16:06:22 2024 -0700

    kunit/fortify: Fix mismatched kvalloc()/vfree() usage
    
    [ Upstream commit 998b18072ceb0613629c256b409f4d299829c7ec ]
    
    The kv*() family of tests were accidentally freeing with vfree() instead
    of kvfree(). Use kvfree() instead.
    
    Fixes: 9124a2640148 ("kunit/fortify: Validate __alloc_size attribute results")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kunit: bail out early in __kunit_test_suites_init() if there are no suites to test [+ + +]
Author: Scott Mayhew <[email protected]>
Date:   Thu Mar 21 10:32:00 2024 -0400

    kunit: bail out early in __kunit_test_suites_init() if there are no suites to test
    
    [ Upstream commit 5496b9b77d7420652202b73cf036e69760be5deb ]
    
    Commit c72a870926c2 added a mutex to prevent kunit tests from running
    concurrently.  Unfortunately that mutex gets locked during module load
    regardless of whether the module actually has any kunit tests.  This
    causes a problem for kunit tests that might need to load other kernel
    modules (e.g. gss_krb5_test loading the camellia module).
    
    So check to see if there are actually any tests to run before locking
    the kunit_run_lock mutex.
    
    Fixes: c72a870926c2 ("kunit: add ability to run tests after boot using debugfs")
    Reported-by: Nico Pache <[email protected]>
    Signed-off-by: Scott Mayhew <[email protected]>
    Reviewed-by: Rae Moar <[email protected]>
    Reviewed-by: David Gow <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

kunit: Fix kthread reference [+ + +]
Author: Mickaël Salaün <[email protected]>
Date:   Mon Apr 8 09:46:20 2024 +0200

    kunit: Fix kthread reference
    
    [ Upstream commit f8aa1b98ce40184521ed95ec26cc115a255183b2 ]
    
    There is a race condition when a kthread finishes after the deadline and
    before the call to kthread_stop(), which may lead to use after free.
    
    Cc: Brendan Higgins <[email protected]>
    Cc: Shuah Khan <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Fixes: adf505457032 ("kunit: fix UAF when run kfence test case test_gfpzero")
    Reviewed-by: David Gow <[email protected]>
    Reviewed-by: Rae Moar <[email protected]>
    Signed-off-by: Mickaël Salaün <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

kunit: unregister the device on error [+ + +]
Author: Wander Lairson Costa <[email protected]>
Date:   Fri Apr 19 10:25:01 2024 -0300

    kunit: unregister the device on error
    
    [ Upstream commit fabd480b721eb30aa4e2c89507b53933069f9f6e ]
    
    kunit_init_device() should unregister the device on bus register error,
    but mistakenly it tries to unregister the bus.
    
    Unregister the device instead of the bus.
    
    Signed-off-by: Wander Lairson Costa <[email protected]>
    Fixes: d03c720e03bd ("kunit: Add APIs for managing devices")
    Reviewed-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KVM: selftests: Add test for uaccesses to non-existent vgic-v2 CPUIF [+ + +]
Author: Oliver Upton <[email protected]>
Date:   Wed Apr 24 17:39:59 2024 +0000

    KVM: selftests: Add test for uaccesses to non-existent vgic-v2 CPUIF
    
    [ Upstream commit 160933e330f4c5a13931d725a4d952a4b9aefa71 ]
    
    Assert that accesses to a non-existent vgic-v2 CPU interface
    consistently fail across the various KVM device attr ioctls. This also
    serves as a regression test for a bug wherein KVM hits a NULL
    dereference when the CPUID specified in the ioctl is invalid.
    
    Note that there is no need to print the observed errno, as TEST_ASSERT()
    will take care of it.
    
    Reviewed-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Oliver Upton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
l2tp: fix ICMP error handling for UDP-encap sockets [+ + +]
Author: Tom Parkin <[email protected]>
Date:   Mon May 13 18:22:47 2024 +0100

    l2tp: fix ICMP error handling for UDP-encap sockets
    
    [ Upstream commit 6e828dc60e509b79ef09882264952f341cb58425 ]
    
    Since commit a36e185e8c85
    ("udp: Handle ICMP errors for tunnels with same destination port on both endpoints")
    UDP's handling of ICMP errors has allowed for UDP-encap tunnels to
    determine socket associations in scenarios where the UDP hash lookup
    could not.
    
    Subsequently, commit d26796ae58940
    ("udp: check udp sock encap_type in __udp_lib_err")
    subtly tweaked the approach such that UDP ICMP error handling would be
    skipped for any UDP socket which has encapsulation enabled.
    
    In the case of L2TP tunnel sockets using UDP-encap, this latter
    modification effectively broke ICMP error reporting for the L2TP
    control plane.
    
    To a degree this isn't catastrophic inasmuch as the L2TP control
    protocol defines a reliable transport on top of the underlying packet
    switching network which will eventually detect errors and time out.
    
    However, paying attention to the ICMP error reporting allows for more
    timely detection of errors in L2TP userspace, and aids in debugging
    connectivity issues.
    
    Reinstate ICMP error handling for UDP encap L2TP tunnels:
    
     * implement struct udp_tunnel_sock_cfg .encap_err_rcv in order to allow
       the L2TP code to handle ICMP errors;
    
     * only implement error-handling for tunnels which have a managed
       socket: unmanaged tunnels using a kernel socket have no userspace to
       report errors back to;
    
     * flag the error on the socket, which allows for userspace to get an
       error such as -ECONNREFUSED back from sendmsg/recvmsg;
    
     * pass the error into ip[v6]_icmp_error() which allows for userspace to
       get extended error information via. MSG_ERRQUEUE.
    
    Fixes: d26796ae5894 ("udp: check udp sock encap_type in __udp_lib_err")
    Signed-off-by: Tom Parkin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
lib/test_hmm.c: handle src_pfns and dst_pfns allocation failure [+ + +]
Author: Duoming Zhou <[email protected]>
Date:   Tue Mar 12 08:59:05 2024 +0800

    lib/test_hmm.c: handle src_pfns and dst_pfns allocation failure
    
    [ Upstream commit c2af060d1c18beaec56351cf9c9bcbbc5af341a3 ]
    
    The kcalloc() in dmirror_device_evict_chunk() will return null if the
    physical memory has run out.  As a result, if src_pfns or dst_pfns is
    dereferenced, the null pointer dereference bug will happen.
    
    Moreover, the device is going away.  If the kcalloc() fails, the pages
    mapping a chunk could not be evicted.  So add a __GFP_NOFAIL flag in
    kcalloc().
    
    Finally, as there is no need to have physically contiguous memory, Switch
    kcalloc() to kvcalloc() in order to avoid failing allocations.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: b2ef9f5a5cb3 ("mm/hmm/test: add selftest driver for HMM")
    Signed-off-by: Duoming Zhou <[email protected]>
    Cc: Jérôme Glisse <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
libbpf: Fix error message in attach_kprobe_multi [+ + +]
Author: Jiri Olsa <[email protected]>
Date:   Thu May 2 09:55:41 2024 +0200

    libbpf: Fix error message in attach_kprobe_multi
    
    [ Upstream commit 7c13ef16e87ac2e44d16c0468b1191bceb06f95c ]
    
    We just failed to retrieve pattern, so we need to print spec instead.
    
    Fixes: ddc6b04989eb ("libbpf: Add bpf_program__attach_kprobe_multi_opts function")
    Reported-by: Andrii Nakryiko <[email protected]>
    Signed-off-by: Jiri Olsa <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

libbpf: Prevent null-pointer dereference when prog to load has no BTF [+ + +]
Author: Quentin Monnet <[email protected]>
Date:   Thu Mar 14 15:04:38 2024 +0000

    libbpf: Prevent null-pointer dereference when prog to load has no BTF
    
    [ Upstream commit 9bf48fa19a4b1d186e08b20bf7e5de26a15644fb ]
    
    In bpf_objec_load_prog(), there's no guarantee that obj->btf is non-NULL
    when passing it to btf__fd(), and this function does not perform any
    check before dereferencing its argument (as bpf_object__btf_fd() used to
    do). As a consequence, we get segmentation fault errors in bpftool (for
    example) when trying to load programs that come without BTF information.
    
    v2: Keep btf__fd() in the fix instead of reverting to bpf_object__btf_fd().
    
    Fixes: df7c3f7d3a3d ("libbpf: make uniform use of btf__fd() accessor inside libbpf")
    Suggested-by: Andrii Nakryiko <[email protected]>
    Signed-off-by: Quentin Monnet <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
libfs: Add simple_offset_empty() [+ + +]
Author: Chuck Lever <[email protected]>
Date:   Sat Feb 17 15:23:54 2024 -0500

    libfs: Add simple_offset_empty()
    
    [ Upstream commit ecba88a3b32d733d41e27973e25b2bc580f64281 ]
    
    For simple filesystems that use directory offset mapping, rely
    strictly on the directory offset map to tell when a directory has
    no children.
    
    After this patch is applied, the emptiness test holds only the RCU
    read lock when the directory being tested has no children.
    
    In addition, this adds another layer of confirmation that
    simple_offset_add/remove() are working as expected.
    
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Link: https://lore.kernel.org/r/170820143463.6328.7872919188371286951.stgit@91.116.238.104.host.secureserver.net
    Signed-off-by: Christian Brauner <[email protected]>
    Stable-dep-of: 23cdd0eed3f1 ("libfs: Fix simple_offset_rename_exchange()")
    Signed-off-by: Sasha Levin <[email protected]>

libfs: Add simple_offset_rename() API [+ + +]
Author: Chuck Lever <[email protected]>
Date:   Mon Apr 15 11:20:55 2024 -0400

    libfs: Add simple_offset_rename() API
    
    [ Upstream commit 5a1a25be995e1014abd01600479915683e356f5c ]
    
    I'm about to fix a tmpfs rename bug that requires the use of
    internal simple_offset helpers that are not available in mm/shmem.c
    
    Signed-off-by: Chuck Lever <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Stable-dep-of: ad191eb6d694 ("shmem: Fix shmem_rename2()")
    Signed-off-by: Sasha Levin <[email protected]>

libfs: Convert simple directory offsets to use a Maple Tree [+ + +]
Author: Chuck Lever <[email protected]>
Date:   Sat Feb 17 15:24:16 2024 -0500

    libfs: Convert simple directory offsets to use a Maple Tree
    
    [ Upstream commit 0e4a862174f2a8d1653a8a9cf0815020e1d3af24 ]
    
    Test robot reports:
    > kernel test robot noticed a -19.0% regression of aim9.disk_src.ops_per_sec on:
    >
    > commit: a2e459555c5f9da3e619b7e47a63f98574dc75f1 ("shmem: stable directory offsets")
    > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
    
    Feng Tang further clarifies that:
    > ... the new simple_offset_add()
    > called by shmem_mknod() brings extra cost related with slab,
    > specifically the 'radix_tree_node', which cause the regression.
    
    Willy's analysis is that, over time, the test workload causes
    xa_alloc_cyclic() to fragment the underlying SLAB cache.
    
    This patch replaces the offset_ctx's xarray with a Maple Tree in the
    hope that Maple Tree's dense node mode will handle this scenario
    more scalably.
    
    In addition, we can widen the simple directory offset maximum to
    signed long (as loff_t is also signed).
    
    Suggested-by: Matthew Wilcox <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-lkp/[email protected]
    Signed-off-by: Chuck Lever <[email protected]>
    Link: https://lore.kernel.org/r/170820145616.6328.12620992971699079156.stgit@91.116.238.104.host.secureserver.net
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Stable-dep-of: 23cdd0eed3f1 ("libfs: Fix simple_offset_rename_exchange()")
    Signed-off-by: Sasha Levin <[email protected]>

libfs: Define a minimum directory offset [+ + +]
Author: Chuck Lever <[email protected]>
Date:   Sat Feb 17 15:23:47 2024 -0500

    libfs: Define a minimum directory offset
    
    [ Upstream commit 7beea725a8ca412c6190090ce7c3a13b169592a1 ]
    
    This value is used in several places, so make it a symbolic
    constant.
    
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Link: https://lore.kernel.org/r/170820142741.6328.12428356024575347885.stgit@91.116.238.104.host.secureserver.net
    Signed-off-by: Christian Brauner <[email protected]>
    Stable-dep-of: 23cdd0eed3f1 ("libfs: Fix simple_offset_rename_exchange()")
    Signed-off-by: Sasha Levin <[email protected]>

libfs: Fix simple_offset_rename_exchange() [+ + +]
Author: Chuck Lever <[email protected]>
Date:   Mon Apr 15 11:20:54 2024 -0400

    libfs: Fix simple_offset_rename_exchange()
    
    [ Upstream commit 23cdd0eed3f1fff3af323092b0b88945a7950d8e ]
    
    User space expects the replacement (old) directory entry to have
    the same directory offset after the rename.
    
    Suggested-by: Christian Brauner <[email protected]>
    Fixes: a2e459555c5f ("shmem: stable directory offsets")
    Signed-off-by: Chuck Lever <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

libfs: Re-arrange locking in offset_iterate_dir() [+ + +]
Author: Chuck Lever <[email protected]>
Date:   Sat Feb 17 15:23:40 2024 -0500

    libfs: Re-arrange locking in offset_iterate_dir()
    
    [ Upstream commit 3f6d810665dfde0d33785420618ceb03fba0619d ]
    
    Liam and Matthew say that once the RCU read lock is released,
    xa_state is not safe to re-use for the next xas_find() call. But the
    RCU read lock must be released on each loop iteration so that
    dput(), which might_sleep(), can be called safely.
    
    Thus we are forced to walk the offset tree with fresh state for each
    directory entry. xa_find() can do this for us, though it might be a
    little less efficient than maintaining xa_state locally.
    
    We believe that in the current code base, inode->i_rwsem provides
    protection for the xa_state maintained in
    offset_iterate_dir(). However, there is no guarantee that will
    continue to be the case in the future.
    
    Since offset_iterate_dir() doesn't build xa_state locally any more,
    there's no longer a strong need for offset_find_next(). Clean up by
    rolling these two helpers together.
    
    Suggested-by: Liam R. Howlett <[email protected]>
    Message-ID: <170785993027.11135.8830043889278631735.stgit@91.116.238.104.host.secureserver.net>
    Signed-off-by: Chuck Lever <[email protected]>
    Link: https://lore.kernel.org/r/170820142021.6328.15047865406275957018.stgit@91.116.238.104.host.secureserver.net
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Stable-dep-of: 23cdd0eed3f1 ("libfs: Fix simple_offset_rename_exchange()")
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 6.8.12 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu May 30 09:49:53 2024 +0200

    Linux 6.8.12
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: Bagas Sanjaya <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: SeongJae Park <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
lkdtm: Disable CFI checking for perms functions [+ + +]
Author: Kees Cook <[email protected]>
Date:   Tue Apr 30 16:49:57 2024 -0700

    lkdtm: Disable CFI checking for perms functions
    
    [ Upstream commit fb28a8862dc4b5bf8e44578338f35d9c6c68339d ]
    
    The EXEC_RODATA test plays a lot of tricks to live in the .rodata section,
    and once again ran into objtool's (completely reasonable) assumptions
    that executable code should live in an executable section. However, this
    manifested only under CONFIG_CFI_CLANG=y, as one of the .cfi_sites was
    pointing into the .rodata section.
    
    Since we're testing non-CFI execution properties in perms.c (and
    rodata.c), we can disable CFI for the involved functions, and remove the
    CFI arguments from rodata.c entirely.
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-lkp/[email protected]
    Fixes: 6342a20efbd8 ("objtool: Add elf_create_section_pair()")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
locking/atomic/x86: Correct the definition of __arch_try_cmpxchg128() [+ + +]
Author: Uros Bizjak <[email protected]>
Date:   Mon Apr 8 11:13:56 2024 +0200

    locking/atomic/x86: Correct the definition of __arch_try_cmpxchg128()
    
    [ Upstream commit 929ad065ba2967be238dfdc0895b79fda62c7f16 ]
    
    Correct the definition of __arch_try_cmpxchg128(), introduced by:
    
      b23e139d0b66 ("arch: Introduce arch_{,try_}_cmpxchg128{,_local}()")
    
    Fixes: b23e139d0b66 ("arch: Introduce arch_{,try_}_cmpxchg128{,_local}()")
    Signed-off-by: Uros Bizjak <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Cc: "H. Peter Anvin" <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
LoongArch: Lately init pmu after smp is online [+ + +]
Author: Bibo Mao <[email protected]>
Date:   Thu Apr 25 22:17:52 2024 +0800

    LoongArch: Lately init pmu after smp is online
    
    [ Upstream commit f3334ebb8a2a1841c2824594dd992e66de19deb2 ]
    
    There is an smp function call named reset_counters() to init PMU
    registers of every CPU in PMU initialization state. It requires that all
    CPUs are online. However there is an early_initcall() wrapper for the
    PMU init funciton init_hw_perf_events(), so that pmu init funciton is
    called in do_pre_smp_initcalls() which before function smp_init().
    Function reset_counters() cannot work on other CPUs since they haven't
    boot up still.
    
    Here replace the wrapper early_initcall() with pure_initcall(), so that
    the PMU init function is called after every cpu is online.
    
    Signed-off-by: Bibo Mao <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
m68k: Fix spinlock race in kernel thread creation [+ + +]
Author: Michael Schmitz <[email protected]>
Date:   Thu Apr 11 15:36:31 2024 +1200

    m68k: Fix spinlock race in kernel thread creation
    
    [ Upstream commit da89ce46f02470ef08f0f580755d14d547da59ed ]
    
    Context switching does take care to retain the correct lock owner across
    the switch from 'prev' to 'next' tasks.  This does rely on interrupts
    remaining disabled for the entire duration of the switch.
    
    This condition is guaranteed for normal process creation and context
    switching between already running processes, because both 'prev' and
    'next' already have interrupts disabled in their saved copies of the
    status register.
    
    The situation is different for newly created kernel threads.  The status
    register is set to PS_S in copy_thread(), which does leave the IPL at 0.
    Upon restoring the 'next' thread's status register in switch_to() aka
    resume(), interrupts then become enabled prematurely.  resume() then
    returns via ret_from_kernel_thread() and schedule_tail() where run queue
    lock is released (see finish_task_switch() and finish_lock_switch()).
    
    A timer interrupt calling scheduler_tick() before the lock is released
    in finish_task_switch() will find the lock already taken, with the
    current task as lock owner.  This causes a spinlock recursion warning as
    reported by Guenter Roeck.
    
    As far as I can ascertain, this race has been opened in commit
    533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()")
    but I haven't done a detailed study of kernel history so it may well
    predate that commit.
    
    Interrupts cannot be disabled in the saved status register copy for
    kernel threads (init will complain about interrupts disabled when
    finally starting user space).  Disable interrupts temporarily when
    switching the tasks' register sets in resume().
    
    Note that a simple oriw 0x700,%sr after restoring sr is not enough here
    - this leaves enough of a race for the 'spinlock recursion' warning to
    still be observed.
    
    Tested on ARAnyM and qemu (Quadra 800 emulation).
    
    Fixes: 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()")
    Reported-by: Guenter Roeck <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Michael Schmitz <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

m68k: mac: Fix reboot hang on Mac IIci [+ + +]
Author: Finn Thain <[email protected]>
Date:   Sat May 4 14:31:12 2024 +1000

    m68k: mac: Fix reboot hang on Mac IIci
    
    [ Upstream commit 265a3b322df9a973ff1fc63da70af456ab6ae1d6 ]
    
    Calling mac_reset() on a Mac IIci does reset the system, but what
    follows is a POST failure that requires a manual reset to resolve.
    Avoid that by using the 68030 asm implementation instead of the C
    implementation.
    
    Apparently the SE/30 has a similar problem as it has used the asm
    implementation since before git. This patch extends that solution to
    other systems with a similar ROM.
    
    After this patch, the only systems still using the C implementation are
    68040 systems where adb_type is either MAC_ADB_IOP or MAC_ADB_II. This
    implies a 1 MiB Quadra ROM.
    
    This now includes the Quadra 900/950, which previously fell through to
    the "should never get here" catch-all.
    
    Reported-and-tested-by: Stan Johnson <[email protected]>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Finn Thain <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/480ebd1249d229c6dc1f3f1c6d599b8505483fd8.1714797072.git.fthain@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
macintosh/via-macii: Fix "BUG: sleeping function called from invalid context" [+ + +]
Author: Finn Thain <[email protected]>
Date:   Wed Mar 13 13:53:41 2024 +1100

    macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"
    
    [ Upstream commit d301a71c76ee4c384b4e03cdc320a55f5cf1df05 ]
    
    The via-macii ADB driver calls request_irq() after disabling hard
    interrupts. But disabling interrupts isn't necessary here because the
    VIA shift register interrupt was masked during VIA1 initialization.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Finn Thain <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/419fcc09d0e563b425c419053d02236b044d86b0.1710298421.git.fthain@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
maple_tree: Add mtree_alloc_cyclic() [+ + +]
Author: Chuck Lever <[email protected]>
Date:   Sat Feb 17 15:24:01 2024 -0500

    maple_tree: Add mtree_alloc_cyclic()
    
    [ Upstream commit 9b6713cc75229f25552c643083cbdbfb771e5bca ]
    
    I need a cyclic allocator for the simple_offset implementation in
    fs/libfs.c.
    
    Signed-off-by: Chuck Lever <[email protected]>
    Link: https://lore.kernel.org/r/170820144179.6328.12838600511394432325.stgit@91.116.238.104.host.secureserver.net
    Signed-off-by: Christian Brauner <[email protected]>
    Stable-dep-of: 23cdd0eed3f1 ("libfs: Fix simple_offset_rename_exchange()")
    Signed-off-by: Sasha Levin <[email protected]>

 
md: fix resync softlockup when bitmap size is less than array size [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Mon Apr 22 14:58:24 2024 +0800

    md: fix resync softlockup when bitmap size is less than array size
    
    [ Upstream commit f0e729af2eb6bee9eb58c4df1087f14ebaefe26b ]
    
    Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
    trigger following softlockup:
    
    kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
    CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
    RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
    Call Trace:
     <TASK>
     md_bitmap_start_sync+0x6b/0xf0
     raid10_sync_request+0x25c/0x1b40 [raid10]
     md_do_sync+0x64b/0x1020
     md_thread+0xa7/0x170
     kthread+0xcf/0x100
     ret_from_fork+0x30/0x50
     ret_from_fork_asm+0x1a/0x30
    
    And the detailed process is as follows:
    
    md_do_sync
     j = mddev->resync_min
     while (j < max_sectors)
      sectors = raid10_sync_request(mddev, j, &skipped)
       if (!md_bitmap_start_sync(..., &sync_blocks))
        // md_bitmap_start_sync set sync_blocks to 0
        return sync_blocks + sectors_skippe;
      // sectors = 0;
      j += sectors;
      // j never change
    
    Root cause is that commit 301867b1c168 ("md/raid10: check
    slab-out-of-bounds in md_bitmap_get_counter") return early from
    md_bitmap_get_counter(), without setting returned blocks.
    
    Fix this problem by always set returned blocks from
    md_bitmap_get_counter"(), as it used to be.
    
    Noted that this patch just fix the softlockup problem in kernel, the
    case that bitmap size doesn't match array size still need to be fixed.
    
    Fixes: 301867b1c168 ("md/raid10: check slab-out-of-bounds in md_bitmap_get_counter")
    Reported-and-tested-by: Nigel Croxon <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Song Liu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries [+ + +]
Author: Zhipeng Lu <[email protected]>
Date:   Thu Jan 18 16:13:00 2024 +0100

    media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries
    
    [ Upstream commit 3b621e9e9e148c0928ab109ac3d4b81487469acb ]
    
    The allocation failure of mycs->yuv_scaler_binary in load_video_binaries()
    is followed with a dereference of mycs->yuv_scaler_binary after the
    following call chain:
    
    sh_css_pipe_load_binaries()
      |-> load_video_binaries(mycs->yuv_scaler_binary == NULL)
      |
      |-> sh_css_pipe_unload_binaries()
            |-> unload_video_binaries()
    
    In unload_video_binaries(), it calls to ia_css_binary_unload with argument
    &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the
    same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer
    dereference is triggered.
    
    Link: https://lore.kernel.org/r/[email protected]
    
    Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: cadence: csi2rx: configure DPHY before starting source stream [+ + +]
Author: Pratyush Yadav <[email protected]>
Date:   Fri Feb 23 13:53:01 2024 +0530

    media: cadence: csi2rx: configure DPHY before starting source stream
    
    [ Upstream commit fd64dda48f7e3f67ada1e1fe47e784ab350da72e ]
    
    When the source device is operating above 1.5 Gbps per lane, it needs to
    send the Skew Calibration Sequence before sending any HS data. If the
    DPHY is initialized after the source stream is started, then it might
    miss the sequence and not be able to receive data properly. Move the
    start of source subdev to the end of the sequence to make sure
    everything is ready to receive data before the source starts streaming.
    
    Signed-off-by: Pratyush Yadav <[email protected]>
    Fixes: 3295cf1241d3 ("media: cadence: Add support for external dphy")
    Tested-by: Julien Massot <[email protected]>
    Tested-by: Changhuang Liang <[email protected]>
    Reviewed-by: Julien Massot <[email protected]>
    Reviewed-by: Changhuang Liang <[email protected]>
    Signed-off-by: Jai Luthra <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: dt-bindings: ovti,ov2680: Fix the power supply names [+ + +]
Author: Fabio Estevam <[email protected]>
Date:   Tue Apr 2 14:40:27 2024 -0300

    media: dt-bindings: ovti,ov2680: Fix the power supply names
    
    [ Upstream commit e2f6ea61b6f3e4ebbb7dff857eea6220c18cd17b ]
    
    The original .txt bindings had the OV2680 power supply names correct,
    but the transition from .txt to yaml spelled them incorrectly.
    
    Fix the OV2680 power supply names as the original .txt bindings
    as these are the names used by the OV2680 driver and in devicetree.
    
    Fixes: 57226cd8c8bf ("media: dt-bindings: ov2680: convert bindings to yaml")
    Signed-off-by: Fabio Estevam <[email protected]>
    Reviewed-by: Rob Herring <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: i2c: et8ek8: Don't strip remove function when driver is builtin [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Sun Mar 24 17:00:44 2024 +0100

    media: i2c: et8ek8: Don't strip remove function when driver is builtin
    
    [ Upstream commit 545b215736c5c4b354e182d99c578a472ac9bfce ]
    
    Using __exit for the remove function results in the remove callback
    being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets
    unbound (e.g. using sysfs or hotplug), the driver is just removed
    without the cleanup being performed. This results in resource leaks. Fix
    it by compiling in the remove callback unconditionally.
    
    This also fixes a W=1 modpost warning:
    
            WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)
    
    Fixes: c5254e72b8ed ("[media] media: Driver for Toshiba et8ek8 5MP sensor")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: ipu3-cio2: Request IRQ earlier [+ + +]
Author: Sakari Ailus <[email protected]>
Date:   Tue Dec 20 16:01:20 2022 +0200

    media: ipu3-cio2: Request IRQ earlier
    
    [ Upstream commit a069f79bfa6ec1ea0744981ea8425c8a25322579 ]
    
    Call devm_request_irq() before registering the async notifier, as otherwise
    it would be possible to use the device before the interrupts could be
    delivered to the driver.
    
    Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: ngene: Add dvb_ca_en50221_init return value check [+ + +]
Author: Aleksandr Burakov <[email protected]>
Date:   Fri Mar 1 14:15:53 2024 +0300

    media: ngene: Add dvb_ca_en50221_init return value check
    
    [ Upstream commit 9bb1fd7eddcab2d28cfc11eb20f1029154dac718 ]
    
    The return value of dvb_ca_en50221_init() is not checked here that may
    cause undefined behavior in case of nonzero value return.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 25aee3debe04 ("[media] Rename media/dvb as media/pci")
    Signed-off-by: Aleksandr Burakov <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: radio-shark2: Avoid led_names truncations [+ + +]
Author: Ricardo Ribalda <[email protected]>
Date:   Mon Mar 25 14:50:24 2024 +0000

    media: radio-shark2: Avoid led_names truncations
    
    [ Upstream commit 1820e16a3019b6258e6009d34432946a6ddd0a90 ]
    
    Increase the size of led_names so it can fit any valid v4l2 device name.
    
    Fixes:
    drivers/media/radio/radio-shark2.c:197:17: warning: ‘%s’ directive output may be truncated writing up to 35 bytes into a region of size 32 [-Wformat-truncation=]
    
    Signed-off-by: Ricardo Ribalda <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: rcar-vin: work around -Wenum-compare-conditional warning [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Mar 22 14:33:46 2024 +0100

    media: rcar-vin: work around -Wenum-compare-conditional warning
    
    [ Upstream commit 1a742c6010d136cb6c441a0f1dd2bfbfae3c4df2 ]
    
    clang-19 warns about mixing two enum types here:
    
    drivers/media/platform/renesas/rcar-vin/rcar-vin.h:296:12: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional]
    drivers/media/platform/renesas/rcar-vin/rcar-core.c:216:18: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional]
    drivers/media/platform/renesas/rcar-vin/rcar-vin.h:296:12: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional]
    drivers/media/platform/renesas/rcar-vin/rcar-vin.h:296:12: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional]
    
    This one is intentional, and there is already a cast to work around another
    warning, so address this by adding another cast.
    
    Fixes: 406bb586dec0 ("media: rcar-vin: Add r8a779a0 support")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Niklas Söderlund <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: uvcvideo: Add quirk for Logitech Rally Bar [+ + +]
Author: Ricardo Ribalda <[email protected]>
Date:   Thu Apr 4 18:00:49 2024 +0000

    media: uvcvideo: Add quirk for Logitech Rally Bar
    
    [ Upstream commit 07731053d11f7647d5d8bc23caac997a4d562dfe ]
    
    Logitech Rally Bar devices, despite behaving as UVC cameras, have a
    different power management system that the other cameras from Logitech.
    
    USB_QUIRK_RESET_RESUME is applied to all the UVC cameras from Logitech
    at the usb core. Unfortunately, USB_QUIRK_RESET_RESUME causes undesired
    USB disconnects in the Rally Bar that make them completely unusable.
    
    There is an open discussion about if we should fix this in the core or
    add a quirk in the UVC driver. In order to enable this hardware, let's
    land this patch first, and we can revert it later if there is a
    different conclusion.
    
    Fixes: e387ef5c47dd ("usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams")
    Acked-by: Greg Kroah-Hartman <[email protected]>
    Reviewed-by: Devinder Khroad <[email protected]>
    Reviewed-by: Sergey Senozhatsky <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Ricardo Ribalda <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: v4l2-subdev: Fix stream handling for crop API [+ + +]
Author: Laurent Pinchart <[email protected]>
Date:   Tue Apr 2 02:37:25 2024 +0300

    media: v4l2-subdev: Fix stream handling for crop API
    
    [ Upstream commit 34d7bf1c8e59f5fbf438ee32c96389ebe41ca2e8 ]
    
    When support for streams was added to the V4L2 subdev API, the
    v4l2_subdev_crop structure was extended with a stream field, but the
    field was not handled in the core code that translates the
    VIDIOC_SUBDEV_[GS]_CROP ioctls to the selection API. Fix it.
    
    Fixes: 2f91e10ee6fd ("media: subdev: add stream based configuration")
    Signed-off-by: Laurent Pinchart <[email protected]>
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mlx5: avoid truncating error message [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Mar 26 23:38:03 2024 +0100

    mlx5: avoid truncating error message
    
    [ Upstream commit b324a960354b872431d25959ad384ab66a7116ec ]
    
    clang warns that one error message is too long for its destination buffer:
    
    drivers/net/ethernet/mellanox/mlx5/core/esw/bridge.c:1876:4: error: 'snprintf' will always be truncated; specified size is 80, but format string expands to at least 94 [-Werror,-Wformat-truncation-non-kprintf]
    
    Reword it to be a bit shorter so it always fits.
    
    Fixes: 70f0302b3f20 ("net/mlx5: Bridge, implement mdb offload")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Subbaraya Sundeep <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mlx5: stop warning for 64KB pages [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Thu Mar 28 15:30:46 2024 +0100

    mlx5: stop warning for 64KB pages
    
    [ Upstream commit a5535e5336943b33689f558199366102387b7bbf ]
    
    When building with 64KB pages, clang points out that xsk->chunk_size
    can never be PAGE_SIZE:
    
    drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:19:22: error: result of comparison of constant 65536 with expression of type 'u16' (aka 'unsigned short') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            if (xsk->chunk_size > PAGE_SIZE ||
                ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~
    
    In older versions of this code, using PAGE_SIZE was the only
    possibility, so this would have never worked on 64KB page kernels,
    but the patch apparently did not address this case completely.
    
    As Maxim Mikityanskiy suggested, 64KB chunks are really not all that
    useful, so just shut up the warning by adding a cast.
    
    Fixes: 282c0c798f8e ("net/mlx5e: Allow XSK frames smaller than a page")
    Link: https://lore.kernel.org/netdev/[email protected]/
    Link: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: Arnd Bergmann <[email protected]>
    Acked-by: Maxim Mikityanskiy <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Reviewed-by: Tariq Toukan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mm/ksm: fix ksm exec support for prctl [+ + +]
Author: Jinjiang Tu <[email protected]>
Date:   Thu Mar 28 19:10:08 2024 +0800

    mm/ksm: fix ksm exec support for prctl
    
    [ Upstream commit 3a9e567ca45fb5280065283d10d9a11f0db61d2b ]
    
    Patch series "mm/ksm: fix ksm exec support for prctl", v4.
    
    commit 3c6f33b7273a ("mm/ksm: support fork/exec for prctl") inherits
    MMF_VM_MERGE_ANY flag when a task calls execve().  However, it doesn't
    create the mm_slot, so ksmd will not try to scan this task.  The first
    patch fixes the issue.
    
    The second patch refactors to prepare for the third patch.  The third
    patch extends the selftests of ksm to verfity the deduplication really
    happens after fork/exec inherits ths KSM setting.
    
    This patch (of 3):
    
    commit 3c6f33b7273a ("mm/ksm: support fork/exec for prctl") inherits
    MMF_VM_MERGE_ANY flag when a task calls execve().  Howerver, it doesn't
    create the mm_slot, so ksmd will not try to scan this task.
    
    To fix it, allocate and add the mm_slot to ksm_mm_head in __bprm_mm_init()
    when the mm has MMF_VM_MERGE_ANY flag.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 3c6f33b7273a ("mm/ksm: support fork/exec for prctl")
    Signed-off-by: Jinjiang Tu <[email protected]>
    Reviewed-by: David Hildenbrand <[email protected]>
    Cc: Johannes Weiner <[email protected]>
    Cc: Kefeng Wang <[email protected]>
    Cc: Nanyong Sun <[email protected]>
    Cc: Rik van Riel <[email protected]>
    Cc: Stefan Roesch <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mm/slub, kunit: Use inverted data to corrupt kmem cache [+ + +]
Author: Guenter Roeck <[email protected]>
Date:   Tue Apr 2 06:38:39 2024 -0700

    mm/slub, kunit: Use inverted data to corrupt kmem cache
    
    [ Upstream commit b1080c667b3b2c8c38a7fa83ca5567124887abae ]
    
    Two failure patterns are seen randomly when running slub_kunit tests with
    CONFIG_SLAB_FREELIST_RANDOM and CONFIG_SLAB_FREELIST_HARDENED enabled.
    
    Pattern 1:
         # test_clobber_zone: pass:1 fail:0 skip:0 total:1
         ok 1 test_clobber_zone
         # test_next_pointer: EXPECTATION FAILED at lib/slub_kunit.c:72
         Expected 3 == slab_errors, but
             slab_errors == 0 (0x0)
         # test_next_pointer: EXPECTATION FAILED at lib/slub_kunit.c:84
         Expected 2 == slab_errors, but
             slab_errors == 0 (0x0)
         # test_next_pointer: pass:0 fail:1 skip:0 total:1
         not ok 2 test_next_pointer
    
    In this case, test_next_pointer() overwrites p[s->offset], but the data
    at p[s->offset] is already 0x12.
    
    Pattern 2:
         ok 1 test_clobber_zone
         # test_next_pointer: EXPECTATION FAILED at lib/slub_kunit.c:72
         Expected 3 == slab_errors, but
             slab_errors == 2 (0x2)
         # test_next_pointer: pass:0 fail:1 skip:0 total:1
         not ok 2 test_next_pointer
    
    In this case, p[s->offset] has a value other than 0x12, but one of the
    expected failures is nevertheless missing.
    
    Invert data instead of writing a fixed value to corrupt the cache data
    structures to fix the problem.
    
    Fixes: 1f9f78b1b376 ("mm/slub, kunit: add a KUnit test for SLUB debugging functionality")
    Cc: Oliver Glitta <[email protected]>
    Cc: Vlastimil Babka <[email protected]>
    CC: Daniel Latypov <[email protected]>
    Cc: Marco Elver <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Vlastimil Babka <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mm/userfaultfd: Do not place zeropages when zeropages are disallowed [+ + +]
Author: David Hildenbrand <[email protected]>
Date:   Thu Apr 11 18:14:40 2024 +0200

    mm/userfaultfd: Do not place zeropages when zeropages are disallowed
    
    [ Upstream commit 90a7592da14951bd21f74a53246ba30955a648aa ]
    
    s390x must disable shared zeropages for processes running VMs, because
    the VMs could end up making use of "storage keys" or protected
    virtualization, which are incompatible with shared zeropages.
    
    Yet, with userfaultfd it is possible to insert shared zeropages into
    such processes. Let's fallback to simply allocating a fresh zeroed
    anonymous folio and insert that instead.
    
    mm_forbids_zeropage() was introduced in commit 593befa6ab74 ("mm: introduce
    mm_forbids_zeropage function"), briefly before userfaultfd went
    upstream.
    
    Note that we don't want to fail the UFFDIO_ZEROPAGE request like we do
    for hugetlb, it would be rather unexpected. Further, we also
    cannot really indicated "not supported" to user space ahead of time: it
    could be that the MM disallows zeropages after userfaultfd was already
    registered.
    
    [ agordeev: Fixed checkpatch complaints ]
    
    Fixes: c1a4de99fada ("userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation")
    Reviewed-by: Peter Xu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: David Hildenbrand <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
modules: Drop the .export_symbol section from the final modules [+ + +]
Author: Wang Yao <[email protected]>
Date:   Wed Apr 17 13:35:30 2024 +0800

    modules: Drop the .export_symbol section from the final modules
    
    [ Upstream commit 8fe51b45c5645c259f759479c374648e9dfeaa03 ]
    
    Commit ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost")
    forget drop the .export_symbol section from the final modules.
    
    Fixes: ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost")
    Signed-off-by: Wang Yao <[email protected]>
    Signed-off-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mptcp: avoid some duplicate code in socket option handling [+ + +]
Author: Paolo Abeni <[email protected]>
Date:   Fri Mar 1 18:43:45 2024 +0100

    mptcp: avoid some duplicate code in socket option handling
    
    [ Upstream commit a74762675f700a5473ebe54a671a0788a5b23cc9 ]
    
    The mptcp_get_int_option() helper is needless open-coded in a
    couple of places, replace the duplicate code with the helper
    call.
    
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Mat Martineau <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: bd11dc4fb969 ("mptcp: fix full TCP keep-alive support")
    Signed-off-by: Sasha Levin <[email protected]>

mptcp: cleanup SOL_TCP handling [+ + +]
Author: Paolo Abeni <[email protected]>
Date:   Fri Mar 1 18:43:47 2024 +0100

    mptcp: cleanup SOL_TCP handling
    
    [ Upstream commit 7f71a337b5152ea0e7bef408d1af53778a919316 ]
    
    Most TCP-level socket options get an integer from user space, and
    set the corresponding field under the msk-level socket lock.
    
    Reduce the code duplication moving such operations in the common code.
    
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Mat Martineau <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: bd11dc4fb969 ("mptcp: fix full TCP keep-alive support")
    Signed-off-by: Sasha Levin <[email protected]>

mptcp: cleanup writer wake-up [+ + +]
Author: Paolo Abeni <[email protected]>
Date:   Fri Mar 1 18:43:44 2024 +0100

    mptcp: cleanup writer wake-up
    
    [ Upstream commit 037db6ea57da7a134a8183dead92d64ef92babee ]
    
    After commit 5cf92bbadc58 ("mptcp: re-enable sndbuf autotune"), the
    MPTCP_NOSPACE bit is redundant: it is always set and cleared together with
    SOCK_NOSPACE.
    
    Let's drop the first and always relay on the latter, dropping a bunch
    of useless code.
    
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Mat Martineau <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: bd11dc4fb969 ("mptcp: fix full TCP keep-alive support")
    Signed-off-by: Sasha Levin <[email protected]>

mptcp: fix full TCP keep-alive support [+ + +]
Author: Matthieu Baerts (NGI0) <[email protected]>
Date:   Mon May 13 18:13:26 2024 -0700

    mptcp: fix full TCP keep-alive support
    
    [ Upstream commit bd11dc4fb969ec148e50cd87f88a78246dbc4d0b ]
    
    SO_KEEPALIVE support has been added a while ago, as part of a series
    "adding SOL_SOCKET" support. To have a full control of this keep-alive
    feature, it is important to also support TCP_KEEP* socket options at the
    SOL_TCP level.
    
    Supporting them on the setsockopt() part is easy, it is just a matter of
    remembering each value in the MPTCP sock structure, and calling
    tcp_sock_set_keep*() helpers on each subflow. If the value is not
    modified (0), calling these helpers will not do anything. For the
    getsockopt() part, the corresponding value from the MPTCP sock structure
    or the default one is simply returned. All of this is very similar to
    other TCP_* socket options supported by MPTCP.
    
    It looks important for kernels supporting SO_KEEPALIVE, to also support
    TCP_KEEP* options as well: some apps seem to (wrongly) consider that if
    the former is supported, the latter ones will be supported as well. But
    also, not having this simple and isolated change is preventing MPTCP
    support in some apps, and libraries like GoLang [1]. This is why this
    patch is seen as a fix.
    
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/383
    Fixes: 1b3e7ede1365 ("mptcp: setsockopt: handle SO_KEEPALIVE and SO_PRIORITY")
    Link: https://github.com/golang/go/issues/56539 [1]
    Acked-by: Paolo Abeni <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Mat Martineau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mptcp: implement TCP_NOTSENT_LOWAT support [+ + +]
Author: Paolo Abeni <[email protected]>
Date:   Fri Mar 1 18:43:46 2024 +0100

    mptcp: implement TCP_NOTSENT_LOWAT support
    
    [ Upstream commit 29b5e5ef87397963ca38d3eec0d296ad1c979bbc ]
    
    Add support for such socket option storing the user-space provided
    value in a new msk field, and using such data to implement the
    _mptcp_stream_memory_free() helper, similar to the TCP one.
    
    To avoid adding more indirect calls in the fast path, open-code
    a variant of sk_stream_memory_free() in mptcp_sendmsg() and add
    direct calls to the mptcp stream memory free helper where possible.
    
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/464
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Mat Martineau <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: bd11dc4fb969 ("mptcp: fix full TCP keep-alive support")
    Signed-off-by: Sasha Levin <[email protected]>

mptcp: SO_KEEPALIVE: fix getsockopt support [+ + +]
Author: Matthieu Baerts (NGI0) <[email protected]>
Date:   Mon May 13 18:13:25 2024 -0700

    mptcp: SO_KEEPALIVE: fix getsockopt support
    
    [ Upstream commit a65198136eaa15b74ee0abf73f12ef83d469a334 ]
    
    SO_KEEPALIVE support has to be set on each subflow: on each TCP socket,
    where sk_prot->keepalive is defined. Technically, nothing has to be done
    on the MPTCP socket. That's why mptcp_sol_socket_sync_intval() was
    called instead of mptcp_sol_socket_intval().
    
    Except that when nothing is done on the MPTCP socket, the
    getsockopt(SO_KEEPALIVE), handled in net/core/sock.c:sk_getsockopt(),
    will not know if SO_KEEPALIVE has been set on the different subflows or
    not.
    
    The fix is simple: simply call mptcp_sol_socket_intval() which will end
    up calling net/core/sock.c:sk_setsockopt() where the SOCK_KEEPOPEN flag
    will be set, the one used in sk_getsockopt().
    
    So now, getsockopt(SO_KEEPALIVE) on an MPTCP socket will return the same
    value as the one previously set with setsockopt(SO_KEEPALIVE).
    
    Fixes: 1b3e7ede1365 ("mptcp: setsockopt: handle SO_KEEPALIVE and SO_PRIORITY")
    Acked-by: Paolo Abeni <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Mat Martineau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mtd: core: Report error if first mtd_otp_size() call fails in mtd_otp_nvmem_add() [+ + +]
Author: Aapo Vienamo <[email protected]>
Date:   Wed Mar 13 19:34:24 2024 +0200

    mtd: core: Report error if first mtd_otp_size() call fails in mtd_otp_nvmem_add()
    
    [ Upstream commit d44f0bbbd8d182debcce88bda55b05269f3d33d6 ]
    
    Jump to the error reporting code in mtd_otp_nvmem_add() if the
    mtd_otp_size() call fails. Without this fix, the error is not logged.
    
    Signed-off-by: Aapo Vienamo <[email protected]>
    Reviewed-by: Mika Westerberg <[email protected]>
    Reviewed-by: Michael Walle <[email protected]>
    Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support")
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

mtd: rawnand: hynix: fixed typo [+ + +]
Author: Maxim Korotkov <[email protected]>
Date:   Wed Mar 13 13:27:20 2024 +0300

    mtd: rawnand: hynix: fixed typo
    
    [ Upstream commit 6819db94e1cd3ce24a432f3616cd563ed0c4eaba ]
    
    The function hynix_nand_rr_init() should probably return an error code.
    Judging by the usage, it seems that the return code is passed up
    the call stack.
    Right now, it always returns 0 and the function hynix_nand_cleanup()
    in hynix_nand_init() has never been called.
    
    Found by RASU JSC and Linux Verification Center (linuxtesting.org)
    
    Fixes: 626994e07480 ("mtd: nand: hynix: Add read-retry support for 1x nm MLC NANDs")
    
    Signed-off-by: Maxim Korotkov <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
net/mlx5: Add a timeout to acquire the command queue semaphore [+ + +]
Author: Akiva Goldberger <[email protected]>
Date:   Thu May 9 14:29:50 2024 +0300

    net/mlx5: Add a timeout to acquire the command queue semaphore
    
    [ Upstream commit 485d65e1357123a697c591a5aeb773994b247ad7 ]
    
    Prevent forced completion handling on an entry that has not yet been
    assigned an index, causing an out of bounds access on idx = -22.
    Instead of waiting indefinitely for the sem, blocking flow now waits for
    index to be allocated or a sem acquisition timeout before beginning the
    timer for FW completion.
    
    Kernel log example:
    mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion
    
    Fixes: 8e715cd613a1 ("net/mlx5: Set command entry semaphore up once got index free")
    Signed-off-by: Akiva Goldberger <[email protected]>
    Reviewed-by: Moshe Shemesh <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5: Discard command completions in internal error [+ + +]
Author: Akiva Goldberger <[email protected]>
Date:   Thu May 9 14:29:51 2024 +0300

    net/mlx5: Discard command completions in internal error
    
    [ Upstream commit db9b31aa9bc56ff0d15b78f7e827d61c4a096e40 ]
    
    Fix use after free when FW completion arrives while device is in
    internal error state. Avoid calling completion handler in this case,
    since the device will flush the command interface and trigger all
    completions manually.
    
    Kernel log:
    ------------[ cut here ]------------
    refcount_t: underflow; use-after-free.
    ...
    RIP: 0010:refcount_warn_saturate+0xd8/0xe0
    ...
    Call Trace:
    <IRQ>
    ? __warn+0x79/0x120
    ? refcount_warn_saturate+0xd8/0xe0
    ? report_bug+0x17c/0x190
    ? handle_bug+0x3c/0x60
    ? exc_invalid_op+0x14/0x70
    ? asm_exc_invalid_op+0x16/0x20
    ? refcount_warn_saturate+0xd8/0xe0
    cmd_ent_put+0x13b/0x160 [mlx5_core]
    mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]
    cmd_comp_notifier+0x1f/0x30 [mlx5_core]
    notifier_call_chain+0x35/0xb0
    atomic_notifier_call_chain+0x16/0x20
    mlx5_eq_async_int+0xf6/0x290 [mlx5_core]
    notifier_call_chain+0x35/0xb0
    atomic_notifier_call_chain+0x16/0x20
    irq_int_handler+0x19/0x30 [mlx5_core]
    __handle_irq_event_percpu+0x4b/0x160
    handle_irq_event+0x2e/0x80
    handle_edge_irq+0x98/0x230
    __common_interrupt+0x3b/0xa0
    common_interrupt+0x7b/0xa0
    </IRQ>
    <TASK>
    asm_common_interrupt+0x22/0x40
    
    Fixes: 51d138c2610a ("net/mlx5: Fix health error state handling")
    Signed-off-by: Akiva Goldberger <[email protected]>
    Reviewed-by: Moshe Shemesh <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5: Fix peer devlink set for SF representor devlink port [+ + +]
Author: Shay Drory <[email protected]>
Date:   Thu May 9 14:29:48 2024 +0300

    net/mlx5: Fix peer devlink set for SF representor devlink port
    
    [ Upstream commit 3c453e8cc672de1f9c662948dba43176bc68d7f0 ]
    
    The cited patch change register devlink flow, and neglect to reflect
    the changes for peer devlink set logic. Peer devlink set is
    triggering a call trace if done after devl_register.[1]
    
    Hence, align peer devlink set logic with register devlink flow.
    
    [1]
    WARNING: CPU: 4 PID: 3394 at net/devlink/core.c:155 devlink_rel_nested_in_add+0x177/0x180
    CPU: 4 PID: 3394 Comm: kworker/u40:1 Not tainted 6.9.0-rc4_for_linust_min_debug_2024_04_16_14_08 #1
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    Workqueue: mlx5_vhca_event0 mlx5_vhca_state_work_handler [mlx5_core]
    RIP: 0010:devlink_rel_nested_in_add+0x177/0x180
    Call Trace:
     <TASK>
     ? __warn+0x78/0x120
     ? devlink_rel_nested_in_add+0x177/0x180
     ? report_bug+0x16d/0x180
     ? handle_bug+0x3c/0x60
     ? exc_invalid_op+0x14/0x70
     ? asm_exc_invalid_op+0x16/0x20
     ? devlink_port_init+0x30/0x30
     ? devlink_port_type_clear+0x50/0x50
     ? devlink_rel_nested_in_add+0x177/0x180
     ? devlink_rel_nested_in_add+0xdd/0x180
     mlx5_sf_mdev_event+0x74/0xb0 [mlx5_core]
     notifier_call_chain+0x35/0xb0
     blocking_notifier_call_chain+0x3d/0x60
     mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]
     mlx5_sf_dev_probe+0x185/0x3e0 [mlx5_core]
     auxiliary_bus_probe+0x38/0x80
     ? driver_sysfs_add+0x51/0x80
     really_probe+0xc5/0x3a0
     ? driver_probe_device+0x90/0x90
     __driver_probe_device+0x80/0x160
     driver_probe_device+0x1e/0x90
     __device_attach_driver+0x7d/0x100
     bus_for_each_drv+0x80/0xd0
     __device_attach+0xbc/0x1f0
     bus_probe_device+0x86/0xa0
     device_add+0x64f/0x860
     __auxiliary_device_add+0x3b/0xa0
     mlx5_sf_dev_add+0x139/0x330 [mlx5_core]
     mlx5_sf_dev_state_change_handler+0x1e4/0x250 [mlx5_core]
     notifier_call_chain+0x35/0xb0
     blocking_notifier_call_chain+0x3d/0x60
     mlx5_vhca_state_work_handler+0x151/0x200 [mlx5_core]
     process_one_work+0x13f/0x2e0
     worker_thread+0x2bd/0x3c0
     ? rescuer_thread+0x410/0x410
     kthread+0xc4/0xf0
     ? kthread_complete_and_exit+0x20/0x20
     ret_from_fork+0x2d/0x50
     ? kthread_complete_and_exit+0x20/0x20
     ret_from_fork_asm+0x11/0x20
     </TASK>
    
    Fixes: bf729988303a ("net/mlx5: Restore mistakenly dropped parts in register devlink flow")
    Fixes: c6e77aa9dd82 ("net/mlx5: Register devlink first under devlink lock")
    Signed-off-by: Shay Drory <[email protected]>
    Reviewed-by: Moshe Shemesh <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5: Reload only IB representors upon lag disable/enable [+ + +]
Author: Maher Sanalla <[email protected]>
Date:   Thu May 9 14:29:49 2024 +0300

    net/mlx5: Reload only IB representors upon lag disable/enable
    
    [ Upstream commit 0f06228d4a2dcc1fca5b3ddb0eefa09c05b102c4 ]
    
    On lag disable, the bond IB device along with all of its
    representors are destroyed, and then the slaves' representors get reloaded.
    
    In case the slave IB representor load fails, the eswitch error flow
    unloads all representors, including ethernet representors, where the
    netdevs get detached and removed from lag bond. Such flow is inaccurate
    as the lag driver is not responsible for loading/unloading ethernet
    representors. Furthermore, the flow described above begins by holding
    lag lock to prevent bond changes during disable flow. However, when
    reaching the ethernet representors detachment from lag, the lag lock is
    required again, triggering the following deadlock:
    
    Call trace:
    __switch_to+0xf4/0x148
    __schedule+0x2c8/0x7d0
    schedule+0x50/0xe0
    schedule_preempt_disabled+0x18/0x28
    __mutex_lock.isra.13+0x2b8/0x570
    __mutex_lock_slowpath+0x1c/0x28
    mutex_lock+0x4c/0x68
    mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core]
    mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core]
    mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core]
    mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core]
    mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core]
    mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core]
    mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core]
    mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core]
    mlx5_disable_lag+0x130/0x138 [mlx5_core]
    mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev->lock
    mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core]
    devlink_nl_cmd_eswitch_set_doit+0xdc/0x180
    genl_family_rcv_msg_doit.isra.17+0xe8/0x138
    genl_rcv_msg+0xe4/0x220
    netlink_rcv_skb+0x44/0x108
    genl_rcv+0x40/0x58
    netlink_unicast+0x198/0x268
    netlink_sendmsg+0x1d4/0x418
    sock_sendmsg+0x54/0x60
    __sys_sendto+0xf4/0x120
    __arm64_sys_sendto+0x30/0x40
    el0_svc_common+0x8c/0x120
    do_el0_svc+0x30/0xa0
    el0_svc+0x20/0x30
    el0_sync_handler+0x90/0xb8
    el0_sync+0x160/0x180
    
    Thus, upon lag enable/disable, load and unload only the IB representors
    of the slaves preventing the deadlock mentioned above.
    
    While at it, refactor the mlx5_esw_offloads_rep_load() function to have
    a static helper method for its internal logic, in symmetry with the
    representor unload design.
    
    Fixes: 598fe77df855 ("net/mlx5: Lag, Create shared FDB when in switchdev mode")
    Co-developed-by: Mark Bloch <[email protected]>
    Signed-off-by: Mark Bloch <[email protected]>
    Signed-off-by: Maher Sanalla <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: bridge: mst: fix vlan use-after-free [+ + +]
Author: Nikolay Aleksandrov <[email protected]>
Date:   Mon May 13 14:06:27 2024 +0300

    net: bridge: mst: fix vlan use-after-free
    
    [ Upstream commit 3a7c1661ae1383364cd6092d851f5e5da64d476b ]
    
    syzbot reported a suspicious rcu usage[1] in bridge's mst code. While
    fixing it I noticed that nothing prevents a vlan to be freed while
    walking the list from the same path (br forward delay timer). Fix the rcu
    usage and also make sure we are not accessing freed memory by making
    br_mst_vlan_set_state use rcu read lock.
    
    [1]
     WARNING: suspicious RCU usage
     6.9.0-rc6-syzkaller #0 Not tainted
     -----------------------------
     net/bridge/br_private.h:1599 suspicious rcu_dereference_protected() usage!
     ...
     stack backtrace:
     CPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0
     Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
     Call Trace:
      <IRQ>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
      lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712
      nbp_vlan_group net/bridge/br_private.h:1599 [inline]
      br_mst_set_state+0x1ea/0x650 net/bridge/br_mst.c:105
      br_set_state+0x28a/0x7b0 net/bridge/br_stp.c:47
      br_forward_delay_timer_expired+0x176/0x440 net/bridge/br_stp_timer.c:88
      call_timer_fn+0x18e/0x650 kernel/time/timer.c:1793
      expire_timers kernel/time/timer.c:1844 [inline]
      __run_timers kernel/time/timer.c:2418 [inline]
      __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2429
      run_timer_base kernel/time/timer.c:2438 [inline]
      run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2448
      __do_softirq+0x2c6/0x980 kernel/softirq.c:554
      invoke_softirq kernel/softirq.c:428 [inline]
      __irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633
      irq_exit_rcu+0x9/0x30 kernel/softirq.c:645
      instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
      sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
      </IRQ>
      <TASK>
     asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
     RIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep.c:5758
     Code: 2b 00 74 08 4c 89 f7 e8 ba d1 84 00 f6 44 24 61 02 0f 85 85 01 00 00 41 f7 c7 00 02 00 00 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 25 00 00 00 00 00 43 c7 44 25 09 00 00 00 00 43 c7 44 25
     RSP: 0018:ffffc90013657100 EFLAGS: 00000206
     RAX: 0000000000000001 RBX: 1ffff920026cae2c RCX: 0000000000000001
     RDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60
     RBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0
     R10: dffffc0000000000 R11: fffffbfff25dfca1 R12: 1ffff920026cae28
     R13: dffffc0000000000 R14: ffffc90013657160 R15: 0000000000000246
    
    Fixes: ec7328b59176 ("net: bridge: mst: Multiple Spanning Tree (MST) mode")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=fa04eb8a56fd923fc5d8
    Signed-off-by: Nikolay Aleksandrov <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: bridge: xmit: make sure we have at least eth header len bytes [+ + +]
Author: Nikolay Aleksandrov <[email protected]>
Date:   Mon May 13 13:34:19 2024 +0300

    net: bridge: xmit: make sure we have at least eth header len bytes
    
    [ Upstream commit 8bd67ebb50c0145fd2ca8681ab65eb7e8cde1afc ]
    
    syzbot triggered an uninit value[1] error in bridge device's xmit path
    by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
    we can actually pull that amount instead of assuming.
    
    Tested with dropwatch:
     drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
     origin: software
     timestamp: Mon May 13 11:31:53 2024 778214037 nsec
     protocol: 0x88a8
     length: 2
     original length: 2
     drop reason: PKT_TOO_SMALL
    
    [1]
    BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
     br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
     __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
     netdev_start_xmit include/linux/netdevice.h:4917 [inline]
     xmit_one net/core/dev.c:3531 [inline]
     dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
     __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
     dev_queue_xmit include/linux/netdevice.h:3091 [inline]
     __bpf_tx_skb net/core/filter.c:2136 [inline]
     __bpf_redirect_common net/core/filter.c:2180 [inline]
     __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
     ____bpf_clone_redirect net/core/filter.c:2460 [inline]
     bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
     ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
     __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
     bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
     __bpf_prog_run include/linux/filter.h:657 [inline]
     bpf_prog_run include/linux/filter.h:664 [inline]
     bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
     bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
     bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
     __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
     __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
     __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
     __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
     x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=a63a1f6a062033cf0f40
    Signed-off-by: Nikolay Aleksandrov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mv88e6xxx: Add support for model-specific pre- and post-reset handlers [+ + +]
Author: Matthias Schiffer <[email protected]>
Date:   Tue Apr 23 09:47:48 2024 +0200

    net: dsa: mv88e6xxx: Add support for model-specific pre- and post-reset handlers
    
    [ Upstream commit 0fdd27b9d6d7c60bd319d3497ad797934bab13cb ]
    
    Instead of calling mv88e6xxx_g2_eeprom_wait() directly from
    mv88e6xxx_hardware_reset(), add configurable pre- and post-reset hard
    reset handlers. Initially, the handlers are set to
    mv88e6xxx_g2_eeprom_wait() for all families that have get/set_eeprom()
    to match the existing behavior. No functional change intended (except
    for additional error messages on failure).
    
    Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent")
    Signed-off-by: Matthias Schiffer <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches [+ + +]
Author: Matthias Schiffer <[email protected]>
Date:   Tue Apr 23 09:47:49 2024 +0200

    net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
    
    [ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
    
    88E6250-family switches have the quirk that the EEPROM Running flag can
    get stuck at 1 when no EEPROM is connected, causing
    mv88e6xxx_g2_eeprom_wait() to time out. We still want to wait for the
    EEPROM however, to avoid interrupting a transfer and leaving the EEPROM
    in an invalid state.
    
    The condition to wait for recommended by the hardware spec is the EEInt
    flag, however this flag is cleared on read, so before the hardware reset,
    is may have been cleared already even though the EEPROM has been read
    successfully.
    
    For this reason, we revive the mv88e6xxx_g1_wait_eeprom_done() function
    that was removed in commit 6ccf50d4d474
    ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") in a
    slightly refactored form, and introduce a new
    mv88e6xxx_g1_wait_eeprom_done_prereset() that additionally handles this
    case by triggering another EEPROM reload that can be waited on.
    
    On other switch models without this quirk, mv88e6xxx_g2_eeprom_wait() is
    kept, as it avoids the additional reload.
    
    Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent")
    Signed-off-by: Matthias Schiffer <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: cortina: Locking fixes [+ + +]
Author: Linus Walleij <[email protected]>
Date:   Thu May 9 09:44:54 2024 +0200

    net: ethernet: cortina: Locking fixes
    
    [ Upstream commit 812552808f7ff71133fc59768cdc253c5b8ca1bf ]
    
    This fixes a probably long standing problem in the Cortina
    Gemini ethernet driver: there are some paths in the code
    where the IRQ registers are written without taking the proper
    locks.
    
    Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet")
    Signed-off-by: Linus Walleij <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: mediatek: split tx and rx fields in mtk_soc_data struct [+ + +]
Author: Lorenzo Bianconi <[email protected]>
Date:   Wed May 8 11:43:34 2024 +0100

    net: ethernet: mediatek: split tx and rx fields in mtk_soc_data struct
    
    [ Upstream commit ecb51fa37ee22f137a87fa140b1e9f1759949f9a ]
    
    Split tx and rx fields in mtk_soc_data struct. This is a preliminary
    patch to roll back to ADMAv1 for MT7986 and MT7981 SoC in order to fix a
    hw hang if the device receives a corrupted packet when using ADMAv2.0.
    
    Fixes: 197c9e9b17b1 ("net: ethernet: mtk_eth_soc: introduce support for mt7986 chipset")
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Signed-off-by: Daniel Golle <[email protected]>
    Reviewed-by: Przemek Kitszel <[email protected]>
    Link: https://lore.kernel.org/r/70a799b1f060ec2f57883e88ccb420ac0fb0abb5.1715164770.git.daniel@makrotopia.org
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: mediatek: use ADMAv1 instead of ADMAv2.0 on MT7981 and MT7986 [+ + +]
Author: Daniel Golle <[email protected]>
Date:   Wed May 8 11:43:56 2024 +0100

    net: ethernet: mediatek: use ADMAv1 instead of ADMAv2.0 on MT7981 and MT7986
    
    [ Upstream commit 5e69ff84f3e6cc54502a902043847b37ed78afd4 ]
    
    ADMAv2.0 is plagued by RX hangs which can't easily detected and happen upon
    receival of a corrupted Ethernet frame.
    
    Use ADMAv1 instead which is also still present and usable, and doesn't
    suffer from that problem.
    
    Fixes: 197c9e9b17b1 ("net: ethernet: mtk_eth_soc: introduce support for mt7986 chipset")
    Co-developed-by: Lorenzo Bianconi <[email protected]>
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Signed-off-by: Daniel Golle <[email protected]>
    Link: https://lore.kernel.org/r/57cef74bbd0c243366ad1ff4221e3f72f437ec80.1715164770.git.daniel@makrotopia.org
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: fec: remove .ndo_poll_controller to avoid deadlocks [+ + +]
Author: Wei Fang <[email protected]>
Date:   Sat May 11 14:20:09 2024 +0800

    net: fec: remove .ndo_poll_controller to avoid deadlocks
    
    [ Upstream commit c2e0c58b25a0a0c37ec643255558c5af4450c9f5 ]
    
    There is a deadlock issue found in sungem driver, please refer to the
    commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid
    deadlocks"). The root cause of the issue is that netpoll is in atomic
    context and disable_irq() is called by .ndo_poll_controller interface
    of sungem driver, however, disable_irq() might sleep. After analyzing
    the implementation of fec_poll_controller(), the fec driver should have
    the same issue. Due to the fec driver uses NAPI for TX completions, the
    .ndo_poll_controller is unnecessary to be implemented in the fec driver,
    so fec_poll_controller() can be safely removed.
    
    Fixes: 7f5c6addcdc0 ("net/fec: add poll controller function for fec nic")
    Signed-off-by: Wei Fang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: give more chances to rcu in netdev_wait_allrefs_any() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Apr 26 06:42:22 2024 +0000

    net: give more chances to rcu in netdev_wait_allrefs_any()
    
    [ Upstream commit cd42ba1c8ac9deb9032add6adf491110e7442040 ]
    
    This came while reviewing commit c4e86b4363ac ("net: add two more
    call_rcu_hurry()").
    
    Paolo asked if adding one synchronize_rcu() would help.
    
    While synchronize_rcu() does not help, making sure to call
    rcu_barrier() before msleep(wait) is definitely helping
    to make sure lazy call_rcu() are completed.
    
    Instead of waiting ~100 seconds in my tests, the ref_tracker
    splats occurs one time only, and netdev_wait_allrefs_any()
    latency is reduced to the strict minimum.
    
    Ideally we should audit our call_rcu() users to make sure
    no refcount (or cascading call_rcu()) is held too long,
    because rcu_barrier() is quite expensive.
    
    Fixes: 0e4be9e57e8c ("net: use exponential backoff in netdev_wait_allrefs")
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/T/#m76d73ed6b03cd930778ac4d20a777f22a08d6824
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ipv6: fix wrong start position when receive hop-by-hop fragment [+ + +]
Author: gaoxingwang <[email protected]>
Date:   Mon Apr 22 17:19:17 2024 +0800

    net: ipv6: fix wrong start position when receive hop-by-hop fragment
    
    [ Upstream commit 1cd354fe1e4864eeaff62f66ee513080ec946f20 ]
    
    In IPv6, ipv6_rcv_core will parse the hop-by-hop type extension header and increase skb->transport_header by one extension header length.
    But if there are more other extension headers like fragment header at this time, the skb->transport_header points to the second extension header,
    not the transport layer header or the first extension header.
    
    This will result in the start and nexthdrp variable not pointing to the same position in ipv6frag_thdr_trunced,
    and ipv6_skip_exthdr returning incorrect offset and frag_off.Sometimes,the length of the last sharded packet is smaller than the calculated incorrect offset, resulting in packet loss.
    We can use network header to offset and calculate the correct position to solve this problem.
    
    Fixes: 9d9e937b1c8b (ipv6/netfilter: Discard first fragment not including all headers)
    Signed-off-by: Gao Xingwang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: lan966x: remove debugfs directory in probe() error path [+ + +]
Author: Herve Codina <[email protected]>
Date:   Mon May 13 13:18:53 2024 +0200

    net: lan966x: remove debugfs directory in probe() error path
    
    commit 99975ad644c7836414183fa7be4f883a4fb2bf64 upstream.
    
    A debugfs directory entry is create early during probe(). This entry is
    not removed on error path leading to some "already present" issues in
    case of EPROBE_DEFER.
    
    Create this entry later in the probe() code to avoid the need to change
    many 'return' in 'goto' and add the removal in the already present error
    path.
    
    Fixes: 942814840127 ("net: lan966x: Add VCAP debugFS support")
    Cc: <[email protected]>
    Signed-off-by: Herve Codina <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Reviewed-by: Horatiu Vultur <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: mana: Fix the extra HZ in mana_hwc_send_request [+ + +]
Author: Souradeep Chakrabarti <[email protected]>
Date:   Sun May 19 23:05:04 2024 -0700

    net: mana: Fix the extra HZ in mana_hwc_send_request
    
    commit 9c91c7fadb1771dcc2815c5271d14566366d05c5 upstream.
    
    Commit 62c1bff593b7 added an extra HZ along with msecs_to_jiffies.
    This patch fixes that.
    
    Cc: [email protected]
    Fixes: 62c1bff593b7 ("net: mana: Configure hwc timeout from hardware")
    Signed-off-by: Souradeep Chakrabarti <[email protected]>
    Reviewed-by: Brett Creeley <[email protected]>
    Reviewed-by: Dexuan Cui <[email protected]>
    Link: https://lore.kernel.org/r/1716185104-31658-1-git-send-email-schakrabarti@linux.microsoft.com
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: micrel: Fix receiving the timestamp in the frame for lan8841 [+ + +]
Author: Horatiu Vultur <[email protected]>
Date:   Mon May 13 21:21:57 2024 +0200

    net: micrel: Fix receiving the timestamp in the frame for lan8841
    
    [ Upstream commit aea27a92a41dae14843f92c79e9e42d8f570105c ]
    
    The blamed commit started to use the ptp workqueue to get the second
    part of the timestamp. And when the port was set down, then this
    workqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING
    is not enabled, then the ptp_clock is not initialized so then it would
    crash when it would try to access the delayed work.
    So then basically by setting up and then down the port, it would crash.
    The fix consists in checking if the ptp_clock is initialized and only
    then cancel the delayed work.
    
    Fixes: cc7554954848 ("net: micrel: Change to receive timestamp in the frame for lan8841")
    Signed-off-by: Horatiu Vultur <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: openvswitch: fix overwriting ct original tuple for ICMPv6 [+ + +]
Author: Ilya Maximets <[email protected]>
Date:   Thu May 9 11:38:05 2024 +0200

    net: openvswitch: fix overwriting ct original tuple for ICMPv6
    
    [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ]
    
    OVS_PACKET_CMD_EXECUTE has 3 main attributes:
     - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.
     - OVS_PACKET_ATTR_PACKET - Binary packet content.
     - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.
    
    OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure
    with the metadata like conntrack state, input port, recirculation id,
    etc.  Then the packet itself gets parsed to populate the rest of the
    keys from the packet headers.
    
    Whenever the packet parsing code starts parsing the ICMPv6 header, it
    first zeroes out fields in the key corresponding to Neighbor Discovery
    information even if it is not an ND packet.
    
    It is an 'ipv6.nd' field.  However, the 'ipv6' is a union that shares
    the space between 'nd' and 'ct_orig' that holds the original tuple
    conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.
    
    ND packets should not normally have conntrack state, so it's fine to
    share the space, but normal ICMPv6 Echo packets or maybe other types of
    ICMPv6 can have the state attached and it should not be overwritten.
    
    The issue results in all but the last 4 bytes of the destination
    address being wiped from the original conntrack tuple leading to
    incorrect packet matching and potentially executing wrong actions
    in case this packet recirculates within the datapath or goes back
    to userspace.
    
    ND fields should not be accessed in non-ND packets, so not clearing
    them should be fine.  Executing memset() only for actual ND packets to
    avoid the issue.
    
    Initializing the whole thing before parsing is needed because ND packet
    may not contain all the options.
    
    The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't
    affect packets entering OVS datapath from network interfaces, because
    in this case CT metadata is populated from skb after the packet is
    already parsed.
    
    Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.")
    Reported-by: Antonin Bas <[email protected]>
    Closes: https://github.com/openvswitch/ovs-issues/issues/327
    Signed-off-by: Ilya Maximets <[email protected]>
    Acked-by: Aaron Conole <[email protected]>
    Acked-by: Eelco Chaudron <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: qrtr: ns: Fix module refcnt [+ + +]
Author: Chris Lew <[email protected]>
Date:   Mon May 13 10:31:46 2024 -0700

    net: qrtr: ns: Fix module refcnt
    
    [ Upstream commit fd76e5ccc48f9f54eb44909dd7c0b924005f1582 ]
    
    The qrtr protocol core logic and the qrtr nameservice are combined into
    a single module. Neither the core logic or nameservice provide much
    functionality by themselves; combining the two into a single module also
    prevents any possible issues that may stem from client modules loading
    inbetween qrtr and the ns.
    
    Creating a socket takes two references to the module that owns the
    socket protocol. Since the ns needs to create the control socket, this
    creates a scenario where there are always two references to the qrtr
    module. This prevents the execution of 'rmmod' for qrtr.
    
    To resolve this, forcefully put the module refcount for the socket
    opened by the nameservice.
    
    Fixes: a365023a76f2 ("net: qrtr: combine nameservice into main module")
    Reported-by: Jeffrey Hugo <[email protected]>
    Tested-by: Jeffrey Hugo <[email protected]>
    Signed-off-by: Chris Lew <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Jeffrey Hugo <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: smc91x: Fix m68k kernel compilation for ColdFire CPU [+ + +]
Author: Thorsten Blum <[email protected]>
Date:   Fri May 10 13:30:55 2024 +0200

    net: smc91x: Fix m68k kernel compilation for ColdFire CPU
    
    commit 5eefb477d21a26183bc3499aeefa991198315a2d upstream.
    
    Compiling the m68k kernel with support for the ColdFire CPU family fails
    with the following error:
    
    In file included from drivers/net/ethernet/smsc/smc91x.c:80:
    drivers/net/ethernet/smsc/smc91x.c: In function ‘smc_reset’:
    drivers/net/ethernet/smsc/smc91x.h:160:40: error: implicit declaration of function ‘_swapw’; did you mean ‘swap’? [-Werror=implicit-function-declaration]
      160 | #define SMC_outw(lp, v, a, r)   writew(_swapw(v), (a) + (r))
          |                                        ^~~~~~
    drivers/net/ethernet/smsc/smc91x.h:904:25: note: in expansion of macro ‘SMC_outw’
      904 |                         SMC_outw(lp, x, ioaddr, BANK_SELECT);           \
          |                         ^~~~~~~~
    drivers/net/ethernet/smsc/smc91x.c:250:9: note: in expansion of macro ‘SMC_SELECT_BANK’
      250 |         SMC_SELECT_BANK(lp, 2);
          |         ^~~~~~~~~~~~~~~
    cc1: some warnings being treated as errors
    
    The function _swapw() was removed in commit d97cf70af097 ("m68k: use
    asm-generic/io.h for non-MMU io access functions"), but is still used in
    drivers/net/ethernet/smsc/smc91x.h.
    
    Use ioread16be() and iowrite16be() to resolve the error.
    
    Cc: [email protected]
    Fixes: d97cf70af097 ("m68k: use asm-generic/io.h for non-MMU io access functions")
    Signed-off-by: Thorsten Blum <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: stmmac: est: Per Tx-queue error count for HLBF [+ + +]
Author: Rohan G Thomas <[email protected]>
Date:   Sat Jan 27 12:04:42 2024 +0800

    net: stmmac: est: Per Tx-queue error count for HLBF
    
    [ Upstream commit fd5a6a71313e27c4f601526081b69d4e76f03dea ]
    
    Keep per Tx-queue error count on Head-Of-Line Blocking due to frame
    size(HLBF) error. The MAC raises HLBF error on one or more queues
    when none of the time Intervals of open-gates in the GCL is greater
    than or equal to the duration needed for frame transmission and by
    default drops those packets that causes HLBF error. EST_FRM_SZ_ERR
    register provides the One Hot encoded Queue numbers that have the
    Frame Size related error.
    
    Signed-off-by: Rohan G Thomas <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 36ac9e7f2e57 ("net: stmmac: move the EST lock to struct stmmac_priv")
    Signed-off-by: Sasha Levin <[email protected]>

net: stmmac: move the EST lock to struct stmmac_priv [+ + +]
Author: Xiaolei Wang <[email protected]>
Date:   Mon May 13 09:43:45 2024 +0800

    net: stmmac: move the EST lock to struct stmmac_priv
    
    [ Upstream commit 36ac9e7f2e5786bd37c5cd91132e1f39c29b8197 ]
    
    Reinitialize the whole EST structure would also reset the mutex
    lock which is embedded in the EST structure, and then trigger
    the following warning. To address this, move the lock to struct
    stmmac_priv. We also need to reacquire the mutex lock when doing
    this initialization.
    
    DEBUG_LOCKS_WARN_ON(lock->magic != lock)
    WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068
     Modules linked in:
     CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29
     Hardware name: NXP i.MX8MPlus EVK board (DT)
     pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : __mutex_lock+0xd84/0x1068
     lr : __mutex_lock+0xd84/0x1068
     sp : ffffffc0864e3570
     x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003
     x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac
     x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000
     x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff
     x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000
     x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8
     x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698
     x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001
     x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027
     x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000
     Call trace:
      __mutex_lock+0xd84/0x1068
      mutex_lock_nested+0x28/0x34
      tc_setup_taprio+0x118/0x68c
      stmmac_setup_tc+0x50/0xf0
      taprio_change+0x868/0xc9c
    
    Fixes: b2aae654a479 ("net: stmmac: add mutex lock to protect est parameters")
    Signed-off-by: Xiaolei Wang <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Serge Semin <[email protected]>
    Reviewed-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: stmmac: Offload queueMaxSDU from tc-taprio [+ + +]
Author: Rohan G Thomas <[email protected]>
Date:   Sat Jan 27 12:04:41 2024 +0800

    net: stmmac: Offload queueMaxSDU from tc-taprio
    
    [ Upstream commit c5c3e1bfc9e0ee72af528df8d773980f4855938a ]
    
    Add support for configuring queueMaxSDU. As DWMAC IPs doesn't support
    queueMaxSDU table handle this in the SW. The maximum 802.3 frame size
    that is allowed to be transmitted by any queue is queueMaxSDU +
    16 bytes (i.e. 6 bytes SA + 6 bytes DA + 4 bytes FCS).
    
    Inspired from intel i225 driver.
    
    Signed-off-by: Rohan G Thomas <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 36ac9e7f2e57 ("net: stmmac: move the EST lock to struct stmmac_priv")
    Signed-off-by: Sasha Levin <[email protected]>

net: stmmac: Report taprio offload status [+ + +]
Author: Rohan G Thomas <[email protected]>
Date:   Sat Jan 27 12:04:43 2024 +0800

    net: stmmac: Report taprio offload status
    
    [ Upstream commit 5ca63ffdb94ba2bac4c23c8609aabd7edd03c312 ]
    
    Report taprio offload status. This includes per txq and global
    counters of window_drops and tx_overruns.
    
    Window_drops count include count of frames dropped because of
    queueMaxSDU setting and HLBF error. Transmission overrun counter
    inform the user application whether any packets are currently being
    transmitted on a particular queue during a gate-close event.DWMAC IPs
    takes care Transmission overrun won't happen hence this is always 0.
    
    Signed-off-by: Rohan G Thomas <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 36ac9e7f2e57 ("net: stmmac: move the EST lock to struct stmmac_priv")
    Signed-off-by: Sasha Levin <[email protected]>

net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe() [+ + +]
Author: Romain Gantois <[email protected]>
Date:   Tue May 21 14:44:11 2024 +0200

    net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe()
    
    commit b31c7e78086127a7fcaa761e8d336ee855a920c6 upstream.
    
    In the prueth_probe() function, if one of the calls to emac_phy_connect()
    fails due to of_phy_connect() returning NULL, then the subsequent call to
    phy_attached_info() will dereference a NULL pointer.
    
    Check the return code of emac_phy_connect and fail cleanly if there is an
    error.
    
    Fixes: 128d5874c082 ("net: ti: icssg-prueth: Add ICSSG ethernet driver")
    Cc: [email protected]
    Signed-off-by: Romain Gantois <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: MD Danish Anwar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: txgbe: fix GPIO interrupt blocking [+ + +]
Author: Jiawen Wu <[email protected]>
Date:   Fri Mar 1 17:29:55 2024 +0800

    net: txgbe: fix GPIO interrupt blocking
    
    [ Upstream commit b4a2496c17ed645f8d51061047c9c249b58c74ba ]
    
    The register of GPIO interrupt status is masked before MAC IRQ
    is enabled. This is because of hardware deficiency. So manually
    clear the interrupt status before using them. Otherwise, GPIO
    interrupts will never be reported again. There is a workaround for
    clearing interrupts to set GPIO EOI in txgbe_up_complete().
    
    Fixes: aefd013624a1 ("net: txgbe: use irq_domain for interrupt controller")
    Signed-off-by: Jiawen Wu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: txgbe: fix to clear interrupt status after handling IRQ [+ + +]
Author: Jiawen Wu <[email protected]>
Date:   Fri Mar 1 17:29:56 2024 +0800

    net: txgbe: fix to clear interrupt status after handling IRQ
    
    [ Upstream commit 0e71862a20d58b6e8d4c39de1d72c8919c4dccd1 ]
    
    GPIO EOI is not set to clear interrupt status after handling the
    interrupt. It should be done in irq_chip->irq_ack, but this function
    is not called in handle_nested_irq(). So executing function
    txgbe_gpio_irq_ack() manually in txgbe_gpio_irq_handler().
    
    Fixes: aefd013624a1 ("net: txgbe: use irq_domain for interrupt controller")
    Signed-off-by: Jiawen Wu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: txgbe: fix to control VLAN strip [+ + +]
Author: Jiawen Wu <[email protected]>
Date:   Fri May 17 14:51:40 2024 +0800

    net: txgbe: fix to control VLAN strip
    
    [ Upstream commit 1d3c6414950badaa38002af3b5857e01a21f01e9 ]
    
    When VLAN tag strip is changed to enable or disable, the hardware requires
    the Rx ring to be in a disabled state, otherwise the feature cannot be
    changed.
    
    Fixes: f3b03c655f67 ("net: wangxun: Implement vlan add and kill functions")
    Signed-off-by: Jiawen Wu <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: txgbe: move interrupt codes to a separate file [+ + +]
Author: Jiawen Wu <[email protected]>
Date:   Thu Jan 25 14:22:12 2024 +0800

    net: txgbe: move interrupt codes to a separate file
    
    [ Upstream commit 63aabc3ef1961a5eb3049d02a323b3b7fabb9a23 ]
    
    In order to change the interrupt response structure, there will be a
    lot of code added next. Move these interrupt codes to a new file, to
    make the codes cleaner.
    
    Signed-off-by: Jiawen Wu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 1d3c6414950b ("net: txgbe: fix to control VLAN strip")
    Signed-off-by: Sasha Levin <[email protected]>

net: txgbe: use irq_domain for interrupt controller [+ + +]
Author: Jiawen Wu <[email protected]>
Date:   Thu Jan 25 14:22:13 2024 +0800

    net: txgbe: use irq_domain for interrupt controller
    
    [ Upstream commit aefd013624a10f39b0bfaee8432a235128705380 ]
    
    In the current interrupt controller, the MAC interrupt acts as the
    parent interrupt in the GPIO IRQ chip. But when the number of Rx/Tx
    ring changes, the PCI IRQ vector needs to be reallocated. Then this
    interrupt controller would be corrupted. So use irq_domain structure
    to avoid the above problem.
    
    Signed-off-by: Jiawen Wu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 1d3c6414950b ("net: txgbe: fix to control VLAN strip")
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: qmi_wwan: add Telit FN920C04 compositions [+ + +]
Author: Daniele Palmas <[email protected]>
Date:   Thu Apr 18 13:12:07 2024 +0200

    net: usb: qmi_wwan: add Telit FN920C04 compositions
    
    [ Upstream commit 0b8fe5bd73249dc20be2e88a12041f8920797b59 ]
    
    Add the following Telit FN920C04 compositions:
    
    0x10a0: rmnet + tty (AT/NMEA) + tty (AT) + tty (diag)
    T:  Bus=03 Lev=01 Prnt=03 Port=06 Cnt=01 Dev#=  5 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a0 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x10a4: rmnet + tty (AT) + tty (AT) + tty (diag)
    T:  Bus=03 Lev=01 Prnt=03 Port=06 Cnt=01 Dev#=  8 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a4 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x10a9: rmnet + tty (AT) + tty (diag) + DPL (data packet logging) + adb
    T:  Bus=03 Lev=01 Prnt=03 Port=06 Cnt=01 Dev#=  9 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a9 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Daniele Palmas <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: smsc95xx: stop lying about skb->truesize [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu May 9 08:33:13 2024 +0000

    net: usb: smsc95xx: stop lying about skb->truesize
    
    [ Upstream commit d50729f1d60bca822ef6d9c1a5fb28d486bd7593 ]
    
    Some usb drivers try to set small skb->truesize and break
    core networking stacks.
    
    In this patch, I removed one of the skb->truesize override.
    
    I also replaced one skb_clone() by an allocation of a fresh
    and small skb, to get minimally sized skbs, like we did
    in commit 1e2c61172342 ("net: cdc_ncm: reduce skb truesize
    in rx path") and 4ce62d5b2f7a ("net: usb: ax88179_178a:
    stop lying about skb->truesize")
    
    v3: also fix a sparse error ( https://lore.kernel.org/oe-kbuild-all/[email protected]/ )
    v2: leave the skb_trim() game because smsc95xx_rx_csum_offload()
        needs the csum part. (Jakub)
        While we are it, use get_unaligned() in smsc95xx_rx_csum_offload().
    
    Fixes: 2f7ca802bdae ("net: Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Steve Glendinning <[email protected]>
    Cc: [email protected]
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: sr9700: stop lying about skb->truesize [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon May 6 14:39:39 2024 +0000

    net: usb: sr9700: stop lying about skb->truesize
    
    [ Upstream commit 05417aa9c0c038da2464a0c504b9d4f99814a23b ]
    
    Some usb drivers set small skb->truesize and break
    core networking stacks.
    
    In this patch, I removed one of the skb->truesize override.
    
    I also replaced one skb_clone() by an allocation of a fresh
    and small skb, to get minimally sized skbs, like we did
    in commit 1e2c61172342 ("net: cdc_ncm: reduce skb truesize
    in rx path") and 4ce62d5b2f7a ("net: usb: ax88179_178a:
    stop lying about skb->truesize")
    
    Fixes: c9b37458e956 ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support")
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: wangxun: fix to change Rx features [+ + +]
Author: Jiawen Wu <[email protected]>
Date:   Fri May 17 14:51:38 2024 +0800

    net: wangxun: fix to change Rx features
    
    [ Upstream commit 68067f065ee730c7c67b361c3c81808d25d5a90b ]
    
    Fix the issue where some Rx features cannot be changed.
    
    When using ethtool -K to turn off rx offload, it returns error and
    displays "Could not change any device features". And netdev->features
    is not assigned a new value to actually configure the hardware.
    
    Fixes: 6dbedcffcf54 ("net: libwx: Implement xx_set_features ops")
    Signed-off-by: Jiawen Wu <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: wangxun: match VLAN CTAG and STAG features [+ + +]
Author: Jiawen Wu <[email protected]>
Date:   Fri May 17 14:51:39 2024 +0800

    net: wangxun: match VLAN CTAG and STAG features
    
    [ Upstream commit ac71ab7816b675f1c9614015bd87bfccb456c394 ]
    
    Hardware requires VLAN CTAG and STAG configuration always matches. And
    whether VLAN CTAG or STAG changes, the configuration needs to be changed
    as well.
    
    Fixes: 6670f1ece2c8 ("net: txgbe: Add netdev features support")
    Signed-off-by: Jiawen Wu <[email protected]>
    Reviewed-by: Sai Krishna <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netrom: fix possible dead-lock in nr_rt_ioctl() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Wed May 15 14:29:34 2024 +0000

    netrom: fix possible dead-lock in nr_rt_ioctl()
    
    [ Upstream commit e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6 ]
    
    syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]
    
    Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)
    
    [1]
    WARNING: possible circular locking dependency detected
    6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted
    ------------------------------------------------------
    syz-executor350/5129 is trying to acquire lock:
     ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
     ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline]
     ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline]
     ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
    
    but task is already holding lock:
     ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
     ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
     ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (nr_node_list_lock){+...}-{2:2}:
            lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
            __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
            _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
            spin_lock_bh include/linux/spinlock.h:356 [inline]
            nr_remove_node net/netrom/nr_route.c:299 [inline]
            nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355
            nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683
            sock_do_ioctl+0x158/0x460 net/socket.c:1222
            sock_ioctl+0x629/0x8e0 net/socket.c:1341
            vfs_ioctl fs/ioctl.c:51 [inline]
            __do_sys_ioctl fs/ioctl.c:904 [inline]
            __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
            do_syscall_x64 arch/x86/entry/common.c:52 [inline]
            do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
           entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    -> #0 (&nr_node->node_lock){+...}-{2:2}:
            check_prev_add kernel/locking/lockdep.c:3134 [inline]
            check_prevs_add kernel/locking/lockdep.c:3253 [inline]
            validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
            __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
            lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
            __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
            _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
            spin_lock_bh include/linux/spinlock.h:356 [inline]
            nr_node_lock include/net/netrom.h:152 [inline]
            nr_dec_obs net/netrom/nr_route.c:464 [inline]
            nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
            sock_do_ioctl+0x158/0x460 net/socket.c:1222
            sock_ioctl+0x629/0x8e0 net/socket.c:1341
            vfs_ioctl fs/ioctl.c:51 [inline]
            __do_sys_ioctl fs/ioctl.c:904 [inline]
            __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
            do_syscall_x64 arch/x86/entry/common.c:52 [inline]
            do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
           entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(nr_node_list_lock);
                                   lock(&nr_node->node_lock);
                                   lock(nr_node_list_lock);
      lock(&nr_node->node_lock);
    
     *** DEADLOCK ***
    
    1 lock held by syz-executor350/5129:
      #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
      #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
      #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697
    
    stack backtrace:
    CPU: 0 PID: 5129 Comm: syz-executor350 Not tainted 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
      check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2187
      check_prev_add kernel/locking/lockdep.c:3134 [inline]
      check_prevs_add kernel/locking/lockdep.c:3253 [inline]
      validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
      __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
      lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
      __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
      _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
      spin_lock_bh include/linux/spinlock.h:356 [inline]
      nr_node_lock include/net/netrom.h:152 [inline]
      nr_dec_obs net/netrom/nr_route.c:464 [inline]
      nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
      sock_do_ioctl+0x158/0x460 net/socket.c:1222
      sock_ioctl+0x629/0x8e0 net/socket.c:1341
      vfs_ioctl fs/ioctl.c:51 [inline]
      __do_sys_ioctl fs/ioctl.c:904 [inline]
      __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfsd: don't create nfsv4recoverydir in nfsdfs when not used. [+ + +]
Author: NeilBrown <[email protected]>
Date:   Wed Apr 17 07:23:02 2024 +1000

    nfsd: don't create nfsv4recoverydir in nfsdfs when not used.
    
    [ Upstream commit 0770249b90f9d9f69714b76adc36cf6c895bc1f9 ]
    
    When CONFIG_NFSD_LEGACY_CLIENT_TRACKING is not set, the virtual file
      /proc/fs/nfsd/nfsv4recoverydir
    is created but responds EINVAL to any access.
    This is not useful, is somewhat surprising, and it causes ltp to
    complain.
    
    The only known user of this file is in nfs-utils, which handles
    non-existence and read-failure equally well.  So there is nothing to
    gain from leaving the file present but inaccessible.
    
    So this patch removes the file when its content is not available - i.e.
    when that config option is not selected.
    
    Also remove the #ifdef which hides some of the enum values when
    CONFIG_NFSD_V$ not selection.  simple_fill_super() quietly ignores array
    entries that are not present, so having slots in the array that don't
    get used is perfectly acceptable.  So there is no value in this #ifdef.
    
    Reported-by: Petr Vorel <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Fixes: 74fd48739d04 ("nfsd: new Kconfig option for legacy client tracking")
    Signed-off-by: NeilBrown <[email protected]>
    Reviewed-by: Petr Vorel <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nilfs2: fix out-of-range warning [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Thu Mar 28 15:30:44 2024 +0100

    nilfs2: fix out-of-range warning
    
    [ Upstream commit c473bcdd80d4ab2ae79a7a509a6712818366e32a ]
    
    clang-14 points out that v_size is always smaller than a 64KB
    page size if that is configured by the CPU architecture:
    
    fs/nilfs2/ioctl.c:63:19: error: result of comparison of constant 65536 with expression of type '__u16' (aka 'unsigned short') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            if (argv->v_size > PAGE_SIZE)
                ~~~~~~~~~~~~ ^ ~~~~~~~~~
    
    This is ok, so just shut up that warning with a cast.
    
    Signed-off-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 3358b4aaa84f ("nilfs2: fix problems of memory allocation in ioctl")
    Acked-by: Ryusuke Konishi <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nilfs2: fix potential hang in nilfs_detach_log_writer() [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Mon May 20 22:26:21 2024 +0900

    nilfs2: fix potential hang in nilfs_detach_log_writer()
    
    commit eb85dace897c5986bc2f36b3c783c6abb8a4292e upstream.
    
    Syzbot has reported a potential hang in nilfs_detach_log_writer() called
    during nilfs2 unmount.
    
    Analysis revealed that this is because nilfs_segctor_sync(), which
    synchronizes with the log writer thread, can be called after
    nilfs_segctor_destroy() terminates that thread, as shown in the call trace
    below:
    
    nilfs_detach_log_writer
      nilfs_segctor_destroy
        nilfs_segctor_kill_thread  --> Shut down log writer thread
        flush_work
          nilfs_iput_work_func
            nilfs_dispose_list
              iput
                nilfs_evict_inode
                  nilfs_transaction_commit
                    nilfs_construct_segment (if inode needs sync)
                      nilfs_segctor_sync  --> Attempt to synchronize with
                                              log writer thread
                               *** DEADLOCK ***
    
    Fix this issue by changing nilfs_segctor_sync() so that the log writer
    thread returns normally without synchronizing after it terminates, and by
    forcing tasks that are already waiting to complete once after the thread
    terminates.
    
    The skipped inode metadata flushout will then be processed together in the
    subsequent cleanup work in nilfs_segctor_destroy().
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=e3973c409251e136fdd0
    Tested-by: Ryusuke Konishi <[email protected]>
    Cc: <[email protected]>
    Cc: "Bai, Shuangpeng" <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

nilfs2: fix unexpected freezing of nilfs_segctor_sync() [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Mon May 20 22:26:20 2024 +0900

    nilfs2: fix unexpected freezing of nilfs_segctor_sync()
    
    commit 936184eadd82906992ff1f5ab3aada70cce44cee upstream.
    
    A potential and reproducible race issue has been identified where
    nilfs_segctor_sync() would block even after the log writer thread writes a
    checkpoint, unless there is an interrupt or other trigger to resume log
    writing.
    
    This turned out to be because, depending on the execution timing of the
    log writer thread running in parallel, the log writer thread may skip
    responding to nilfs_segctor_sync(), which causes a call to schedule()
    waiting for completion within nilfs_segctor_sync() to lose the opportunity
    to wake up.
    
    The reason why waking up the task waiting in nilfs_segctor_sync() may be
    skipped is that updating the request generation issued using a shared
    sequence counter and adding an wait queue entry to the request wait queue
    to the log writer, are not done atomically.  There is a possibility that
    log writing and request completion notification by nilfs_segctor_wakeup()
    may occur between the two operations, and in that case, the wait queue
    entry is not yet visible to nilfs_segctor_wakeup() and the wake-up of
    nilfs_segctor_sync() will be carried over until the next request occurs.
    
    Fix this issue by performing these two operations simultaneously within
    the lock section of sc_state_lock.  Also, following the memory barrier
    guidelines for event waiting loops, move the call to set_current_state()
    in the same location into the event waiting loop to ensure that a memory
    barrier is inserted just before the event condition determination.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 9ff05123e3bf ("nilfs2: segment constructor")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Tested-by: Ryusuke Konishi <[email protected]>
    Cc: <[email protected]>
    Cc: "Bai, Shuangpeng" <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

nilfs2: fix use-after-free of timer for log writer thread [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Mon May 20 22:26:19 2024 +0900

    nilfs2: fix use-after-free of timer for log writer thread
    
    commit f5d4e04634c9cf68bdf23de08ada0bb92e8befe7 upstream.
    
    Patch series "nilfs2: fix log writer related issues".
    
    This bug fix series covers three nilfs2 log writer-related issues,
    including a timer use-after-free issue and potential deadlock issue on
    unmount, and a potential freeze issue in event synchronization found
    during their analysis.  Details are described in each commit log.
    
    
    This patch (of 3):
    
    A use-after-free issue has been reported regarding the timer sc_timer on
    the nilfs_sc_info structure.
    
    The problem is that even though it is used to wake up a sleeping log
    writer thread, sc_timer is not shut down until the nilfs_sc_info structure
    is about to be freed, and is used regardless of the thread's lifetime.
    
    Fix this issue by limiting the use of sc_timer only while the log writer
    thread is alive.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: fdce895ea5dd ("nilfs2: change sc_timer from a pointer to an embedded one in struct nilfs_sc_info")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: "Bai, Shuangpeng" <[email protected]>
    Closes: https://groups.google.com/g/syzkaller/c/MK_LYqtt8ko/m/8rgdWeseAwAJ
    Tested-by: Ryusuke Konishi <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
null_blk: Fix missing mutex_destroy() at module removal [+ + +]
Author: Zhu Yanjun <[email protected]>
Date:   Thu Apr 25 19:16:35 2024 +0200

    null_blk: Fix missing mutex_destroy() at module removal
    
    [ Upstream commit 07d1b99825f40f9c0d93e6b99d79a08d0717bac1 ]
    
    When a mutex lock is not used any more, the function mutex_destroy
    should be called to mark the mutex lock uninitialized.
    
    Fixes: f2298c0403b0 ("null_blk: multi queue aware block test driver")
    Signed-off-by: Zhu Yanjun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme-tcp: strict pdu pacing to avoid send stalls on TLS [+ + +]
Author: Hannes Reinecke <[email protected]>
Date:   Thu Apr 18 12:39:45 2024 +0200

    nvme-tcp: strict pdu pacing to avoid send stalls on TLS
    
    [ Upstream commit 50abcc179e0c9ca667feb223b26ea406d5c4c556 ]
    
    TLS requires a strict pdu pacing via MSG_EOR to signal the end
    of a record and subsequent encryption. If we do not set MSG_EOR
    at the end of a sequence the record won't be closed, encryption
    doesn't start, and we end up with a send stall as the message
    will never be passed on to the TCP layer.
    So do not check for the queue status when TLS is enabled but
    rather make the MSG_MORE setting dependent on the current
    request only.
    
    Signed-off-by: Hannes Reinecke <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme: cancel pending I/O if nvme controller is in terminal state [+ + +]
Author: Nilay Shroff <[email protected]>
Date:   Thu Apr 25 19:33:00 2024 +0530

    nvme: cancel pending I/O if nvme controller is in terminal state
    
    [ Upstream commit 25bb3534ee21e39eb9301c4edd7182eb83cb0d07 ]
    
    While I/O is running, if the pci bus error occurs then
    in-flight I/O can not complete. Worst, if at this time,
    user (logically) hot-unplug the nvme disk then the
    nvme_remove() code path can't forward progress until
    in-flight I/O is cancelled. So these sequence of events
    may potentially hang hot-unplug code path indefinitely.
    This patch helps cancel the pending/in-flight I/O from the
    nvme request timeout handler in case the nvme controller
    is in the terminal (DEAD/DELETING/DELETING_NOIO) state and
    that helps nvme_remove() code path forward progress and
    finish successfully.
    
    Link: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Nilay Shroff <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nvme: find numa distance only if controller has valid numa id [+ + +]
Author: Nilay Shroff <[email protected]>
Date:   Tue Apr 16 13:49:23 2024 +0530

    nvme: find numa distance only if controller has valid numa id
    
    [ Upstream commit 863fe60ed27f2c85172654a63c5b827e72c8b2e6 ]
    
    On system where native nvme multipath is configured and iopolicy
    is set to numa but the nvme controller numa node id is undefined
    or -1 (NUMA_NO_NODE) then avoid calculating node distance for
    finding optimal io path. In such case we may access numa distance
    table with invalid index and that may potentially refer to incorrect
    memory. So this patch ensures that if the nvme controller numa node
    id is -1 then instead of calculating node distance for finding optimal
    io path, we set the numa node distance of such controller to default 10
    (LOCAL_DISTANCE).
    
    Link: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Nilay Shroff <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvmet-auth: replace pr_debug() with pr_err() to report an error. [+ + +]
Author: Maurizio Lombardi <[email protected]>
Date:   Wed Apr 10 11:48:42 2024 +0200

    nvmet-auth: replace pr_debug() with pr_err() to report an error.
    
    [ Upstream commit 445f9119e70368ccc964575c2a6d3176966a9d65 ]
    
    In nvmet_auth_host_hash(), if a mismatch is detected in the hash length
    the kernel should print an error.
    
    Signed-off-by: Maurizio Lombardi <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nvmet-auth: return the error code to the nvmet_auth_host_hash() callers [+ + +]
Author: Maurizio Lombardi <[email protected]>
Date:   Wed Apr 10 11:48:41 2024 +0200

    nvmet-auth: return the error code to the nvmet_auth_host_hash() callers
    
    [ Upstream commit 46b8f9f74f6d500871985e22eb19560b21f3bc81 ]
    
    If the nvmet_auth_host_hash() function fails, the error code should
    be returned to its callers.
    
    Signed-off-by: Maurizio Lombardi <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvmet-tcp: fix possible memory leak when tearing down a controller [+ + +]
Author: Sagi Grimberg <[email protected]>
Date:   Sun Apr 28 11:49:49 2024 +0300

    nvmet-tcp: fix possible memory leak when tearing down a controller
    
    [ Upstream commit 6825bdde44340c5a9121f6d6fa25cc885bd9e821 ]
    
    When we teardown the controller, we wait for pending I/Os to complete
    (sq->ref on all queues to drop to zero) and then we go over the commands,
    and free their command buffers in case they are still fetching data from
    the host (e.g. processing nvme writes) and have yet to take a reference
    on the sq.
    
    However, we may miss the case where commands have failed before executing
    and are queued for sending a response, but will never occur because the
    queue socket is already down. In this case we may miss deallocating command
    buffers.
    
    Solve this by freeing all commands buffers as nvmet_tcp_free_cmd_buffers is
    idempotent anyways.
    
    Reported-by: Yi Zhang <[email protected]>
    Tested-by: Yi Zhang <[email protected]>
    Signed-off-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvmet: fix nvme status code when namespace is disabled [+ + +]
Author: Sagi Grimberg <[email protected]>
Date:   Sun Apr 28 12:25:40 2024 +0300

    nvmet: fix nvme status code when namespace is disabled
    
    [ Upstream commit 505363957fad35f7aed9a2b0d8dad73451a80fb5 ]
    
    If the user disabled a nvmet namespace, it is removed from the subsystem
    namespaces list. When nvmet processes a command directed to an nsid that
    was disabled, it cannot differentiate between a nsid that is disabled
    vs. a non-existent namespace, and resorts to return NVME_SC_INVALID_NS
    with the dnr bit set.
    
    This translates to a non-retryable status for the host, which translates
    to a user error. We should expect disabled namespaces to not cause an
    I/O error in a multipath environment.
    
    Address this by searching a configfs item for the namespace nvmet failed
    to find, and if we found one, conclude that the namespace is disabled
    (perhaps temporarily). Return NVME_SC_INTERNAL_PATH_ERROR in this case
    and keep DNR bit cleared.
    
    Reported-by: Jirong Feng <[email protected]>
    Tested-by: Jirong Feng <[email protected]>
    Signed-off-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nvmet: prevent sprintf() overflow in nvmet_subsys_nsid_exists() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Wed May 8 10:43:04 2024 +0300

    nvmet: prevent sprintf() overflow in nvmet_subsys_nsid_exists()
    
    [ Upstream commit d15dcd0f1a4753b57e66c64c8dc2a9779ff96aab ]
    
    The nsid value is a u32 that comes from nvmet_req_find_ns().  It's
    endian data and we're on an error path and both of those raise red
    flags.  So let's make this safer.
    
    1) Make the buffer large enough for any u32.
    2) Remove the unnecessary initialization.
    3) Use snprintf() instead of sprintf() for even more safety.
    4) The sprintf() function returns the number of bytes printed, not
       counting the NUL terminator. It is impossible for the return value to
       be <= 0 so delete that.
    
    Fixes: 505363957fad ("nvmet: fix nvme status code when namespace is disabled")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
of: module: add buffer overflow check in of_modalias() [+ + +]
Author: Sergey Shtylyov <[email protected]>
Date:   Sun Apr 14 11:51:39 2024 +0300

    of: module: add buffer overflow check in of_modalias()
    
    [ Upstream commit cf7385cb26ac4f0ee6c7385960525ad534323252 ]
    
    In of_modalias(), if the buffer happens to be too small even for the 1st
    snprintf() call, the len parameter will become negative and str parameter
    (if not NULL initially) will point beyond the buffer's end. Add the buffer
    overflow check after the 1st snprintf() call and fix such check after the
    strlen() call (accounting for the terminating NUL char).
    
    Fixes: bc575064d688 ("of/device: use of_property_for_each_string to parse compatible strings")
    Signed-off-by: Sergey Shtylyov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rob Herring <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
openpromfs: finish conversion to the new mount API [+ + +]
Author: Eric Sandeen <[email protected]>
Date:   Fri Mar 1 16:33:11 2024 -0600

    openpromfs: finish conversion to the new mount API
    
    [ Upstream commit 8f27829974b025d4df2e78894105d75e3bf349f0 ]
    
    The original mount API conversion inexplicably left out the change
    from ->remount_fs to ->reconfigure; do that now.
    
    Fixes: 7ab2fa7693c3 ("vfs: Convert openpromfs to use the new mount API")
    Signed-off-by: Eric Sandeen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
openrisc: traps: Don't send signals to kernel mode threads [+ + +]
Author: Stafford Horne <[email protected]>
Date:   Sat Mar 30 14:42:49 2024 +0000

    openrisc: traps: Don't send signals to kernel mode threads
    
    [ Upstream commit c88cfb5cea5f8f9868ef02cc9ce9183a26dcf20f ]
    
    OpenRISC exception handling sends signals to user processes on floating
    point exceptions and trap instructions (for debugging) among others.
    There is a bug where the trap handling logic may send signals to kernel
    threads, we should not send these signals to kernel threads, if that
    happens we treat it as an error.
    
    This patch adds conditions to die if the kernel receives these
    exceptions in kernel mode code.
    
    Fixes: 27267655c531 ("openrisc: Support floating point user api")
    Signed-off-by: Stafford Horne <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
overflow: Change DEFINE_FLEX to take __counted_by member [+ + +]
Author: Kees Cook <[email protected]>
Date:   Wed Mar 6 15:51:36 2024 -0800

    overflow: Change DEFINE_FLEX to take __counted_by member
    
    [ Upstream commit d8e45f2929b94099913eb66c3ebb18b5063e9421 ]
    
    The norm should be flexible array structures with __counted_by
    annotations, so DEFINE_FLEX() is updated to expect that. Rename
    the non-annotated version to DEFINE_RAW_FLEX(), and update the
    few existing users. Additionally add selftests for the macros.
    
    Reviewed-by: Gustavo A. R. Silva <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Przemek Kitszel <[email protected]>
    Signed-off-by: Kees Cook <[email protected]>
    Stable-dep-of: e77f43d531af ("Bluetooth: hci_core: Fix not handling hdev->le_num_of_adv_sets=1")
    Signed-off-by: Sasha Levin <[email protected]>

 
parisc: add missing export of __cmpxchg_u8() [+ + +]
Author: Al Viro <[email protected]>
Date:   Mon Apr 1 22:35:54 2024 -0400

    parisc: add missing export of __cmpxchg_u8()
    
    [ Upstream commit c57e5dccb06decf3cb6c272ab138c033727149b5 ]
    
    __cmpxchg_u8() had been added (initially) for the sake of
    drivers/phy/ti/phy-tusb1210.c; the thing is, that drivers is
    modular, so we need an export
    
    Fixes: b344d6a83d01 "parisc: add support for cmpxchg on u8 pointers"
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
platform/x86: ISST: Add Grand Ridge to HPM CPU list [+ + +]
Author: Srinivas Pandruvada <[email protected]>
Date:   Mon Apr 22 14:22:22 2024 -0700

    platform/x86: ISST: Add Grand Ridge to HPM CPU list
    
    [ Upstream commit 515a3c3a5489a890c7c3c1df3855eb4868a27598 ]
    
    Add Grand Ridge (ATOM_CRESTMONT) to hpm_cpu_ids, so that MSR 0x54 can be
    used.
    
    Signed-off-by: Srinivas Pandruvada <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

platform/x86: xiaomi-wmi: Fix race condition when reporting key events [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Tue Apr 2 16:30:57 2024 +0200

    platform/x86: xiaomi-wmi: Fix race condition when reporting key events
    
    [ Upstream commit 290680c2da8061e410bcaec4b21584ed951479af ]
    
    Multiple WMI events can be received concurrently, so multiple instances
    of xiaomi_wmi_notify() can be active at the same time. Since the input
    device is shared between those handlers, the key input sequence can be
    disturbed.
    
    Fix this by protecting the key input sequence with a mutex.
    
    Compile-tested only.
    
    Fixes: edb73f4f0247 ("platform/x86: wmi: add Xiaomi WMI key driver")
    Signed-off-by: Armin Wolf <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/fsl-soc: hide unused const variable [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Wed Apr 3 10:06:19 2024 +0200

    powerpc/fsl-soc: hide unused const variable
    
    [ Upstream commit 01acaf3aa75e1641442cc23d8fe0a7bb4226efb1 ]
    
    vmpic_msi_feature is only used conditionally, which triggers a rare
    -Werror=unused-const-variable= warning with gcc:
    
    arch/powerpc/sysdev/fsl_msi.c:567:37: error: 'vmpic_msi_feature' defined but not used [-Werror=unused-const-variable=]
      567 | static const struct fsl_msi_feature vmpic_msi_feature =
    
    Hide this one in the same #ifdef as the reference so we can turn on
    the warning by default.
    
    Fixes: 305bcf26128e ("powerpc/fsl-soc: use CONFIG_EPAPR_PARAVIRT for hcalls")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
printk: Let no_printk() use _printk() [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Wed Feb 28 15:00:02 2024 +0100

    printk: Let no_printk() use _printk()
    
    [ Upstream commit 8522f6b760ca588928eede740d5d69dd1e936b49 ]
    
    When printk-indexing is enabled, each printk() invocation emits a
    pi_entry structure, containing the format string and other information
    related to its location in the kernel sources.  This is even true for
    no_printk(): while the actual code to print the message is optimized out
    by the compiler due to the always-false check, the pi_entry structure is
    still emitted.
    
    As the main purpose of no_printk() is to provide a helper to maintain
    printf()-style format checking when debugging is disabled, this leads to
    the inclusion in the index of lots of printk formats that cannot be
    emitted by the current kernel.
    
    Fix this by switching no_printk() from printk() to _printk().
    
    This reduces the size of an arm64 defconfig kernel with
    CONFIG_PRINTK_INDEX=y by 576 KiB.
    
    Fixes: 337015573718b161 ("printk: Userspace format indexing support")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Reviewed-by: Xiubo Li <[email protected]>
    Reviewed-by: Chris Down <[email protected]>
    Reviewed-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/56cf92edccffea970e1f40a075334dd6cf5bb2a4.1709127473.git.geert+renesas@glider.be
    Signed-off-by: Petr Mladek <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ptp: ocp: fix DPLL functions [+ + +]
Author: Vadim Fedorenko <[email protected]>
Date:   Wed May 8 13:21:11 2024 +0000

    ptp: ocp: fix DPLL functions
    
    [ Upstream commit a2c78977950da00aca83a3f8865d1f54e715770d ]
    
    In ptp_ocp driver pin actions assume sma_nr starts with 1, but for DPLL
    subsystem callback 0-based index was used. Fix it providing proper index.
    
    Fixes: 09eeb3aecc6c ("ptp_ocp: implement DPLL ops")
    Signed-off-by: Vadim Fedorenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pwm: Drop duplicate check against chip->npwm in of_pwm_xlate_with_flags() [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Tue Jan 9 22:34:35 2024 +0100

    pwm: Drop duplicate check against chip->npwm in of_pwm_xlate_with_flags()
    
    [ Upstream commit 91bb23493f8fd115e362d075ebaa3e6f12d1439d ]
    
    args->args[0] is passed as parameter "index" to pwm_request_from_chip().
    The latter function also checks for index >= npwm, so
    of_pwm_xlate_with_flags() doesn't need to do that.
    
    Link: https://lore.kernel.org/r/b06e445a6ed62a339add727eccb969a33d678386.1704835845.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Stable-dep-of: 3e551115aee0 ("pwm: meson: Add check for error from clk_round_rate()")
    Signed-off-by: Sasha Levin <[email protected]>

pwm: Drop useless member .of_pwm_n_cells of struct pwm_chip [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Tue Jan 9 22:34:32 2024 +0100

    pwm: Drop useless member .of_pwm_n_cells of struct pwm_chip
    
    [ Upstream commit 4e77431cda4973f03d063c47f6ea313dfceebf16 ]
    
    Apart from the two of_xlate implementations this member is write-only.
    In the of_xlate functions of_pwm_xlate_with_flags() and
    of_pwm_single_xlate() it's more sensible to check for args->args_count
    because this is what is actually used in the device tree.
    
    Acked-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/53d8c545aa8f79a920358be9e72e382b3981bdc4.1704835845.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Stable-dep-of: 3e551115aee0 ("pwm: meson: Add check for error from clk_round_rate()")
    Signed-off-by: Sasha Levin <[email protected]>

pwm: Fix setting period with #pwm-cells = <1> and of_pwm_single_xlate() [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Fri Mar 29 11:35:40 2024 +0100

    pwm: Fix setting period with #pwm-cells = <1> and of_pwm_single_xlate()
    
    [ Upstream commit 73dfe970c038d0548beccc5bfb2707e1d543b01f ]
    
    For drivers making use of of_pwm_single_xlate() (i.e. those that don't
    pass a hwpwm index) and also don't pass flags, setting period was
    wrongly skipped. This affects the pwm-pxa and ti-sn65dsi86 drivers.
    
    Reported-by: Karel Balej <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 40ade0c2e794 ("pwm: Let the of_xlate callbacks accept references without period")
    Tested-by: Karel Balej <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pwm: Let the of_xlate callbacks accept references without period [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Tue Jan 9 22:34:33 2024 +0100

    pwm: Let the of_xlate callbacks accept references without period
    
    [ Upstream commit 40ade0c2e7940becad70a0643ba90488b905b468 ]
    
    With this extension of_pwm_xlate_with_flags() is suitable to replace the
    custom xlate function of the pwm-clps711x driver.
    
    While touching these very similar functions align their implementations.
    
    Link: https://lore.kernel.org/r/127622315d07d9d419ae8e6373c7e5be7fab7a62.1704835845.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Stable-dep-of: 3e551115aee0 ("pwm: meson: Add check for error from clk_round_rate()")
    Signed-off-by: Sasha Levin <[email protected]>

pwm: meson: Add check for error from clk_round_rate() [+ + +]
Author: George Stark <[email protected]>
Date:   Thu Apr 25 20:12:52 2024 +0300

    pwm: meson: Add check for error from clk_round_rate()
    
    [ Upstream commit 3e551115aee079931b82e1ec78c05f3d5033473f ]
    
    clk_round_rate() can return not only zero if requested frequency can not
    be provided but also negative error code so add check for it too.
    
    Also change type of variable holding clk_round_rate() result from
    unsigned long to long. It's safe due to clk_round_rate() returns long.
    
    Fixes: 329db102a26d ("pwm: meson: make full use of common clock framework")
    Signed-off-by: Dmitry Rokosov <[email protected]>
    Signed-off-by: George Stark <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pwm: meson: Change prototype of a few helpers to prepare further changes [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Wed Feb 14 10:31:57 2024 +0100

    pwm: meson: Change prototype of a few helpers to prepare further changes
    
    [ Upstream commit b647dcfde1b5683abf7a939897888ca2786ac6c6 ]
    
    This prepares the driver for further changes that will make it harder to
    determine the pwm_chip from a given meson_pwm. To just not have to do
    that, rework meson_pwm_calc(), meson_pwm_enable(), meson_pwm_disable()
    and meson_pwm_init_channels() to take a pwm_chip.
    
    Link: https://lore.kernel.org/r/157084e1dd464da0097edba880240868c1c0b27e.1707900770.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Stable-dep-of: 3e551115aee0 ("pwm: meson: Add check for error from clk_round_rate()")
    Signed-off-by: Sasha Levin <[email protected]>

pwm: meson: Make use of pwmchip_parent() accessor [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Wed Feb 14 10:31:58 2024 +0100

    pwm: meson: Make use of pwmchip_parent() accessor
    
    [ Upstream commit e369035a98894a7327e78ebd01ec859c6654fc52 ]
    
    struct pwm_chip::dev is about to change. To not have to touch this
    driver in the same commit as struct pwm_chip::dev, use the accessor
    function provided for exactly this purpose.
    
    Link: https://lore.kernel.org/r/02d5f32001c4d0817fa79f5831cfd16b7e345f00.1707900770.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Stable-dep-of: 3e551115aee0 ("pwm: meson: Add check for error from clk_round_rate()")
    Signed-off-by: Sasha Levin <[email protected]>

pwm: meson: Use mul_u64_u64_div_u64() for frequency calculating [+ + +]
Author: George Stark <[email protected]>
Date:   Thu Apr 25 20:12:53 2024 +0300

    pwm: meson: Use mul_u64_u64_div_u64() for frequency calculating
    
    [ Upstream commit 32c44e1fa921aebf8a5ef9f778534a30aab39313 ]
    
    While calculating frequency for the given period u64 numbers are
    multiplied before division what can lead to overflow in theory so use
    secure mul_u64_u64_div_u64() which handles overflow correctly.
    
    Fixes: 329db102a26d ("pwm: meson: make full use of common clock framework")
    Suggested-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: George Stark <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pwm: Provide an inline function to get the parent device of a given chip [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Wed Feb 14 10:30:48 2024 +0100

    pwm: Provide an inline function to get the parent device of a given chip
    
    [ Upstream commit 4e59267c7a20eb1c1ad9106e682cb6a0d8eb3111 ]
    
    Currently a pwm_chip stores in its struct device *dev member a pointer
    to the parent device. Preparing a change that embeds a full struct
    device in struct pwm_chip, this accessor function should be used in all
    drivers directly accessing chip->dev now. This way struct pwm_chip and
    this new function can be changed without having to touch all drivers in
    the same change set.
    
    Make use of this function in the framework's core sources.
    
    Reviewed-by: Greg Kroah-Hartman <[email protected]>
    Link: https://lore.kernel.org/r/cc30090d2f9762bed9854a55612144bccc910781.1707900770.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Stable-dep-of: 3e551115aee0 ("pwm: meson: Add check for error from clk_round_rate()")
    Signed-off-by: Sasha Levin <[email protected]>

pwm: Reorder symbols in core.c [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Thu Jan 25 13:08:23 2024 +0100

    pwm: Reorder symbols in core.c
    
    [ Upstream commit 62928315adfe32442b119cff42788891db89a575 ]
    
    This moves the functions called by pwm consumers above the functions
    called by pwm providers. When character device support is added later
    this is hooked into the chip registration functions. As the needed
    callbacks are a kind of consumer and make use of the consumer functions,
    having this order is more natural and prevents having to add
    declarations for static functions.
    
    Also move the global variables for pwm tables to the respective
    functions to have them properly grouped.
    
    Link: https://lore.kernel.org/r/eed83de07bdfb69b5ceba0b9aed757ee612dea8f.1706182805.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Stable-dep-of: 3e551115aee0 ("pwm: meson: Add check for error from clk_round_rate()")
    Signed-off-by: Sasha Levin <[email protected]>

pwm: sti: Prepare removing pwm_chip from driver data [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Wed Feb 14 10:32:38 2024 +0100

    pwm: sti: Prepare removing pwm_chip from driver data
    
    [ Upstream commit 54272761ce7c475fa30a31b59b0cb89f7652b39e ]
    
    This prepares the driver for further changes that will drop struct
    pwm_chip chip from struct sti_pwm_chip. Use the pwm_chip as driver data
    instead of the sti_pwm_chip to get access to the pwm_chip in
    sti_pwm_remove() without using pc->chip.
    
    Link: https://lore.kernel.org/r/56d53372aacff6871df4d6c6779c9dac94592696.1707900770.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Stable-dep-of: 5bb0b194aeee ("pwm: sti: Simplify probe function using devm functions")
    Signed-off-by: Sasha Levin <[email protected]>

pwm: sti: Simplify probe function using devm functions [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Sun Mar 10 12:00:54 2024 +0100

    pwm: sti: Simplify probe function using devm functions
    
    [ Upstream commit 5bb0b194aeee5d5da6881232f4e9989b35957c25 ]
    
    Instead of of_clk_get_by_name() use devm_clk_get_prepared() which has
    several advantages:
    
     - Combines getting the clock and a call to clk_prepare(). The latter
       can be dropped from sti_pwm_probe() accordingly.
     - Cares for calling clk_put() which is missing in both probe's error
       path and the remove function.
     - Cares for calling clk_unprepare() which can be dropped from the error
       paths and the remove function. (Note that not all error path got this
       right.)
    
    With additionally using devm_pwmchip_add() instead of pwmchip_add() the
    remove callback can be dropped completely. With it the last user of
    platform_get_drvdata() goes away and so platform_set_drvdata() can be
    dropped from the probe function, too.
    
    Fixes: 378fe115d19d ("pwm: sti: Add new driver for ST's PWM IP")
    Link: https://lore.kernel.org/r/81f0e1d173652f435afda6719adaed1922fe059a.1710068192.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
qed: avoid truncating work queue length [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Tue Mar 26 23:38:02 2024 +0100

    qed: avoid truncating work queue length
    
    [ Upstream commit 954fd908f177604d4cce77e2a88cc50b29bad5ff ]
    
    clang complains that the temporary string for the name passed into
    alloc_workqueue() is too short for its contents:
    
    drivers/net/ethernet/qlogic/qed/qed_main.c:1218:3: error: 'snprintf' will always be truncated; specified size is 16, but format string expands to at least 18 [-Werror,-Wformat-truncation]
    
    There is no need for a temporary buffer, and the actual name of a workqueue
    is 32 bytes (WQ_NAME_LEN), so just use the interface as intended to avoid
    the truncation.
    
    Fixes: 59ccf86fe69a ("qed: Add driver infrastucture for handling mfw requests.")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
r8169: Fix possible ring buffer corruption on fragmented Tx packets. [+ + +]
Author: Ken Milmore <[email protected]>
Date:   Tue May 21 23:45:50 2024 +0100

    r8169: Fix possible ring buffer corruption on fragmented Tx packets.
    
    commit c71e3a5cffd5309d7f84444df03d5b72600cc417 upstream.
    
    An issue was found on the RTL8125b when transmitting small fragmented
    packets, whereby invalid entries were inserted into the transmit ring
    buffer, subsequently leading to calls to dma_unmap_single() with a null
    address.
    
    This was caused by rtl8169_start_xmit() not noticing changes to nr_frags
    which may occur when small packets are padded (to work around hardware
    quirks) in rtl8169_tso_csum_v2().
    
    To fix this, postpone inspecting nr_frags until after any padding has been
    applied.
    
    Fixes: 9020845fb5d6 ("r8169: improve rtl8169_start_xmit")
    Cc: [email protected]
    Signed-off-by: Ken Milmore <[email protected]>
    Reviewed-by: Heiner Kallweit <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow [+ + +]
Author: Nikita Kiryushin <[email protected]>
Date:   Wed Mar 27 20:47:47 2024 +0300

    rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow
    
    [ Upstream commit cc5645fddb0ce28492b15520306d092730dffa48 ]
    
    There is a possibility of buffer overflow in
    show_rcu_tasks_trace_gp_kthread() if counters, passed
    to sprintf() are huge. Counter numbers, needed for this
    are unrealistically high, but buffer overflow is still
    possible.
    
    Use snprintf() with buffer size instead of sprintf().
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: edf3775f0ad6 ("rcu-tasks: Add count for idle tasks on offline CPUs")
    Signed-off-by: Nikita Kiryushin <[email protected]>
    Reviewed-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Uladzislau Rezki (Sony) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
rcu: Fix buffer overflow in print_cpu_stall_info() [+ + +]
Author: Nikita Kiryushin <[email protected]>
Date:   Mon Apr 1 22:43:15 2024 +0300

    rcu: Fix buffer overflow in print_cpu_stall_info()
    
    [ Upstream commit 3758f7d9917bd7ef0482c4184c0ad673b4c4e069 ]
    
    The rcuc-starvation output from print_cpu_stall_info() might overflow the
    buffer if there is a huge difference in jiffies difference.  The situation
    might seem improbable, but computers sometimes get very confused about
    time, which can result in full-sized integers, and, in this case,
    buffer overflow.
    
    Also, the unsigned jiffies difference is printed using %ld, which is
    normally for signed integers.  This is intentional for debugging purposes,
    but it is not obvious from the code.
    
    This commit therefore changes sprintf() to snprintf() and adds a
    clarifying comment about intention of %ld format.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 245a62982502 ("rcu: Dump rcuc kthread status for CPUs not reporting quiescent state")
    Signed-off-by: Nikita Kiryushin <[email protected]>
    Reviewed-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Uladzislau Rezki (Sony) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw [+ + +]
Author: Zhu Yanjun <[email protected]>
Date:   Fri May 10 23:12:47 2024 +0200

    RDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw
    
    [ Upstream commit 9c0731832d3b7420cbadba6a7f334363bc8dfb15 ]
    
    When running blktests nvme/rdma, the following kmemleak issue will appear.
    
    kmemleak: Kernel memory leak detector initialized (mempool available:36041)
    kmemleak: Automatic memory scanning thread started
    kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
    kmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
    kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
    kmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
    
    unreferenced object 0xffff88855da53400 (size 192):
      comm "rdma", pid 10630, jiffies 4296575922
      hex dump (first 32 bytes):
        37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00  7...............
        10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff  .4.].....4.]....
      backtrace (crc 47f66721):
        [<ffffffff911251bd>] kmalloc_trace+0x30d/0x3b0
        [<ffffffffc2640ff7>] alloc_gid_entry+0x47/0x380 [ib_core]
        [<ffffffffc2642206>] add_modify_gid+0x166/0x930 [ib_core]
        [<ffffffffc2643468>] ib_cache_update.part.0+0x6d8/0x910 [ib_core]
        [<ffffffffc2644e1a>] ib_cache_setup_one+0x24a/0x350 [ib_core]
        [<ffffffffc263949e>] ib_register_device+0x9e/0x3a0 [ib_core]
        [<ffffffffc2a3d389>] 0xffffffffc2a3d389
        [<ffffffffc2688cd8>] nldev_newlink+0x2b8/0x520 [ib_core]
        [<ffffffffc2645fe3>] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core]
        [<ffffffffc264648c>]
    rdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core]
        [<ffffffff9270e7b5>] netlink_unicast+0x445/0x710
        [<ffffffff9270f1f1>] netlink_sendmsg+0x761/0xc40
        [<ffffffff9249db29>] __sys_sendto+0x3a9/0x420
        [<ffffffff9249dc8c>] __x64_sys_sendto+0xdc/0x1b0
        [<ffffffff92db0ad3>] do_syscall_64+0x93/0x180
        [<ffffffff92e00126>] entry_SYSCALL_64_after_hwframe+0x71/0x79
    
    The root cause: rdma_put_gid_attr is not called when sgid_attr is set
    to ERR_PTR(-ENODEV).
    
    Reported-and-tested-by: Yi Zhang <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/T/
    Fixes: f8ef1be816bf ("RDMA/cma: Avoid GID lookups on iWARP devices")
    Reviewed-by: Chuck Lever <[email protected]>
    Signed-off-by: Zhu Yanjun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/hns: Fix deadlock on SRQ async events. [+ + +]
Author: Chengchang Tang <[email protected]>
Date:   Fri Apr 12 17:16:10 2024 +0800

    RDMA/hns: Fix deadlock on SRQ async events.
    
    [ Upstream commit b46494b6f9c19f141114a57729e198698f40af37 ]
    
    xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/
    xa_erase_irq() to avoid deadlock.
    
    Fixes: 81fce6291d99 ("RDMA/hns: Add SRQ asynchronous event support")
    Signed-off-by: Chengchang Tang <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix GMV table pagesize [+ + +]
Author: Chengchang Tang <[email protected]>
Date:   Fri Apr 12 17:16:13 2024 +0800

    RDMA/hns: Fix GMV table pagesize
    
    [ Upstream commit ee045493283403969591087bd405fa280103282a ]
    
    GMV's BA table only supports 4K pages. Currently, PAGESIZE is used to
    calculate gmv_bt_num, which will cause an abnormal number of gmv_bt_num
    in a 64K OS.
    
    Fixes: d6d91e46210f ("RDMA/hns: Add support for configuring GMV table")
    Signed-off-by: Chengchang Tang <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix return value in hns_roce_map_mr_sg [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Thu Apr 11 11:38:51 2024 +0800

    RDMA/hns: Fix return value in hns_roce_map_mr_sg
    
    [ Upstream commit 203b70fda63425a4eb29f03f9074859afe821a39 ]
    
    As described in the ib_map_mr_sg function comment, it returns the number
    of sg elements that were mapped to the memory region. However,
    hns_roce_map_mr_sg returns the number of pages required for mapping the
    DMA area. Fix it.
    
    Fixes: 9b2cf76c9f05 ("RDMA/hns: Optimize PBL buffer allocation process")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Junxian Huang <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix UAF for cq async event [+ + +]
Author: Chengchang Tang <[email protected]>
Date:   Fri Apr 12 17:16:11 2024 +0800

    RDMA/hns: Fix UAF for cq async event
    
    [ Upstream commit a942ec2745ca864cd8512142100e4027dc306a42 ]
    
    The refcount of CQ is not protected by locks. When CQ asynchronous
    events and CQ destruction are concurrent, CQ may have been released,
    which will cause UAF.
    
    Use the xa_lock() to protect the CQ refcount.
    
    Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
    Signed-off-by: Chengchang Tang <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Modify the print level of CQE error [+ + +]
Author: Chengchang Tang <[email protected]>
Date:   Fri Apr 12 17:16:16 2024 +0800

    RDMA/hns: Modify the print level of CQE error
    
    [ Upstream commit 349e859952285ab9689779fb46de163f13f18f43 ]
    
    Too much print may lead to a panic in kernel. Change ibdev_err() to
    ibdev_err_ratelimited(), and change the printing level of cqe dump
    to debug level.
    
    Fixes: 7c044adca272 ("RDMA/hns: Simplify the cqe code of poll cq")
    Signed-off-by: Chengchang Tang <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Use complete parentheses in macros [+ + +]
Author: Chengchang Tang <[email protected]>
Date:   Fri Apr 12 17:16:15 2024 +0800

    RDMA/hns: Use complete parentheses in macros
    
    [ Upstream commit 4125269bb9b22e1d8cdf4412c81be8074dbc61ca ]
    
    Use complete parentheses to ensure that macro expansion does
    not produce unexpected results.
    
    Fixes: a25d13cbe816 ("RDMA/hns: Add the interfaces to support multi hop addressing for the contexts in hip08")
    Signed-off-by: Chengchang Tang <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/IPoIB: Fix format truncation compilation errors [+ + +]
Author: Leon Romanovsky <[email protected]>
Date:   Thu May 9 10:39:33 2024 +0300

    RDMA/IPoIB: Fix format truncation compilation errors
    
    [ Upstream commit 49ca2b2ef3d003402584c68ae7b3055ba72e750a ]
    
    Truncate the device name to store IPoIB VLAN name.
    
    [leonro@5b4e8fba4ddd kernel]$ make -s -j 20 allmodconfig
    [leonro@5b4e8fba4ddd kernel]$ make -s -j 20 W=1 drivers/infiniband/ulp/ipoib/
    drivers/infiniband/ulp/ipoib/ipoib_vlan.c: In function ‘ipoib_vlan_add’:
    drivers/infiniband/ulp/ipoib/ipoib_vlan.c:187:52: error: ‘%04x’
    directive output may be truncated writing 4 bytes into a region of size
    between 0 and 15 [-Werror=format-truncation=]
      187 |         snprintf(intf_name, sizeof(intf_name), "%s.%04x",
          |                                                    ^~~~
    drivers/infiniband/ulp/ipoib/ipoib_vlan.c:187:48: note: directive
    argument in the range [0, 65535]
      187 |         snprintf(intf_name, sizeof(intf_name), "%s.%04x",
          |                                                ^~~~~~~~~
    drivers/infiniband/ulp/ipoib/ipoib_vlan.c:187:9: note: ‘snprintf’ output
    between 6 and 21 bytes into a destination of size 16
      187 |         snprintf(intf_name, sizeof(intf_name), "%s.%04x",
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      188 |                  ppriv->dev->name, pkey);
          |                  ~~~~~~~~~~~~~~~~~~~~~~~
    cc1: all warnings being treated as errors
    make[6]: *** [scripts/Makefile.build:244: drivers/infiniband/ulp/ipoib/ipoib_vlan.o] Error 1
    make[6]: *** Waiting for unfinished jobs....
    
    Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
    Link: https://lore.kernel.org/r/e9d3e1fef69df4c9beaf402cc3ac342bad680791.1715240029.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/mana_ib: boundary check before installing cq callbacks [+ + +]
Author: Konstantin Taranov <[email protected]>
Date:   Fri Apr 26 06:12:39 2024 -0700

    RDMA/mana_ib: boundary check before installing cq callbacks
    
    [ Upstream commit f79edef79b6a2161f4124112f9b0c46891bb0b74 ]
    
    Add a boundary check inside mana_ib_install_cq_cb to prevent index overflow.
    
    Fixes: 2a31c5a7e0d8 ("RDMA/mana_ib: Introduce mana_ib_install_cq_cb helper function")
    Signed-off-by: Konstantin Taranov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Long Li <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/mana_ib: Introduce helpers to create and destroy mana queues [+ + +]
Author: Konstantin Taranov <[email protected]>
Date:   Tue Mar 26 13:08:05 2024 -0700

    RDMA/mana_ib: Introduce helpers to create and destroy mana queues
    
    [ Upstream commit 46f5be7cd4bceb3a503c544b3dab7b75fe4bb96b ]
    
    Intoduce helpers to work with mana ib queues (struct mana_ib_queue).
    A queue always consists of umem, gdma_region, and id.
    A queue can become a WQ or a CQ.
    
    Signed-off-by: Konstantin Taranov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Long Li <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Stable-dep-of: f79edef79b6a ("RDMA/mana_ib: boundary check before installing cq callbacks")
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/mana_ib: Use struct mana_ib_queue for CQs [+ + +]
Author: Konstantin Taranov <[email protected]>
Date:   Tue Mar 26 13:08:06 2024 -0700

    RDMA/mana_ib: Use struct mana_ib_queue for CQs
    
    [ Upstream commit 60a7ac0b8bec5df9764b7460ffee91fc981e8a31 ]
    
    Use struct mana_ib_queue and its helpers for CQs
    
    Signed-off-by: Konstantin Taranov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Long Li <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Stable-dep-of: f79edef79b6a ("RDMA/mana_ib: boundary check before installing cq callbacks")
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/mlx5: Adding remote atomic access flag to updatable flags [+ + +]
Author: Or Har-Toov <[email protected]>
Date:   Wed Apr 3 13:36:01 2024 +0300

    RDMA/mlx5: Adding remote atomic access flag to updatable flags
    
    [ Upstream commit 2ca7e93bc963d9ec2f5c24d117176851454967af ]
    
    Currently IB_ACCESS_REMOTE_ATOMIC is blocked from being updated via UMR
    although in some cases it should be possible. These cases are checked in
    mlx5r_umr_can_reconfig function.
    
    Fixes: ef3642c4f54d ("RDMA/mlx5: Fix error unwinds for rereg_mr")
    Signed-off-by: Or Har-Toov <[email protected]>
    Link: https://lore.kernel.org/r/24dac73e2fa48cb806f33a932d97f3e402a5ea2c.1712140377.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/mlx5: Change check for cacheable mkeys [+ + +]
Author: Or Har-Toov <[email protected]>
Date:   Wed Apr 3 13:36:00 2024 +0300

    RDMA/mlx5: Change check for cacheable mkeys
    
    [ Upstream commit 8c1185fef68cc603b954fece2a434c9f851d6a86 ]
    
    umem can be NULL for user application mkeys in some cases. Therefore
    umem can't be used for checking if the mkey is cacheable and it is
    changed for checking a flag that indicates it. Also make sure that
    all mkeys which are not returned to the cache will be destroyed.
    
    Fixes: dd1b913fb0d0 ("RDMA/mlx5: Cache all user cacheable mkeys on dereg MR flow")
    Signed-off-by: Or Har-Toov <[email protected]>
    Link: https://lore.kernel.org/r/2690bc5c6896bcb937f89af16a1ff0343a7ab3d0.1712140377.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/mlx5: Uncacheable mkey has neither rb_key or cache_ent [+ + +]
Author: Or Har-Toov <[email protected]>
Date:   Wed Apr 3 13:35:59 2024 +0300

    RDMA/mlx5: Uncacheable mkey has neither rb_key or cache_ent
    
    [ Upstream commit 0611a8e8b475fc5230b9a24d29c8397aaab20b63 ]
    
    As some mkeys can't be modified with UMR due to some UMR limitations,
    like the size of translation that can be updated, not all user mkeys can
    be cached.
    
    Fixes: dd1b913fb0d0 ("RDMA/mlx5: Cache all user cacheable mkeys on dereg MR flow")
    Signed-off-by: Or Har-Toov <[email protected]>
    Link: https://lore.kernel.org/r/f2742dd934ed73b2d32c66afb8e91b823063880c.1712140377.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/rxe: Allow good work requests to be executed [+ + +]
Author: Bob Pearson <[email protected]>
Date:   Fri Mar 29 09:55:05 2024 -0500

    RDMA/rxe: Allow good work requests to be executed
    
    [ Upstream commit b703374837a8f8422fa3f1edcf65505421a65a6a ]
    
    A previous commit incorrectly added an 'if(!err)' before scheduling the
    requester task in rxe_post_send_kernel(). But if there were send wrs
    successfully added to the send queue before a bad wr they might never get
    executed.
    
    This commit fixes this by scheduling the requester task if any wqes were
    successfully posted in rxe_post_send_kernel() in rxe_verbs.c.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bob Pearson <[email protected]>
    Fixes: 5bf944f24129 ("RDMA/rxe: Add error messages")
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/rxe: Fix incorrect rxe_put in error path [+ + +]
Author: Bob Pearson <[email protected]>
Date:   Fri Mar 29 09:55:12 2024 -0500

    RDMA/rxe: Fix incorrect rxe_put in error path
    
    [ Upstream commit 8776618dbbd1b6f210b31509507e1aad461d6435 ]
    
    In rxe_send() a ref is taken on the qp to keep it alive until the
    kfree_skb() has a chance to call the skb destructor rxe_skb_tx_dtor()
    which drops the reference. If the packet has an incorrect protocol the
    error path just calls kfree_skb() which will call the destructor which
    will drop the ref. Currently the driver also calls rxe_put() which is
    incorrect. Additionally since the packets sent to rxe_send() are under the
    control of the driver and it only ever produces IPV4 or IPV6 packets the
    simplest fix is to remove all the code in this block.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bob Pearson <[email protected]>
    Fixes: 9eb7f8e44d13 ("IB/rxe: Move refcounting earlier in rxe_send()")
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt [+ + +]
Author: Bob Pearson <[email protected]>
Date:   Fri Mar 29 09:55:04 2024 -0500

    RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt
    
    [ Upstream commit 2b23b6097303ed0ba5f4bc036a1c07b6027af5c6 ]
    
    In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the
    resp_pkts queue and then a decision is made whether to run the completer
    task inline or schedule it. Finally the skb is dereferenced to bump a 'hw'
    performance counter. This is wrong because if the completer task is
    already running in a separate thread it may have already processed the skb
    and freed it which can cause a seg fault.  This has been observed
    infrequently in testing at high scale.
    
    This patch fixes this by changing the order of enqueuing the packet until
    after the counter is accessed.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bob Pearson <[email protected]>
    Fixes: 0b1e5b99a48b ("IB/rxe: Add port protocol stats")
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Reapply "arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD" [+ + +]
Author: Will Deacon <[email protected]>
Date:   Wed May 22 11:53:05 2024 +0100

    Reapply "arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD"
    
    commit f481bb32d60e45fb3d19ea68ce79c5629f3fc3a0 upstream.
    
    This reverts commit b8995a18417088bb53f87c49d200ec72a9dd4ec1.
    
    Ard managed to reproduce the dm-crypt corruption problem and got to the
    bottom of it, so re-apply the problematic patch in preparation for
    fixing things properly.
    
    Cc: [email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
regulator: irq_helpers: duplicate IRQ name [+ + +]
Author: Matti Vaittinen <[email protected]>
Date:   Sun Apr 7 10:35:21 2024 +0300

    regulator: irq_helpers: duplicate IRQ name
    
    [ Upstream commit 7ab681ddedd4b6dd2b047c74af95221c5f827e1d ]
    
    The regulator IRQ helper requires caller to provide pointer to IRQ name
    which is kept in memory by caller. All other data passed to the helper
    in the regulator_irq_desc structure is copied. This can cause some
    confusion and unnecessary complexity.
    
    Make the regulator_irq_helper() to copy also the provided IRQ name
    information so caller can discard the name after the call to
    regulator_irq_helper() completes.
    
    Signed-off-by: Matti Vaittinen <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

regulator: qcom-refgen: fix module autoloading [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Wed Apr 10 19:26:14 2024 +0200

    regulator: qcom-refgen: fix module autoloading
    
    [ Upstream commit ddd3f34c10002e41ed3cd89c9bd8f1d05a22506a ]
    
    Add MODULE_DEVICE_TABLE(), so the module could be properly autoloaded
    based on the alias from of_device_id table.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

regulator: vqmmc-ipq4019: fix module autoloading [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Wed Apr 10 19:26:15 2024 +0200

    regulator: vqmmc-ipq4019: fix module autoloading
    
    [ Upstream commit 68adb581a39ae63a0ed082c47f01fbbe515efa0e ]
    
    Add MODULE_DEVICE_TABLE(), so the module could be properly autoloaded
    based on the alias from of_device_id table.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD" [+ + +]
Author: Will Deacon <[email protected]>
Date:   Fri May 17 12:55:55 2024 +0100

    Revert "arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD"
    
    commit b8995a18417088bb53f87c49d200ec72a9dd4ec1 upstream.
    
    This reverts commit 2632e25217696712681dd1f3ecc0d71624ea3b23.
    
    Johannes (and others) report data corruption with dm-crypt on Apple M1
    which has been bisected to this change. Revert the offending commit
    while we figure out what's going on.
    
    Cc: [email protected]
    Reported-by: Johannes Nixdorf <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "net: txgbe: fix clk_name exceed MAX_DEV_ID limits" [+ + +]
Author: Duanqiang Wen <[email protected]>
Date:   Mon Apr 22 16:41:09 2024 +0800

    Revert "net: txgbe: fix clk_name exceed MAX_DEV_ID limits"
    
    [ Upstream commit edd2d250fb3bb5d70419ae82c1f9dbb9684dffd3 ]
    
    This reverts commit e30cef001da259e8df354b813015d0e5acc08740.
    commit 99f4570cfba1 ("clkdev: Update clkdev id usage to allow
    for longer names") can fix clk_name exceed MAX_DEV_ID limits,
    so this commit is meaningless.
    
    Signed-off-by: Duanqiang Wen <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Revert "net: txgbe: fix i2c dev name cannot match clkdev" [+ + +]
Author: Duanqiang Wen <[email protected]>
Date:   Mon Apr 22 16:41:08 2024 +0800

    Revert "net: txgbe: fix i2c dev name cannot match clkdev"
    
    [ Upstream commit 8d6bf83f6740ba52a59e25dad360e1e87ef47666 ]
    
    This reverts commit c644920ce9220d83e070f575a4df711741c07f07.
    when register i2c dev, txgbe shorten "i2c_designware" to "i2c_dw",
    will cause this i2c dev can't match platfom driver i2c_designware_platform.
    
    Signed-off-by: Duanqiang Wen <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "r8169: don't try to disable interrupts if NAPI is, scheduled already" [+ + +]
Author: Heiner Kallweit <[email protected]>
Date:   Wed May 15 08:18:01 2024 +0200

    Revert "r8169: don't try to disable interrupts if NAPI is, scheduled already"
    
    commit eabb8a9be1e4a12f3bf37ceb7411083e3775672d upstream.
    
    This reverts commit 7274c4147afbf46f45b8501edbdad6da8cd013b9.
    
    Ken reported that RTL8125b can lock up if gro_flush_timeout has the
    default value of 20000 and napi_defer_hard_irqs is set to 0.
    In this scenario device interrupts aren't disabled, what seems to
    trigger some silicon bug under heavy load. I was able to reproduce this
    behavior on RTL8168h. Fix this by reverting 7274c4147afb.
    
    Fixes: 7274c4147afb ("r8169: don't try to disable interrupts if NAPI is scheduled already")
    Cc: [email protected]
    Reported-by: Ken Milmore <[email protected]>
    Signed-off-by: Heiner Kallweit <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "sh: Handle calling csum_partial with misaligned data" [+ + +]
Author: Guenter Roeck <[email protected]>
Date:   Sun Mar 24 16:18:04 2024 -0700

    Revert "sh: Handle calling csum_partial with misaligned data"
    
    [ Upstream commit b5319c96292ff877f6b58d349acf0a9dc8d3b454 ]
    
    This reverts commit cadc4e1a2b4d20d0cc0e81f2c6ba0588775e54e5.
    
    Commit cadc4e1a2b4d ("sh: Handle calling csum_partial with misaligned
    data") causes bad checksum calculations on unaligned data. Reverting
    it fixes the problem.
    
        # Subtest: checksum
        # module: checksum_kunit
        1..5
        # test_csum_fixed_random_inputs: ASSERTION FAILED at lib/checksum_kunit.c:500
        Expected ( u64)result == ( u64)expec, but
            ( u64)result == 53378 (0xd082)
            ( u64)expec == 33488 (0x82d0)
        # test_csum_fixed_random_inputs: pass:0 fail:1 skip:0 total:1
        not ok 1 test_csum_fixed_random_inputs
        # test_csum_all_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:525
        Expected ( u64)result == ( u64)expec, but
            ( u64)result == 65281 (0xff01)
            ( u64)expec == 65280 (0xff00)
        # test_csum_all_carry_inputs: pass:0 fail:1 skip:0 total:1
        not ok 2 test_csum_all_carry_inputs
        # test_csum_no_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:573
        Expected ( u64)result == ( u64)expec, but
            ( u64)result == 65535 (0xffff)
            ( u64)expec == 65534 (0xfffe)
        # test_csum_no_carry_inputs: pass:0 fail:1 skip:0 total:1
        not ok 3 test_csum_no_carry_inputs
        # test_ip_fast_csum: pass:1 fail:0 skip:0 total:1
        ok 4 test_ip_fast_csum
        # test_csum_ipv6_magic: pass:1 fail:0 skip:0 total:1
        ok 5 test_csum_ipv6_magic
     # checksum: pass:2 fail:3 skip:0 total:5
     # Totals: pass:2 fail:3 skip:0 total:5
    not ok 22 checksum
    
    Fixes: cadc4e1a2b4d ("sh: Handle calling csum_partial with misaligned data")
    Signed-off-by: Guenter Roeck <[email protected]>
    Tested-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ring-buffer: Fix a race between readers and resize checks [+ + +]
Author: Petr Pavlu <[email protected]>
Date:   Fri May 17 15:40:08 2024 +0200

    ring-buffer: Fix a race between readers and resize checks
    
    commit c2274b908db05529980ec056359fae916939fdaa upstream.
    
    The reader code in rb_get_reader_page() swaps a new reader page into the
    ring buffer by doing cmpxchg on old->list.prev->next to point it to the
    new page. Following that, if the operation is successful,
    old->list.next->prev gets updated too. This means the underlying
    doubly-linked list is temporarily inconsistent, page->prev->next or
    page->next->prev might not be equal back to page for some page in the
    ring buffer.
    
    The resize operation in ring_buffer_resize() can be invoked in parallel.
    It calls rb_check_pages() which can detect the described inconsistency
    and stop further tracing:
    
    [  190.271762] ------------[ cut here ]------------
    [  190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0
    [  190.271789] Modules linked in: [...]
    [  190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1
    [  190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G            E      6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
    [  190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
    [  190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
    [  190.272023] Code: [...]
    [  190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206
    [  190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80
    [  190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700
    [  190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000
    [  190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720
    [  190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000
    [  190.272053] FS:  00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000
    [  190.272057] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0
    [  190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  190.272077] Call Trace:
    [  190.272098]  <TASK>
    [  190.272189]  ring_buffer_resize+0x2ab/0x460
    [  190.272199]  __tracing_resize_ring_buffer.part.0+0x23/0xa0
    [  190.272206]  tracing_resize_ring_buffer+0x65/0x90
    [  190.272216]  tracing_entries_write+0x74/0xc0
    [  190.272225]  vfs_write+0xf5/0x420
    [  190.272248]  ksys_write+0x67/0xe0
    [  190.272256]  do_syscall_64+0x82/0x170
    [  190.272363]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    [  190.272373] RIP: 0033:0x7f1bd657d263
    [  190.272381] Code: [...]
    [  190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [  190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263
    [  190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001
    [  190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000
    [  190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500
    [  190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002
    [  190.272412]  </TASK>
    [  190.272414] ---[ end trace 0000000000000000 ]---
    
    Note that ring_buffer_resize() calls rb_check_pages() only if the parent
    trace_buffer has recording disabled. Recent commit d78ab792705c
    ("tracing: Stop current tracer when resizing buffer") causes that it is
    now always the case which makes it more likely to experience this issue.
    
    The window to hit this race is nonetheless very small. To help
    reproducing it, one can add a delay loop in rb_get_reader_page():
    
     ret = rb_head_page_replace(reader, cpu_buffer->reader_page);
     if (!ret)
            goto spin;
     for (unsigned i = 0; i < 1U << 26; i++)  /* inserted delay loop */
            __asm__ __volatile__ ("" : : : "memory");
     rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list;
    
    .. and then run the following commands on the target system:
    
     echo 1 > /sys/kernel/tracing/events/sched/sched_switch/enable
     while true; do
            echo 16 > /sys/kernel/tracing/buffer_size_kb; sleep 0.1
            echo 8 > /sys/kernel/tracing/buffer_size_kb; sleep 0.1
     done &
     while true; do
            for i in /sys/kernel/tracing/per_cpu/*; do
                    timeout 0.1 cat $i/trace_pipe; sleep 0.2
            done
     done
    
    To fix the problem, make sure ring_buffer_resize() doesn't invoke
    rb_check_pages() concurrently with a reader operating on the same
    ring_buffer_per_cpu by taking its cpu_buffer->reader_lock.
    
    Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
    
    Cc: [email protected]
    Cc: Masami Hiramatsu <[email protected]>
    Cc: Mathieu Desnoyers <[email protected]>
    Fixes: 659f451ff213 ("ring-buffer: Add integrity check at end of iter read")
    Signed-off-by: Petr Pavlu <[email protected]>
    [ Fixed whitespace ]
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
riscv, bpf: make some atomic operations fully ordered [+ + +]
Author: Puranjay Mohan <[email protected]>
Date:   Sun May 5 20:16:33 2024 +0000

    riscv, bpf: make some atomic operations fully ordered
    
    [ Upstream commit 20a759df3bba35bf5c3ddec0c02ad69b603b584c ]
    
    The BPF atomic operations with the BPF_FETCH modifier along with
    BPF_XCHG and BPF_CMPXCHG are fully ordered but the RISC-V JIT implements
    all atomic operations except BPF_CMPXCHG with relaxed ordering.
    
    Section 8.1 of the "The RISC-V Instruction Set Manual Volume I:
    Unprivileged ISA" [1], titled, "Specifying Ordering of Atomic
    Instructions" says:
    
    | To provide more efficient support for release consistency [5], each
    | atomic instruction has two bits, aq and rl, used to specify additional
    | memory ordering constraints as viewed by other RISC-V harts.
    
    and
    
    | If only the aq bit is set, the atomic memory operation is treated as
    | an acquire access.
    | If only the rl bit is set, the atomic memory operation is treated as a
    | release access.
    |
    | If both the aq and rl bits are set, the atomic memory operation is
    | sequentially consistent.
    
    Fix this by setting both aq and rl bits as 1 for operations with
    BPF_FETCH and BPF_XCHG.
    
    [1] https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf
    
    Fixes: dd642ccb45ec ("riscv, bpf: Implement more atomic operations for RV64")
    Signed-off-by: Puranjay Mohan <[email protected]>
    Reviewed-by: Pu Lehui <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
riscv: T-Head: Test availability bit before enabling MAE errata [+ + +]
Author: Christoph Müllner <[email protected]>
Date:   Sun Apr 7 23:32:36 2024 +0200

    riscv: T-Head: Test availability bit before enabling MAE errata
    
    [ Upstream commit 65b71cc35cc6631cb0a5b24f961fe64c085cb40b ]
    
    T-Head's memory attribute extension (XTheadMae) (non-compatible
    equivalent of RVI's Svpbmt) is currently assumed for all T-Head harts.
    However, QEMU recently decided to drop acceptance of guests that write
    reserved bits in PTEs.
    As XTheadMae uses reserved bits in PTEs and Linux applies the MAE errata
    for all T-Head harts, this broke the Linux startup on QEMU emulations
    of the C906 emulation.
    
    This patch attempts to address this issue by testing the MAE-enable bit
    in the th.sxstatus CSR. This CSR is available in HW and can be
    emulated in QEMU.
    
    This patch also makes the XTheadMae probing mechanism reliable, because
    a test for the right combination of mvendorid, marchid, and mimpid
    is not sufficient to enable MAE.
    
    Reviewed-by: Conor Dooley <[email protected]>
    Signed-off-by: Christoph Müllner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: thead: Rename T-Head PBMT to MAE [+ + +]
Author: Christoph Müllner <[email protected]>
Date:   Sun Apr 7 23:32:35 2024 +0200

    riscv: thead: Rename T-Head PBMT to MAE
    
    [ Upstream commit 6179d4a213006491ff0d50073256f21fad22149b ]
    
    T-Head's vendor extension to set page attributes has the name
    MAE (memory attribute extension).
    Let's rename it, so it is clear what this referes to.
    
    Link: https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadmae.adoc
    Reviewed-by: Conor Dooley <[email protected]>
    Signed-off-by: Christoph Müllner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/bpf: Emit a barrier for BPF_FETCH instructions [+ + +]
Author: Ilya Leoshkevich <[email protected]>
Date:   Tue May 7 02:02:49 2024 +0200

    s390/bpf: Emit a barrier for BPF_FETCH instructions
    
    [ Upstream commit 68378982f0b21de02ac3c6a11e2420badefcb4bc ]
    
    BPF_ATOMIC_OP() macro documentation states that "BPF_ADD | BPF_FETCH"
    should be the same as atomic_fetch_add(), which is currently not the
    case on s390x: the serialization instruction "bcr 14,0" is missing.
    This applies to "and", "or" and "xor" variants too.
    
    s390x is allowed to reorder stores with subsequent fetches from
    different addresses, so code relying on BPF_FETCH acting as a barrier,
    for example:
    
      stw [%r0], 1
      afadd [%r1], %r2
      ldxw %r3, [%r4]
    
    may be broken. Fix it by emitting "bcr 14,0".
    
    Note that a separate serialization instruction is not needed for
    BPF_XCHG and BPF_CMPXCHG, because COMPARE AND SWAP performs
    serialization itself.
    
    Fixes: ba3b86b9cef0 ("s390/bpf: Implement new atomic ops")
    Reported-by: Puranjay Mohan <[email protected]>
    Closes: https://lore.kernel.org/bpf/[email protected]/
    Signed-off-by: Ilya Leoshkevich <[email protected]>
    Reviewed-by: Puranjay Mohan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/cio: fix tracepoint subchannel type field [+ + +]
Author: Peter Oberparleiter <[email protected]>
Date:   Tue Mar 26 17:04:56 2024 +0100

    s390/cio: fix tracepoint subchannel type field
    
    [ Upstream commit 8692a24d0fae19f674d51726d179ad04ba95d958 ]
    
    The subchannel-type field "st" of s390_cio_stsch and s390_cio_msch
    tracepoints is incorrectly filled with the subchannel-enabled SCHIB
    value "ena". Fix this by assigning the correct value.
    
    Fixes: d1de8633d96a ("s390 cio: Rewrite trace point class s390_class_schib")
    Reviewed-by: Heiko Carstens <[email protected]>
    Signed-off-by: Peter Oberparleiter <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/mm: Re-enable the shared zeropage for !PV and !skeys KVM guests [+ + +]
Author: David Hildenbrand <[email protected]>
Date:   Thu Apr 11 18:14:41 2024 +0200

    s390/mm: Re-enable the shared zeropage for !PV and !skeys KVM guests
    
    [ Upstream commit 06201e00ee3e4beacac48aab2b83eff64ebf0bc0 ]
    
    commit fa41ba0d08de ("s390/mm: avoid empty zero pages for KVM guests to
    avoid postcopy hangs") introduced an undesired side effect when combined
    with memory ballooning and VM migration: memory part of the inflated
    memory balloon will consume memory.
    
    Assuming we have a 100GiB VM and inflated the balloon to 40GiB. Our VM
    will consume ~60GiB of memory. If we now trigger a VM migration,
    hypervisors like QEMU will read all VM memory. As s390x does not support
    the shared zeropage, we'll end up allocating for all previously-inflated
    memory part of the memory balloon: 50 GiB. So we might easily
    (unexpectedly) crash the VM on the migration source.
    
    Even worse, hypervisors like QEMU optimize for zeropage migration to not
    consume memory on the migration destination: when migrating a
    "page full of zeroes", on the migration destination they check whether the
    target memory is already zero (by reading the destination memory) and avoid
    writing to the memory to not allocate memory: however, s390x will also
    allocate memory here, implying that also on the migration destination, we
    will end up allocating all previously-inflated memory part of the memory
    balloon.
    
    This is especially bad if actual memory overcommit was not desired, when
    memory ballooning is used for dynamic VM memory resizing, setting aside
    some memory during boot that can be added later on demand. Alternatives
    like virtio-mem that would avoid this issue are not yet available on
    s390x.
    
    There could be ways to optimize some cases in user space: before reading
    memory in an anonymous private mapping on the migration source, check via
    /proc/self/pagemap if anything is already populated. Similarly check on
    the migration destination before reading. While that would avoid
    populating tables full of shared zeropages on all architectures, it's
    harder to get right and performant, and requires user space changes.
    
    Further, with posctopy live migration we must place a page, so there,
    "avoid touching memory to avoid allocating memory" is not really
    possible. (Note that a previously we would have falsely inserted
    shared zeropages into processes using UFFDIO_ZEROPAGE where
    mm_forbids_zeropage() would have actually forbidden it)
    
    PV is currently incompatible with memory ballooning, and in the common
    case, KVM guests don't make use of storage keys. Instead of zapping
    zeropages when enabling storage keys / PV, that turned out to be
    problematic in the past, let's do exactly the same we do with KSM pages:
    trigger unsharing faults to replace the shared zeropages by proper
    anonymous folios.
    
    What about added latency when enabling storage kes? Having a lot of
    zeropages in applicable environments (PV, legacy guests, unittests) is
    unexpected. Further, KSM could today already unshare the zeropages
    and unmerging KSM pages when enabling storage kets would unshare the
    KSM-placed zeropages in the same way, resulting in the same latency.
    
    [ agordeev: Fixed sparse and checkpatch complaints and error handling ]
    
    Reviewed-by: Christian Borntraeger <[email protected]>
    Tested-by: Christian Borntraeger <[email protected]>
    Fixes: fa41ba0d08de ("s390/mm: avoid empty zero pages for KVM guests to avoid postcopy hangs")
    Signed-off-by: David Hildenbrand <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
samples/landlock: Fix incorrect free in populate_ruleset_net [+ + +]
Author: Ivanov Mikhail <[email protected]>
Date:   Tue Mar 26 17:56:25 2024 +0800

    samples/landlock: Fix incorrect free in populate_ruleset_net
    
    [ Upstream commit 42212936d9d811c7cf6efc4804747a6c417aafd4 ]
    
    Pointer env_port_name changes after strsep(). Memory allocated via
    strdup() will not be freed if landlock_add_rule() returns non-zero value.
    
    Fixes: 5e990dcef12e ("samples/landlock: Support TCP restrictions")
    Signed-off-by: Ivanov Mikhail <[email protected]>
    Reviewed-by: Konstantin Meskhidze <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mickaël Salaün <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sched/core: Fix incorrect initialization of the 'burst' parameter in cpu_max_write() [+ + +]
Author: Cheng Yu <[email protected]>
Date:   Wed Apr 24 21:24:38 2024 +0800

    sched/core: Fix incorrect initialization of the 'burst' parameter in cpu_max_write()
    
    [ Upstream commit 49217ea147df7647cb89161b805c797487783fc0 ]
    
    In the cgroup v2 CPU subsystem, assuming we have a
    cgroup named 'test', and we set cpu.max and cpu.max.burst:
    
        # echo 1000000 > /sys/fs/cgroup/test/cpu.max
        # echo 1000000 > /sys/fs/cgroup/test/cpu.max.burst
    
    then we check cpu.max and cpu.max.burst:
    
        # cat /sys/fs/cgroup/test/cpu.max
        1000000 100000
        # cat /sys/fs/cgroup/test/cpu.max.burst
        1000000
    
    Next we set cpu.max again and check cpu.max and
    cpu.max.burst:
    
        # echo 2000000 > /sys/fs/cgroup/test/cpu.max
        # cat /sys/fs/cgroup/test/cpu.max
        2000000 100000
    
        # cat /sys/fs/cgroup/test/cpu.max.burst
        1000
    
    ... we find that the cpu.max.burst value changed unexpectedly.
    
    In cpu_max_write(), the unit of the burst value returned
    by tg_get_cfs_burst() is microseconds, while in cpu_max_write(),
    the burst unit used for calculation should be nanoseconds,
    which leads to the bug.
    
    To fix it, get the burst value directly from tg->cfs_bandwidth.burst.
    
    Fixes: f4183717b370 ("sched/fair: Introduce the burstable CFS controller")
    Reported-by: Qixin Liao <[email protected]>
    Signed-off-by: Cheng Yu <[email protected]>
    Signed-off-by: Zhang Qiao <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Reviewed-by: Vincent Guittot <[email protected]>
    Tested-by: Vincent Guittot <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
sched/fair: Add EAS checks before updating root_domain::overutilized [+ + +]
Author: Shrikanth Hegde <[email protected]>
Date:   Thu Mar 7 14:27:23 2024 +0530

    sched/fair: Add EAS checks before updating root_domain::overutilized
    
    [ Upstream commit be3a51e68f2f1b17250ce40d8872c7645b7a2991 ]
    
    root_domain::overutilized is only used for EAS(energy aware scheduler)
    to decide whether to do load balance or not. It is not used if EAS
    not possible.
    
    Currently enqueue_task_fair and task_tick_fair accesses, sometime updates
    this field. In update_sd_lb_stats it is updated often. This causes cache
    contention due to true sharing and burns a lot of cycles. ::overload and
    ::overutilized are part of the same cacheline. Updating it often invalidates
    the cacheline. That causes access to ::overload to slow down due to
    false sharing. Hence add EAS check before accessing/updating this field.
    EAS check is optimized at compile time or it is a static branch.
    Hence it shouldn't cost much.
    
    With the patch, both enqueue_task_fair and newidle_balance don't show
    up as hot routines in perf profile.
    
      6.8-rc4:
      7.18%  swapper          [kernel.vmlinux]              [k] enqueue_task_fair
      6.78%  s                [kernel.vmlinux]              [k] newidle_balance
    
      +patch:
      0.14%  swapper          [kernel.vmlinux]              [k] enqueue_task_fair
      0.00%  swapper          [kernel.vmlinux]              [k] newidle_balance
    
    While at it: trace_sched_overutilized_tp expect that second argument to
    be bool. So do a int to bool conversion for that.
    
    Fixes: 2802bf3cd936 ("sched/fair: Add over-utilization/tipping point indicator")
    Signed-off-by: Shrikanth Hegde <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Reviewed-by: Qais Yousef <[email protected]>
    Reviewed-by: Srikar Dronamraju <[email protected]>
    Reviewed-by: Vincent Guittot <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

sched/fair: Allow disabling sched_balance_newidle with sched_relax_domain_level [+ + +]
Author: Vitalii Bursov <[email protected]>
Date:   Tue Apr 30 18:05:23 2024 +0300

    sched/fair: Allow disabling sched_balance_newidle with sched_relax_domain_level
    
    [ Upstream commit a1fd0b9d751f840df23ef0e75b691fc00cfd4743 ]
    
    Change relax_domain_level checks so that it would be possible
    to include or exclude all domains from newidle balancing.
    
    This matches the behavior described in the documentation:
    
      -1   no request. use system default or follow request of others.
       0   no search.
       1   search siblings (hyperthreads in a core).
    
    "2" enables levels 0 and 1, level_max excludes the last (level_max)
    level, and level_max+1 includes all levels.
    
    Fixes: 1d3504fcf560 ("sched, cpuset: customize sched domains, core")
    Signed-off-by: Vitalii Bursov <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Tested-by: Dietmar Eggemann <[email protected]>
    Reviewed-by: Vincent Guittot <[email protected]>
    Reviewed-by: Valentin Schneider <[email protected]>
    Link: https://lore.kernel.org/r/bd6de28e80073c79466ec6401cdeae78f0d4423d.1714488502.git.vitaly@bursov.com
    Signed-off-by: Sasha Levin <[email protected]>

 
sched/isolation: Fix boot crash when maxcpus < first housekeeping CPU [+ + +]
Author: Oleg Nesterov <[email protected]>
Date:   Sat Apr 13 16:17:46 2024 +0200

    sched/isolation: Fix boot crash when maxcpus < first housekeeping CPU
    
    [ Upstream commit 257bf89d84121280904800acd25cc2c444c717ae ]
    
    housekeeping_setup() checks cpumask_intersects(present, online) to ensure
    that the kernel will have at least one housekeeping CPU after smp_init(),
    but this doesn't work if the maxcpus= kernel parameter limits the number of
    processors available after bootup.
    
    For example, a kernel with "maxcpus=2 nohz_full=0-2" parameters crashes at
    boot time on a virtual machine with 4 CPUs.
    
    Change housekeeping_setup() to use cpumask_first_and() and check that the
    returned CPU number is valid and less than setup_max_cpus.
    
    Another corner case is "nohz_full=0" on a machine with a single CPU or with
    the maxcpus=1 kernel argument. In this case non_housekeeping_mask is empty
    and tick_nohz_full_setup() makes no sense. And indeed, the kernel hits the
    WARN_ON(tick_nohz_full_running) in tick_sched_do_timer().
    
    And how should the kernel interpret the "nohz_full=" parameter? It should
    be silently ignored, but currently cpulist_parse() happily returns the
    empty cpumask and this leads to the same problem.
    
    Change housekeeping_setup() to check cpumask_empty(non_housekeeping_mask)
    and do nothing in this case.
    
    Signed-off-by: Oleg Nesterov <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Reviewed-by: Phil Auld <[email protected]>
    Acked-by: Frederic Weisbecker <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
scsi: bfa: Ensure the copied buf is NUL terminated [+ + +]
Author: Bui Quang Minh <[email protected]>
Date:   Wed Apr 24 21:44:20 2024 +0700

    scsi: bfa: Ensure the copied buf is NUL terminated
    
    [ Upstream commit 13d0cecb4626fae67c00c84d3c7851f6b62f7df3 ]
    
    Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
    userspace to that buffer. Later, we use sscanf on this buffer but we don't
    ensure that the string is terminated inside the buffer, this can lead to
    OOB read when using sscanf. Fix this issue by using memdup_user_nul instead
    of memdup_user.
    
    Fixes: 9f30b674759b ("bfa: replace 2 kzalloc/copy_from_user by memdup_user")
    Signed-off-by: Bui Quang Minh <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: hpsa: Fix allocation size for Scsi_Host private data [+ + +]
Author: Yuri Karpov <[email protected]>
Date:   Tue Mar 12 20:04:47 2024 +0300

    scsi: hpsa: Fix allocation size for Scsi_Host private data
    
    [ Upstream commit 504e2bed5d50610c1836046c0c195b0a6dba9c72 ]
    
    struct Scsi_Host private data contains pointer to struct ctlr_info.
    
    Restore allocation of only 8 bytes to store pointer in struct Scsi_Host
    private data area.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: bbbd25499100 ("scsi: hpsa: Fix allocation size for scsi_host_alloc()")
    Signed-off-by: Yuri Karpov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: libsas: Fix the failure of adding phy with zero-address to port [+ + +]
Author: Xingui Yang <[email protected]>
Date:   Tue Mar 12 14:11:03 2024 +0000

    scsi: libsas: Fix the failure of adding phy with zero-address to port
    
    [ Upstream commit 06036a0a5db34642c5dbe22021a767141f010b7a ]
    
    As of commit 7d1d86518118 ("[SCSI] libsas: fix false positive 'device
    attached' conditions"), reset the phy->entacted_sas_addr address to a
    zero-address when the link rate is less than 1.5G.
    
    Currently we find that when a new device is attached, and the link rate is
    less than 1.5G, but the device type is not NO_DEVICE, for example: the link
    rate is SAS_PHY_RESET_IN_PROGRESS and the device type is stp. After setting
    the phy->entacted_sas_addr address to the zero address, the port will
    continue to be created for the phy with the zero-address, and other phys
    with the zero-address will be tried to be added to the new port:
    
    [562240.051197] sas: ex 500e004aaaaaaa1f phy19:U:0 attached: 0000000000000000 (no device)
    // phy19 is deleted but still on the parent port's phy_list
    [562240.062536] sas: ex 500e004aaaaaaa1f phy0 new device attached
    [562240.062616] sas: ex 500e004aaaaaaa1f phy00:U:5 attached: 0000000000000000 (stp)
    [562240.062680] port-7:7:0: trying to add phy phy-7:7:19 fails: it's already part of another port
    
    Therefore, it should be the same as sas_get_phy_attached_dev(). Only when
    device_type is SAS_PHY_UNUSED, sas_address is set to the 0 address.
    
    Fixes: 7d1d86518118 ("[SCSI] libsas: fix false positive 'device attached' conditions")
    Signed-off-by: Xingui Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qedf: Ensure the copied buf is NUL terminated [+ + +]
Author: Bui Quang Minh <[email protected]>
Date:   Wed Apr 24 21:44:21 2024 +0700

    scsi: qedf: Ensure the copied buf is NUL terminated
    
    [ Upstream commit d0184a375ee797eb657d74861ba0935b6e405c62 ]
    
    Currently, we allocate a count-sized kernel buffer and copy count from
    userspace to that buffer. Later, we use kstrtouint on this buffer but we
    don't ensure that the string is terminated inside the buffer, this can
    lead to OOB read when using kstrtouint. Fix this issue by using
    memdup_user_nul instead of memdup_user.
    
    Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.")
    Signed-off-by: Bui Quang Minh <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qla2xxx: Fix debugfs output for fw_resource_count [+ + +]
Author: Himanshu Madhani <[email protected]>
Date:   Fri Apr 26 02:00:56 2024 +0000

    scsi: qla2xxx: Fix debugfs output for fw_resource_count
    
    [ Upstream commit 998d09c5ef6183bd8137d1a892ba255b15978bb4 ]
    
    DebugFS output for fw_resource_count shows:
    
    estimate exchange used[0] high water limit [1945] n        estimate iocb2 used [0] high water limit [5141]
            estimate exchange2 used[0] high water limit [1945]
    
    Which shows incorrect display due to missing newline in seq_print().
    
    [mkp: fix checkpatch warning about space before newline]
    
    Fixes: 5f63a163ed2f ("scsi: qla2xxx: Fix exchange oversubscription for management commands")
    Signed-off-by: Himanshu Madhani <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: cdns-pltfrm: Perform read back after writing HCLKDIV [+ + +]
Author: Andrew Halaney <[email protected]>
Date:   Fri Mar 29 15:46:48 2024 -0500

    scsi: ufs: cdns-pltfrm: Perform read back after writing HCLKDIV
    
    [ Upstream commit b715c55daf598aac8fa339048e4ca8a0916b332e ]
    
    Currently, HCLKDIV is written to and then completed with an mb().
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring this
    bit has taken effect on the device is to perform a read back to force it to
    make it all the way to the device. This is documented in device-io.rst and
    a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure the bit hits the device. Because the mb()'s purpose
    wasn't to add extra ordering (on top of the ordering guaranteed by
    writel()/readl()), it can safely be removed.
    
    Fixes: d90996dae8e4 ("scsi: ufs: Add UFS platform driver for Cadence UFS")
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-6-181252004586@redhat.com
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: core: mcq: Fix ufshcd_mcq_sqe_search() [+ + +]
Author: Bart Van Assche <[email protected]>
Date:   Tue Apr 9 17:07:45 2024 -0700

    scsi: ufs: core: mcq: Fix ufshcd_mcq_sqe_search()
    
    [ Upstream commit 3c5d0dce8ce0a2781ac306b9ad1492b005ecbab5 ]
    
    Fix the calculation of the utrd pointer. This patch addresses the following
    Coverity complaint:
    
    CID 1538170: (#1 of 1): Extra sizeof expression (SIZEOF_MISMATCH)
    suspicious_pointer_arithmetic: Adding sq_head_slot * 32UL /* sizeof (struct
    utp_transfer_req_desc) */ to pointer hwq->sqe_base_addr of type struct
    utp_transfer_req_desc * is suspicious because adding an integral value to
    this pointer automatically scales that value by the size, 32 bytes, of the
    pointed-to type, struct utp_transfer_req_desc. Most likely, the
    multiplication by sizeof (struct utp_transfer_req_desc) in this expression
    is extraneous and should be eliminated.
    
    Cc: Bao D. Nguyen <[email protected]>
    Cc: Stanley Chu <[email protected]>
    Cc: Can Guo <[email protected]>
    Fixes: 8d7290348992 ("scsi: ufs: mcq: Add supporting functions for MCQ abort")
    Signed-off-by: Bart Van Assche <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: core: Perform read back after disabling interrupts [+ + +]
Author: Andrew Halaney <[email protected]>
Date:   Fri Mar 29 15:46:50 2024 -0500

    scsi: ufs: core: Perform read back after disabling interrupts
    
    [ Upstream commit e4a628877119bd40164a651d20321247b6f94a8b ]
    
    Currently, interrupts are cleared and disabled prior to registering the
    interrupt. An mb() is used to complete the clear/disable writes before the
    interrupt is registered.
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring these
    bits have taken effect on the device is to perform a read back to force it
    to make it all the way to the device. This is documented in device-io.rst
    and a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure these bits hit the device. Because the mb()'s
    purpose wasn't to add extra ordering (on top of the ordering guaranteed by
    writel()/readl()), it can safely be removed.
    
    Fixes: 199ef13cac7d ("scsi: ufs: avoid spurious UFS host controller interrupts")
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Reviewed-by: Can Guo <[email protected]>
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-8-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: core: Perform read back after disabling UIC_COMMAND_COMPL [+ + +]
Author: Andrew Halaney <[email protected]>
Date:   Fri Mar 29 15:46:51 2024 -0500

    scsi: ufs: core: Perform read back after disabling UIC_COMMAND_COMPL
    
    [ Upstream commit 4bf3855497b60765ca03b983d064b25e99b97657 ]
    
    Currently, the UIC_COMMAND_COMPL interrupt is disabled and a wmb() is used
    to complete the register write before any following writes.
    
    wmb() ensures the writes complete in that order, but completion doesn't
    mean that it isn't stored in a buffer somewhere. The recommendation for
    ensuring this bit has taken effect on the device is to perform a read back
    to force it to make it all the way to the device. This is documented in
    device-io.rst and a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure the bit hits the device. Because the wmb()'s
    purpose wasn't to add extra ordering (on top of the ordering guaranteed by
    writel()/readl()), it can safely be removed.
    
    Fixes: d75f7fe495cf ("scsi: ufs: reduce the interrupts for power mode change requests")
    Reviewed-by: Bart Van Assche <[email protected]>
    Reviewed-by: Can Guo <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-9-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: core: Perform read back after writing UTP_TASK_REQ_LIST_BASE_H [+ + +]
Author: Andrew Halaney <[email protected]>
Date:   Fri Mar 29 15:46:49 2024 -0500

    scsi: ufs: core: Perform read back after writing UTP_TASK_REQ_LIST_BASE_H
    
    [ Upstream commit 408e28086f1c7a6423efc79926a43d7001902fae ]
    
    Currently, the UTP_TASK_REQ_LIST_BASE_L/UTP_TASK_REQ_LIST_BASE_H regs are
    written to and then completed with an mb().
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring these
    bits have taken effect on the device is to perform a read back to force it
    to make it all the way to the device. This is documented in device-io.rst
    and a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure the bits hit the device. Because the mb()'s purpose
    wasn't to add extra ordering (on top of the ordering guaranteed by
    writel()/readl()), it can safely be removed.
    
    Fixes: 88441a8d355d ("scsi: ufs: core: Add hibernation callbacks")
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Reviewed-by: Can Guo <[email protected]>
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-7-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: qcom: Perform read back after writing CGC enable [+ + +]
Author: Andrew Halaney <[email protected]>
Date:   Fri Mar 29 15:46:47 2024 -0500

    scsi: ufs: qcom: Perform read back after writing CGC enable
    
    [ Upstream commit d9488511b3ac7eb48a91bc5eded7027525525e03 ]
    
    Currently, the CGC enable bit is written and then an mb() is used to ensure
    that completes before continuing.
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring this
    bit has taken effect on the device is to perform a read back to force it to
    make it all the way to the device. This is documented in device-io.rst and
    a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure the bit hits the device. Because the mb()'s purpose
    wasn't to add extra ordering (on top of the ordering guaranteed by
    writel()/readl()), it can safely be removed.
    
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Can Guo <[email protected]>
    Fixes: 81c0fc51b7a7 ("ufs-qcom: add support for Qualcomm Technologies Inc platforms")
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-5-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: qcom: Perform read back after writing REG_UFS_SYS1CLK_1US [+ + +]
Author: Andrew Halaney <[email protected]>
Date:   Fri Mar 29 15:46:44 2024 -0500

    scsi: ufs: qcom: Perform read back after writing REG_UFS_SYS1CLK_1US
    
    [ Upstream commit a862fafa263aea0f427d51aca6ff7fd9eeaaa8bd ]
    
    Currently after writing to REG_UFS_SYS1CLK_1US a mb() is used to ensure
    that write has gone through to the device.
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring this
    bit has taken effect on the device is to perform a read back to force it to
    make it all the way to the device. This is documented in device-io.rst and
    a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure the bit hits the device. Because the mb()'s purpose
    wasn't to add extra ordering (on top of the ordering guaranteed by
    writel()/readl()), it can safely be removed.
    
    Fixes: f06fcc7155dc ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations")
    Reviewed-by: Can Guo <[email protected]>
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-2-181252004586@redhat.com
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: qcom: Perform read back after writing reset bit [+ + +]
Author: Andrew Halaney <[email protected]>
Date:   Fri Mar 29 15:46:43 2024 -0500

    scsi: ufs: qcom: Perform read back after writing reset bit
    
    [ Upstream commit c4d28e06b0c94636f6e35d003fa9ebac0a94e1ae ]
    
    Currently, the reset bit for the UFS provided reset controller (used by its
    phy) is written to, and then a mb() happens to try and ensure that hit the
    device. Immediately afterwards a usleep_range() occurs.
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring this
    bit has taken effect on the device is to perform a read back to force it to
    make it all the way to the device. This is documented in device-io.rst and
    a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure the bit hits the device. By doing so and
    guaranteeing the ordering against the immediately following usleep_range(),
    the mb() can safely be removed.
    
    Fixes: 81c0fc51b7a7 ("ufs-qcom: add support for Qualcomm Technologies Inc platforms")
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Can Guo <[email protected]>
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-1-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: qcom: Perform read back after writing unipro mode [+ + +]
Author: Andrew Halaney <[email protected]>
Date:   Fri Mar 29 15:46:46 2024 -0500

    scsi: ufs: qcom: Perform read back after writing unipro mode
    
    [ Upstream commit 823150ecf04f958213cf3bf162187cd1a91c885c ]
    
    Currently, the QUNIPRO_SEL bit is written to and then an mb() is used to
    ensure that completes before continuing.
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring this
    bit has taken effect on the device is to perform a read back to force it to
    make it all the way to the device. This is documented in device-io.rst and
    a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    But, there's really no reason to even ensure completion before
    continuing. The only requirement here is that this write is ordered to this
    endpoint (which readl()/writel() guarantees already). For that reason the
    mb() can be dropped altogether without anything forcing completion.
    
    Fixes: f06fcc7155dc ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations")
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-4-181252004586@redhat.com
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/binderfs: use the Makefile's rules, not Make's implicit rules [+ + +]
Author: John Hubbard <[email protected]>
Date:   Thu May 2 18:58:20 2024 -0700

    selftests/binderfs: use the Makefile's rules, not Make's implicit rules
    
    [ Upstream commit 019baf635eb6ffe8d6c1343f81788f02a7e0ed98 ]
    
    First of all, in order to build with clang at all, one must first apply
    Valentin Obst's build fix for LLVM [1]. Once that is done, then when
    building with clang, via:
    
        make LLVM=1 -C tools/testing/selftests
    
    ...the following error occurs:
    
       clang: error: cannot specify -o when generating multiple output files
    
    This is because clang, unlike gcc, won't accept invocations of this
    form:
    
        clang file1.c header2.h
    
    While trying to fix this, I noticed that:
    
    a) selftests/lib.mk already avoids the problem, and
    
    b) The binderfs Makefile indavertently bypasses the selftests/lib.mk
    build system, and quitely uses Make's implicit build rules for .c files
    instead.
    
    The Makefile attempts to set up both a dependency and a source file,
    neither of which was needed, because lib.mk is able to automatically
    handle both. This line:
    
        binderfs_test: binderfs_test.c
    
    ...causes Make's implicit rules to run, which builds binderfs_test
    without ever looking at lib.mk.
    
    Fix this by simply deleting the "binderfs_test:" Makefile target and
    letting lib.mk handle it instead.
    
    [1] https://lore.kernel.org/all/20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c49f@valentinobst.de/
    
    Fixes: 6e29225af902 ("binderfs: port tests to test harness infrastructure")
    Cc: Christian Brauner <[email protected]>
    Signed-off-by: John Hubbard <[email protected]>
    Reviewed-by: Christian Brauner <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/bpf: Fix a fd leak in error paths in open_netns [+ + +]
Author: Geliang Tang <[email protected]>
Date:   Tue Apr 23 18:35:27 2024 +0800

    selftests/bpf: Fix a fd leak in error paths in open_netns
    
    [ Upstream commit 151f7442436658ee84076681d8f52e987fe147ea ]
    
    As Martin mentioned in review comment, there is an existing bug that
    orig_netns_fd will be leaked in the later "goto fail;" case after
    open("/proc/self/ns/net") in open_netns() in network_helpers.c. This
    patch adds "close(token->orig_netns_fd);" before "free(token);" to
    fix it.
    
    Fixes: a30338840fa5 ("selftests/bpf: Move open_netns() and close_netns() into network_helpers.c")
    Signed-off-by: Geliang Tang <[email protected]>
    Link: https://lore.kernel.org/r/a104040b47c3c34c67f3f125cdfdde244a870d3c.1713868264.git.tanggeliang@kylinos.cn
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix pointer arithmetic in test_xdp_do_redirect [+ + +]
Author: Michal Schmidt <[email protected]>
Date:   Mon May 6 16:50:22 2024 +0200

    selftests/bpf: Fix pointer arithmetic in test_xdp_do_redirect
    
    [ Upstream commit e549b39a0ab8880d7ae6c6495b00fc1cb8f36174 ]
    
    Cast operation has a higher precedence than addition. The code here
    wants to zero the 2nd half of the 64-bit metadata, but due to a pointer
    arithmetic mistake, it writes the zero at offset 16 instead.
    
    Just adding parentheses around "data + 4" would fix this, but I think
    this will be slightly better readable with array syntax.
    
    I was unable to test this with tools/testing/selftests/bpf/vmtest.sh,
    because my glibc is newer than glibc in the provided VM image.
    So I just checked the difference in the compiled code.
    objdump -S tools/testing/selftests/bpf/xdp_do_redirect.test.o:
      -     *((__u32 *)data) = 0x42; /* metadata test value */
      +     ((__u32 *)data)[0] = 0x42; /* metadata test value */
            be7:    48 8d 85 30 fc ff ff    lea    -0x3d0(%rbp),%rax
            bee:    c7 00 42 00 00 00       movl   $0x42,(%rax)
      -     *((__u32 *)data + 4) = 0;
      +     ((__u32 *)data)[1] = 0;
            bf4:    48 8d 85 30 fc ff ff    lea    -0x3d0(%rbp),%rax
      -     bfb:    48 83 c0 10             add    $0x10,%rax
      +     bfb:    48 83 c0 04             add    $0x4,%rax
            bff:    c7 00 00 00 00 00       movl   $0x0,(%rax)
    
    Fixes: 5640b6d89434 ("selftests/bpf: fix "metadata marker" getting overwritten by the netstack")
    Signed-off-by: Michal Schmidt <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Reviewed-by: Toke Høiland-Jørgensen <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix umount cgroup2 error in test_sockmap [+ + +]
Author: Geliang Tang <[email protected]>
Date:   Tue Apr 9 13:18:40 2024 +0800

    selftests/bpf: Fix umount cgroup2 error in test_sockmap
    
    [ Upstream commit d75142dbeb2bd1587b9cc19f841578f541275a64 ]
    
    This patch fixes the following "umount cgroup2" error in test_sockmap.c:
    
     (cgroup_helpers.c:353: errno: Device or resource busy) umount cgroup2
    
    Cgroup fd cg_fd should be closed before cleanup_cgroup_environment().
    
    Fixes: 13a5f3ffd202 ("bpf: Selftests, sockmap test prog run without setting cgroup")
    Signed-off-by: Geliang Tang <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Link: https://lore.kernel.org/r/0399983bde729708773416b8488bac2cd5e022b8.1712639568.git.tanggeliang@kylinos.cn
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Run cgroup1_hierarchy test in own mount namespace [+ + +]
Author: Viktor Malik <[email protected]>
Date:   Mon Apr 29 13:23:11 2024 +0200

    selftests/bpf: Run cgroup1_hierarchy test in own mount namespace
    
    [ Upstream commit 19468ed51488dae19254e8a67c75d583b05fa5e3 ]
    
    The cgroup1_hierarchy test uses setup_classid_environment to setup
    cgroupv1 environment. The problem is that the environment is set in
    /sys/fs/cgroup and therefore, if not run under an own mount namespace,
    effectively deletes all system cgroups:
    
        $ ls /sys/fs/cgroup | wc -l
        27
        $ sudo ./test_progs -t cgroup1_hierarchy
        #41/1    cgroup1_hierarchy/test_cgroup1_hierarchy:OK
        #41/2    cgroup1_hierarchy/test_root_cgid:OK
        #41/3    cgroup1_hierarchy/test_invalid_level:OK
        #41/4    cgroup1_hierarchy/test_invalid_cgid:OK
        #41/5    cgroup1_hierarchy/test_invalid_hid:OK
        #41/6    cgroup1_hierarchy/test_invalid_cgrp_name:OK
        #41/7    cgroup1_hierarchy/test_invalid_cgrp_name2:OK
        #41/8    cgroup1_hierarchy/test_sleepable_prog:OK
        #41      cgroup1_hierarchy:OK
        Summary: 1/8 PASSED, 0 SKIPPED, 0 FAILED
        $ ls /sys/fs/cgroup | wc -l
        1
    
    To avoid this, run setup_cgroup_environment first which will create an
    own mount namespace. This only affects the cgroupv1_hierarchy test as
    all other cgroup1 test progs already run setup_cgroup_environment prior
    to running setup_classid_environment.
    
    Also add a comment to the header of setup_classid_environment to warn
    against this invalid usage in future.
    
    Fixes: 360769233cc9 ("selftests/bpf: Add selftests for cgroup1 hierarchy")
    Signed-off-by: Viktor Malik <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/damon/_damon_sysfs: check errors from nr_schemes file reads [+ + +]
Author: SeongJae Park <[email protected]>
Date:   Fri May 3 11:03:10 2024 -0700

    selftests/damon/_damon_sysfs: check errors from nr_schemes file reads
    
    [ Upstream commit 732b8815c079199d29b0426d9372bb098c63cdc7 ]
    
    DAMON context staging method in _damon_sysfs.py is not checking the
    returned error from nr_schemes file read.  Check it.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: f5f0e5a2bef9 ("selftests/damon/_damon_sysfs: implement kdamonds start function")
    Signed-off-by: SeongJae Park <[email protected]>
    Cc: Jonathan Corbet <[email protected]>
    Cc: Shuah Khan <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/ftrace: Fix BTFARG testcase to check fprobe is enabled correctly [+ + +]
Author: Masami Hiramatsu (Google) <[email protected]>
Date:   Sat May 4 09:33:10 2024 +0900

    selftests/ftrace: Fix BTFARG testcase to check fprobe is enabled correctly
    
    commit 2fd3ef1b9265eda7f53b9506f1ebfb67eb6435a2 upstream.
    
    Since the dynevent/add_remove_btfarg.tc test case forgets to ensure that
    fprobe is enabled for some structure field access tests which uses the
    fprobe, it fails if CONFIG_FPROBE=n or CONFIG_FPROBE_EVENTS=n.
    Fixes it to ensure the fprobe events are supported.
    
    Fixes: d892d3d3d885 ("selftests/ftrace: Add BTF fields access testcases")
    Cc: [email protected]
    Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
selftests/kcmp: remove unused open mode [+ + +]
Author: Edward Liaw <[email protected]>
Date:   Mon Apr 29 23:46:09 2024 +0000

    selftests/kcmp: remove unused open mode
    
    [ Upstream commit eb59a58113717df04b8a8229befd8ab1e5dbf86e ]
    
    Android bionic warns that open modes are ignored if O_CREAT or O_TMPFILE
    aren't specified.  The permissions for the file are set above:
    
            fd1 = open(kpath, O_RDWR | O_CREAT | O_TRUNC, 0644);
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: d97b46a64674 ("syscalls, x86: add __NR_kcmp syscall")
    Signed-off-by: Edward Liaw <[email protected]>
    Reviewed-by: Cyrill Gorcunov <[email protected]>
    Cc: Eric Biederman <[email protected]>
    Cc: Shuah Khan <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/net/lib: no need to record ns name if it already exist [+ + +]
Author: Hangbin Liu <[email protected]>
Date:   Tue May 14 10:33:59 2024 +0800

    selftests/net/lib: no need to record ns name if it already exist
    
    [ Upstream commit 83e93942796db58652288f0391ac00072401816f ]
    
    There is no need to add the name to ns_list again if the netns already
    recoreded.
    
    Fixes: 25ae948b4478 ("selftests/net: add lib.sh")
    Signed-off-by: Hangbin Liu <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/resctrl: fix clang build failure: use LOCAL_HDRS [+ + +]
Author: John Hubbard <[email protected]>
Date:   Thu May 2 19:17:12 2024 -0700

    selftests/resctrl: fix clang build failure: use LOCAL_HDRS
    
    [ Upstream commit d8171aa4ca72f1a67bf3c14c59441d63c1d2585f ]
    
    First of all, in order to build with clang at all, one must first apply
    Valentin Obst's build fix for LLVM [1]. Once that is done, then when
    building with clang, via:
    
        make LLVM=1 -C tools/testing/selftests
    
    ...the following error occurs:
    
       clang: error: cannot specify -o when generating multiple output files
    
    This is because clang, unlike gcc, won't accept invocations of this
    form:
    
        clang file1.c header2.h
    
    Fix this by using selftests/lib.mk facilities for tracking local header
    file dependencies: add them to LOCAL_HDRS, leaving only the .c files to
    be passed to the compiler.
    
    [1] https://lore.kernel.org/all/20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c49f@valentinobst.de/
    
    Fixes: 8e289f454289 ("selftests/resctrl: Add resctrl.h into build deps")
    Cc: Ilpo Järvinen <[email protected]>
    Signed-off-by: John Hubbard <[email protected]>
    Acked-by: Reinette Chatre <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests: cgroup: skip test_cgcore_lesser_ns_open when cgroup2 mounted without nsdelegate [+ + +]
Author: Tianchen Ding <[email protected]>
Date:   Wed Mar 27 10:44:37 2024 +0800

    selftests: cgroup: skip test_cgcore_lesser_ns_open when cgroup2 mounted without nsdelegate
    
    [ Upstream commit 4793cb599b1bdc3d356f0374c2c99ffe890ae876 ]
    
    The test case test_cgcore_lesser_ns_open only tasks effect when cgroup2
    is mounted with "nsdelegate" mount option. If it misses this option, or
    is remounted without "nsdelegate", the test case will fail. For example,
    running bpf/test_cgroup_storage first, and then run cgroup/test_core will
    fail on test_cgcore_lesser_ns_open. Skip it if "nsdelegate" is not
    detected in cgroup2 mount options.
    
    Fixes: bf35a7879f1d ("selftests: cgroup: Test open-time cgroup namespace usage for migration checks")
    Signed-off-by: Tianchen Ding <[email protected]>
    Reviewed-by: Muhammad Usama Anjum <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: default to host arch for LLVM builds [+ + +]
Author: Valentin Obst <[email protected]>
Date:   Fri Mar 29 11:49:43 2024 +0100

    selftests: default to host arch for LLVM builds
    
    [ Upstream commit d4e6fbd245c48b272cc591d1c5e7c07aedd7f071 ]
    
    Align the behavior for gcc and clang builds by interpreting unset
    `ARCH` and `CROSS_COMPILE` variables in `LLVM` builds as a sign that the
    user wants to build for the host architecture.
    
    This patch preserves the properties that setting the `ARCH` variable to an
    unknown value will trigger an error that complains about insufficient
    information, and that a set `CROSS_COMPILE` variable will override the
    target triple that is determined based on presence/absence of `ARCH`.
    
    When compiling with clang, i.e., `LLVM` is set, an unset `ARCH` variable in
    combination with an unset `CROSS_COMPILE` variable, i.e., compiling for
    the host architecture, leads to compilation failures since `lib.mk` can
    not determine the clang target triple. In this case, the following error
    message is displayed for each subsystem that does not set `ARCH` in its
    own Makefile before including `lib.mk` (lines wrapped at 75 chrs):
    
      make[1]: Entering directory '/mnt/build/linux/tools/testing/selftests/
       sysctl'
      ../lib.mk:33: *** Specify CROSS_COMPILE or add '--target=' option to
       lib.mk.  Stop.
      make[1]: Leaving directory '/mnt/build/linux/tools/testing/selftests/
       sysctl'
    
    In the same scenario a gcc build would default to the host architecture,
    i.e., it would use plain `gcc`.
    
    Fixes: 795285ef2425 ("selftests: Fix clang cross compilation")
    Reviewed-by: Mark Brown <[email protected]>
    Signed-off-by: Valentin Obst <[email protected]>
    Reviewed-by: John Hubbard <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: net: add missing config for amt.sh [+ + +]
Author: Jakub Kicinski <[email protected]>
Date:   Thu May 9 09:19:19 2024 -0700

    selftests: net: add missing config for amt.sh
    
    [ Upstream commit c499fe96d3f75a5cf50de6089dd8f1cddd1301a9 ]
    
    Test needs IPv6 multicast. smcroute currently crashes when trying
    to install a route in a kernel without IPv6 multicast.
    
    Fixes: c08e8baea78e ("selftests: add amt interface selftest script")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: net: bridge: increase IGMP/MLD exclude timeout membership interval [+ + +]
Author: Nikolay Aleksandrov <[email protected]>
Date:   Mon May 13 13:52:57 2024 +0300

    selftests: net: bridge: increase IGMP/MLD exclude timeout membership interval
    
    [ Upstream commit 06080ea23095afe04a2cb7a8d05fab4311782623 ]
    
    When running the bridge IGMP/MLD selftests on debug kernels we can get
    spurious errors when setting up the IGMP/MLD exclude timeout tests
    because the membership interval is just 3 seconds and the setup has 2
    seconds of sleep plus various validations, the one second that is left
    is not enough. Increase the membership interval from 3 to 5 seconds to
    make room for the setup validation and 2 seconds of sleep.
    
    Fixes: 34d7ecb3d4f7 ("selftests: net: bridge: update IGMP/MLD membership interval value")
    Reported-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Nikolay Aleksandrov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: net: move amt to socat for better compatibility [+ + +]
Author: Jakub Kicinski <[email protected]>
Date:   Thu May 9 09:19:52 2024 -0700

    selftests: net: move amt to socat for better compatibility
    
    [ Upstream commit 4c639b6a7b9db236c0907aca8e92d1537076f2cd ]
    
    The test seems to expect that nc will exit after the first
    received message. This is not the case with Ncat 7.94.
    There are multiple versions of nc out there, switch
    to socat for better compatibility.
    
    Tell socat to exit after 128 bytes and pad the message.
    
    Since the test sets -e make sure we don't set exit code
    (|| true) and print the pass / fail rather then silently
    moving over the test and just setting non-zero exit code
    with no output indicating what failed.
    
    Fixes: c08e8baea78e ("selftests: add amt interface selftest script")
    Acked-by: Paolo Abeni<[email protected]>
    Tested-by: Taehee Yoo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: sud_test: return correct emulated syscall value on RISC-V [+ + +]
Author: Clément Léger <[email protected]>
Date:   Wed Dec 6 14:44:37 2023 +0100

    selftests: sud_test: return correct emulated syscall value on RISC-V
    
    [ Upstream commit 17c67ed752d6a456602b3dbb25c5ae4d3de5deab ]
    
    Currently, the sud_test expects the emulated syscall to return the
    emulated syscall number. This assumption only works on architectures
    were the syscall calling convention use the same register for syscall
    number/syscall return value. This is not the case for RISC-V and thus
    the return value must be also emulated using the provided ucontext.
    
    Signed-off-by: Clément Léger <[email protected]>
    Reviewed-by: Palmer Dabbelt <[email protected]>
    Acked-by: Palmer Dabbelt <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
serial: 8250_bcm7271: use default_mux_rate if possible [+ + +]
Author: Doug Berger <[email protected]>
Date:   Wed Apr 24 15:25:59 2024 -0700

    serial: 8250_bcm7271: use default_mux_rate if possible
    
    commit 614a19b89ca43449196a8af1afac7d55c6781687 upstream.
    
    There is a scenario when resuming from some power saving states
    with no_console_suspend where console output can be generated
    before the 8250_bcm7271 driver gets the opportunity to restore
    the baud_mux_clk frequency. Since the baud_mux_clk is at its
    default frequency at this time the output can be garbled until
    the driver gets the opportunity to resume.
    
    Since this is only an issue with console use of the serial port
    during that window and the console isn't likely to use baud
    rates that require alternate baud_mux_clk frequencies, allow the
    driver to select the default_mux_rate if it is accurate enough.
    
    Fixes: 41a469482de2 ("serial: 8250: Add new 8250-core based Broadcom STB driver")
    Cc: [email protected]
    Signed-off-by: Doug Berger <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: 8520_mtk: Set RTS on shutdown for Rx in-band wakeup [+ + +]
Author: Pin-yen Lin <[email protected]>
Date:   Wed Apr 24 20:58:08 2024 +0800

    serial: 8520_mtk: Set RTS on shutdown for Rx in-band wakeup
    
    commit 4244f830a56058ee0670d80e7ac9fd7c982eb480 upstream.
    
    When Rx in-band wakeup is enabled, set RTS to true in mtk8250_shutdown()
    so the connected device can still send message and trigger IRQ when the
    system is suspended.
    
    Fixes: 18c9d4a3c249 ("serial: When UART is suspended, set RTS to false")
    Cc: stable <[email protected]>
    Signed-off-by: Pin-yen Lin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: sc16is7xx: fix bug in sc16is7xx_set_baud() when using prescaler [+ + +]
Author: Hugo Villeneuve <[email protected]>
Date:   Tue Apr 30 16:04:30 2024 -0400

    serial: sc16is7xx: fix bug in sc16is7xx_set_baud() when using prescaler
    
    commit 8492bd91aa055907c67ef04f2b56f6dadd1f44bf upstream.
    
    When using a high speed clock with a low baud rate, the 4x prescaler is
    automatically selected if required. In that case, sc16is7xx_set_baud()
    properly configures the chip registers, but returns an incorrect baud
    rate by not taking into account the prescaler value. This incorrect baud
    rate is then fed to uart_update_timeout().
    
    For example, with an input clock of 80MHz, and a selected baud rate of 50,
    sc16is7xx_set_baud() will return 200 instead of 50.
    
    Fix this by first changing the prescaler variable to hold the selected
    prescaler value instead of the MCR bitfield. Then properly take into
    account the selected prescaler value in the return value computation.
    
    Also add better documentation about the divisor value computation.
    
    Fixes: dfeae619d781 ("serial: sc16is7xx")
    Cc: [email protected]
    Signed-off-by: Hugo Villeneuve <[email protected]>
    Reviewed-by: Jiri Slaby <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
sh: kprobes: Merge arch_copy_kprobe() into arch_prepare_kprobe() [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Fri Mar 1 22:02:30 2024 +0100

    sh: kprobes: Merge arch_copy_kprobe() into arch_prepare_kprobe()
    
    [ Upstream commit 1422ae080b66134fe192082d9b721ab7bd93fcc5 ]
    
    arch/sh/kernel/kprobes.c:52:16: warning: no previous prototype for 'arch_copy_kprobe' [-Wmissing-prototypes]
    
    Although SH kprobes support was only merged in v2.6.28, it missed the
    earlier removal of the arch_copy_kprobe() callback in v2.6.15.
    
    Based on the powerpc part of commit 49a2a1b83ba6fa40 ("[PATCH] kprobes:
    changed from using spinlock to mutex").
    
    Fixes: d39f5450146ff39f ("sh: Add kprobes support.")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
    Link: https://lore.kernel.org/r/717d47a19689cc944fae6e981a1ad7cae1642c89.1709326528.git.geert+renesas@glider.be
    Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
shmem: Fix shmem_rename2() [+ + +]
Author: Chuck Lever <[email protected]>
Date:   Mon Apr 15 11:20:56 2024 -0400

    shmem: Fix shmem_rename2()
    
    [ Upstream commit ad191eb6d6942bb835a0b20b647f7c53c1d99ca4 ]
    
    When renaming onto an existing directory entry, user space expects
    the replacement entry to have the same directory offset as the
    original one.
    
    Link: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15966
    Fixes: a2e459555c5f ("shmem: stable directory offsets")
    Signed-off-by: Chuck Lever <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
soc: mediatek: cmdq: Fix typo of CMDQ_JUMP_RELATIVE [+ + +]
Author: Chun-Kuang Hu <[email protected]>
Date:   Thu Feb 22 15:41:09 2024 +0000

    soc: mediatek: cmdq: Fix typo of CMDQ_JUMP_RELATIVE
    
    [ Upstream commit ed4d5ab179b9f0a60da87c650a31f1816db9b4b4 ]
    
    For cmdq jump command, offset 0 means relative jump and offset 1
    means absolute jump. cmdq_pkt_jump() is absolute jump, so fix the
    typo of CMDQ_JUMP_RELATIVE in cmdq_pkt_jump().
    
    Fixes: 946f1792d3d7 ("soc: mediatek: cmdq: add jump function")
    Signed-off-by: Chun-Kuang Hu <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

soc: qcom: pmic_glink: don't traverse clients list without a lock [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Apr 3 06:10:57 2024 +0300

    soc: qcom: pmic_glink: don't traverse clients list without a lock
    
    [ Upstream commit 635ce0db89567ba62f64b79e8c6664ba3eff6516 ]
    
    Take the client_lock before traversing the clients list at the
    pmic_glink_state_notify_clients() function. This is required to keep the
    list traversal safe from concurrent modification.
    
    Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Andrew Halaney <[email protected]>
    Reviewed-by: Mukesh Ojha <[email protected]>
    Tested-by: Xilin Wu <[email protected]> # on QCS8550 AYN Odin 2
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

soc: qcom: pmic_glink: Make client-lock non-sleeping [+ + +]
Author: Bjorn Andersson <[email protected]>
Date:   Tue Apr 30 20:38:57 2024 -0700

    soc: qcom: pmic_glink: Make client-lock non-sleeping
    
    [ Upstream commit 9329933699b32d467a99befa20415c4b2172389a ]
    
    The recently introduced commit '635ce0db8956 ("soc: qcom: pmic_glink:
    don't traverse clients list without a lock")' ensured that the clients
    list is not modified while traversed.
    
    But the callback is made from the GLINK IRQ handler and as such this
    mutual exclusion can not be provided by a (sleepable) mutex.
    
    Replace the mutex with a spinlock.
    
    Fixes: 635ce0db8956 ("soc: qcom: pmic_glink: don't traverse clients list without a lock")
    Signed-off-by: Bjorn Andersson <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/20240430-pmic-glink-sleep-while-atomic-v1-1-88fb493e8545@quicinc.com
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

soc: qcom: pmic_glink: notify clients about the current state [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Apr 3 06:10:58 2024 +0300

    soc: qcom: pmic_glink: notify clients about the current state
    
    [ Upstream commit d6cbce2cd354c9a37a558f290a8f1dfd20584f99 ]
    
    In case the client is registered after the pmic-glink recived a response
    from the Protection Domain mapper, it is going to miss the notification
    about the state. Notify clients about the current state upon
    registration.
    
    Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver")
    Reviewed-by: Andrew Halaney <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Mukesh Ojha <[email protected]>
    Tested-by: Xilin Wu <[email protected]> # on QCS8550 AYN Odin 2
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
softirq: Fix suspicious RCU usage in __do_softirq() [+ + +]
Author: Zqiang <[email protected]>
Date:   Sat Apr 27 18:28:08 2024 +0800

    softirq: Fix suspicious RCU usage in __do_softirq()
    
    [ Upstream commit 1dd1eff161bd55968d3d46bc36def62d71fb4785 ]
    
    Currently, the condition "__this_cpu_read(ksoftirqd) == current" is used to
    invoke rcu_softirq_qs() in ksoftirqd tasks context for non-RT kernels.
    
    This works correctly as long as the context is actually task context but
    this condition is wrong when:
    
         - the current task is ksoftirqd
         - the task is interrupted in a RCU read side critical section
         - __do_softirq() is invoked on return from interrupt
    
    Syzkaller triggered the following scenario:
    
      -> finish_task_switch()
        -> put_task_struct_rcu_user()
          -> call_rcu(&task->rcu, delayed_put_task_struct)
            -> __kasan_record_aux_stack()
              -> pfn_valid()
                -> rcu_read_lock_sched()
                  <interrupt>
                    __irq_exit_rcu()
                    -> __do_softirq)()
                       -> if (!IS_ENABLED(CONFIG_PREEMPT_RT) &&
                         __this_cpu_read(ksoftirqd) == current)
                         -> rcu_softirq_qs()
                           -> RCU_LOCKDEP_WARN(lock_is_held(&rcu_sched_lock_map))
    
    The rcu quiescent state is reported in the rcu-read critical section, so
    the lockdep warning is triggered.
    
    Fix this by splitting out the inner working of __do_softirq() into a helper
    function which takes an argument to distinguish between ksoftirqd task
    context and interrupted context and invoke it from the relevant call sites
    with the proper context information and use that for the conditional
    invocation of rcu_softirq_qs().
    
    Reported-by: [email protected]
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Zqiang <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/lkml/8f281a10-b85a-4586-9586-5bbc12dc784f@paulmck-laptop/T/#mea8aba4abfcb97bbf499d169ce7f30c4cff1b0e3
    Signed-off-by: Sasha Levin <[email protected]>

 
speakup: Fix sizeof() vs ARRAY_SIZE() bug [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Mon Apr 15 14:02:23 2024 +0300

    speakup: Fix sizeof() vs ARRAY_SIZE() bug
    
    commit 008ab3c53bc4f0b2f20013c8f6c204a3203d0b8b upstream.
    
    The "buf" pointer is an array of u16 values.  This code should be
    using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512),
    otherwise it can the still got out of bounds.
    
    Fixes: c8d2f34ea96e ("speakup: Avoid crash on very long word")
    Cc: [email protected]
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Samuel Thibault <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
staging: media: starfive: Remove links when unregistering devices [+ + +]
Author: Changhuang Liang <[email protected]>
Date:   Mon Mar 11 05:03:09 2024 -0700

    staging: media: starfive: Remove links when unregistering devices
    
    [ Upstream commit 810dd605e917c716f6f83e6cd8ea23d9155d32a2 ]
    
    Need to remove links when unregistering devices.
    
    Fixes: ac7da4a73b10 ("media: staging: media: starfive: camss: Register devices")
    
    Signed-off-by: Changhuang Liang <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
SUNRPC: Fix gss_free_in_token_pages() [+ + +]
Author: Chuck Lever <[email protected]>
Date:   Tue May 7 09:10:41 2024 -0400

    SUNRPC: Fix gss_free_in_token_pages()
    
    [ Upstream commit bafa6b4d95d97877baa61883ff90f7e374427fae ]
    
    Dan Carpenter says:
    > Commit 5866efa8cbfb ("SUNRPC: Fix svcauth_gss_proxy_init()") from Oct
    > 24, 2019 (linux-next), leads to the following Smatch static checker
    > warning:
    >
    >       net/sunrpc/auth_gss/svcauth_gss.c:1039 gss_free_in_token_pages()
    >       warn: iterator 'i' not incremented
    >
    > net/sunrpc/auth_gss/svcauth_gss.c
    >     1034 static void gss_free_in_token_pages(struct gssp_in_token *in_token)
    >     1035 {
    >     1036         u32 inlen;
    >     1037         int i;
    >     1038
    > --> 1039         i = 0;
    >     1040         inlen = in_token->page_len;
    >     1041         while (inlen) {
    >     1042                 if (in_token->pages[i])
    >     1043                         put_page(in_token->pages[i]);
    >                                                          ^
    > This puts page zero over and over.
    >
    >     1044                 inlen -= inlen > PAGE_SIZE ? PAGE_SIZE : inlen;
    >     1045         }
    >     1046
    >     1047         kfree(in_token->pages);
    >     1048         in_token->pages = NULL;
    >     1049 }
    
    Based on the way that the ->pages[] array is constructed in
    gss_read_proxy_verf(), we know that once the loop encounters a NULL
    page pointer, the remaining array elements must also be NULL.
    
    Reported-by: Dan Carpenter <[email protected]>
    Suggested-by: Trond Myklebust <[email protected]>
    Fixes: 5866efa8cbfb ("SUNRPC: Fix svcauth_gss_proxy_init()")
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sunrpc: removed redundant procp check [+ + +]
Author: Aleksandr Aprelkov <[email protected]>
Date:   Wed Mar 27 14:10:44 2024 +0700

    sunrpc: removed redundant procp check
    
    [ Upstream commit a576f36971ab4097b6aa76433532aa1fb5ee2d3b ]
    
    since vs_proc pointer is dereferenced before getting it's address there's
    no need to check for NULL.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 8e5b67731d08 ("SUNRPC: Add a callback to initialise server requests")
    Signed-off-by: Aleksandr Aprelkov <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

sunrpc: use the struct net as the svc proc private [+ + +]
Author: Josef Bacik <[email protected]>
Date:   Fri Jan 26 10:39:44 2024 -0500

    sunrpc: use the struct net as the svc proc private
    
    commit 418b9687dece5bd763c09b5c27a801a7e3387be9 upstream.
    
    nfsd is the only thing using this helper, and it doesn't use the private
    currently.  When we switch to per-network namespace stats we will need
    the struct net * in order to get to the nfsd_net.  Use the net as the
    proc private so we can utilize this when we make the switch over.
    
    Signed-off-by: Josef Bacik <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
 
tcp: avoid premature drops in tcp_add_backlog() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue Apr 23 12:56:20 2024 +0000

    tcp: avoid premature drops in tcp_add_backlog()
    
    [ Upstream commit ec00ed472bdb7d0af840da68c8c11bff9f4d9caa ]
    
    While testing TCP performance with latest trees,
    I saw suspect SOCKET_BACKLOG drops.
    
    tcp_add_backlog() computes its limit with :
    
        limit = (u32)READ_ONCE(sk->sk_rcvbuf) +
                (u32)(READ_ONCE(sk->sk_sndbuf) >> 1);
        limit += 64 * 1024;
    
    This does not take into account that sk->sk_backlog.len
    is reset only at the very end of __release_sock().
    
    Both sk->sk_backlog.len and sk->sk_rmem_alloc could reach
    sk_rcvbuf in normal conditions.
    
    We should double sk->sk_rcvbuf contribution in the formula
    to absorb bubbles in the backlog, which happen more often
    for very fast flows.
    
    This change maintains decent protection against abuses.
    
    Fixes: c377411f2494 ("net: sk_add_backlog() take rmem_alloc into account")
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

tcp: increase the default TCP scaling ratio [+ + +]
Author: Hechao Li <[email protected]>
Date:   Tue Apr 9 09:43:55 2024 -0700

    tcp: increase the default TCP scaling ratio
    
    [ Upstream commit 697a6c8cec03c2299f850fa50322641a8bf6b915 ]
    
    After commit dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale"),
    we noticed an application-level timeout due to reduced throughput.
    
    Before the commit, for a client that sets SO_RCVBUF to 65k, it takes
    around 22 seconds to transfer 10M data. After the commit, it takes 40
    seconds. Because our application has a 30-second timeout, this
    regression broke the application.
    
    The reason that it takes longer to transfer data is that
    tp->scaling_ratio is initialized to a value that results in ~0.25 of
    rcvbuf. In our case, SO_RCVBUF is set to 65536 by the application, which
    translates to 2 * 65536 = 131,072 bytes in rcvbuf and hence a ~28k
    initial receive window.
    
    Later, even though the scaling_ratio is updated to a more accurate
    skb->len/skb->truesize, which is ~0.66 in our environment, the window
    stays at ~0.25 * rcvbuf. This is because tp->window_clamp does not
    change together with the tp->scaling_ratio update when autotuning is
    disabled due to SO_RCVBUF. As a result, the window size is capped at the
    initial window_clamp, which is also ~0.25 * rcvbuf, and never grows
    bigger.
    
    Most modern applications let the kernel do autotuning, and benefit from
    the increased scaling_ratio. But there are applications such as kafka
    that has a default setting of SO_RCVBUF=64k.
    
    This patch increases the initial scaling_ratio from ~25% to 50% in order
    to make it backward compatible with the original default
    sysctl_tcp_adv_win_scale for applications setting SO_RCVBUF.
    
    Fixes: dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale")
    Signed-off-by: Hechao Li <[email protected]>
    Reviewed-by: Tycho Andersen <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
thermal/debugfs: Avoid excessive updates of trip point statistics [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Wed Apr 17 15:09:46 2024 +0200

    thermal/debugfs: Avoid excessive updates of trip point statistics
    
    [ Upstream commit 0a293c77580581c4b058eb40287acadac6ffd14a ]
    
    Since thermal_debug_update_temp() is called before invoking
    thermal_debug_tz_trip_down() for the trips that were crossed by the
    zone temperature on the way up, it updates the statistics for them
    as though the current zone temperature was above the low temperature
    of each of them.  However, if a given trip has just been crossed on the
    way down, the zone temperature is in fact below its low temperature,
    but this is handled by thermal_debug_tz_trip_down() running after the
    update of the trip statistics.
    
    The remedy is to call thermal_debug_update_temp() after
    thermal_debug_tz_trip_down() has been invoked for all of the
    trips in question, but then thermal_debug_tz_trip_up() needs to
    be adjusted, so it does not update the statistics for the trips
    that has just been crossed on the way up, as that will be taken
    care of by thermal_debug_update_temp() down the road.
    
    Modify the code accordingly.
    
    Fixes: 7ef01f228c9f ("thermal/debugfs: Add thermal debugfs information for mitigation episodes")
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Lukasz Luba <[email protected]>
    Acked-by: Daniel Lezcano <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

thermal/debugfs: Create records for cdev states as they get used [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Thu Apr 25 14:24:10 2024 +0200

    thermal/debugfs: Create records for cdev states as they get used
    
    [ Upstream commit f4ae18fcb652c6cccc834ded525ac37f91d5cdb1 ]
    
    Because thermal_debug_cdev_state_update() only creates a duration record
    for the old state of a cooling device, if its new state is used for the
    first time, there will be no record for it and cdev_dt_seq_show() will
    not print the duration information for it even though it contains code
    to compute the duration value in that case.
    
    Address this by making thermal_debug_cdev_state_update() create a
    duration record for the new state if there is none.
    
    Fixes: 755113d76786 ("thermal/debugfs: Add thermal cooling device debugfs information")
    Reported-by: Lukasz Luba <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Lukasz Luba <[email protected]>
    Tested-by: Lukasz Luba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

thermal/debugfs: Pass cooling device state to thermal_debug_cdev_add() [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Thu Apr 25 14:24:20 2024 +0200

    thermal/debugfs: Pass cooling device state to thermal_debug_cdev_add()
    
    [ Upstream commit 31a0fa0019b022024cc082ae292951a596b06f8c ]
    
    If cdev_dt_seq_show() runs before the first state transition of a cooling
    device, it will not print any state residency information for it, even
    though it might be reasonably expected to print residency information for
    the initial state of the cooling device.
    
    For this reason, rearrange the code to get the initial state of a cooling
    device at the registration time and pass it to thermal_debug_cdev_add(),
    so that the latter can create a duration record for that state which will
    allow cdev_dt_seq_show() to print its residency information.
    
    Fixes: 755113d76786 ("thermal/debugfs: Add thermal cooling device debugfs information")
    Reported-by: Lukasz Luba <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Lukasz Luba <[email protected]>
    Tested-by: Lukasz Luba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
thermal/drivers/mediatek/lvts_thermal: Add coeff for mt8192 [+ + +]
Author: Hsin-Te Yuan <[email protected]>
Date:   Tue Apr 16 07:35:47 2024 +0000

    thermal/drivers/mediatek/lvts_thermal: Add coeff for mt8192
    
    [ Upstream commit 7954c92ede882b0dfd52a5db90291a4151b44c1a ]
    
    In order for lvts_raw_to_temp to function properly on mt8192,
    temperature coefficients for mt8192 need to be added.
    
    Fixes: 288732242db4 ("thermal/drivers/mediatek/lvts_thermal: Add mt8192 support")
    Signed-off-by: Hsin-Te Yuan <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
thermal/drivers/tsens: Fix null pointer dereference [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Thu Apr 11 14:40:21 2024 +0300

    thermal/drivers/tsens: Fix null pointer dereference
    
    [ Upstream commit d998ddc86a27c92140b9f7984ff41e3d1d07a48f ]
    
    compute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c)
    as compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to null
    pointer dereference (if DEBUG or DYNAMIC_DEBUG set).
    Fix this bug by adding null pointer check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: dfc1193d4dbd ("thermal/drivers/tsens: Replace custom 8960 apis with generic apis")
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
tools/latency-collector: Fix -Wformat-security compile warns [+ + +]
Author: Shuah Khan <[email protected]>
Date:   Wed Apr 3 19:10:09 2024 -0600

    tools/latency-collector: Fix -Wformat-security compile warns
    
    commit df73757cf8f66fa54c4721c53b0916af3c4d9818 upstream.
    
    Fix the following -Wformat-security compile warnings adding missing
    format arguments:
    
    latency-collector.c: In function ‘show_available’:
    latency-collector.c:938:17: warning: format not a string literal and
    no format arguments [-Wformat-security]
      938 |                 warnx(no_tracer_msg);
          |                 ^~~~~
    
    latency-collector.c:943:17: warning: format not a string literal and
    no format arguments [-Wformat-security]
      943 |                 warnx(no_latency_tr_msg);
          |                 ^~~~~
    
    latency-collector.c: In function ‘find_default_tracer’:
    latency-collector.c:986:25: warning: format not a string literal and
    no format arguments [-Wformat-security]
      986 |                         errx(EXIT_FAILURE, no_tracer_msg);
          |
                             ^~~~
    latency-collector.c: In function ‘scan_arguments’:
    latency-collector.c:1881:33: warning: format not a string literal and
    no format arguments [-Wformat-security]
     1881 |                                 errx(EXIT_FAILURE, no_tracer_msg);
          |                                 ^~~~
    
    Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
    
    Cc: [email protected]
    Fixes: e23db805da2df ("tracing/tools: Add the latency-collector to tools directory")
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tools/nolibc/stdlib: fix memory error in realloc() [+ + +]
Author: Brennan Xavier McManus <[email protected]>
Date:   Tue Jan 9 18:44:02 2024 -0500

    tools/nolibc/stdlib: fix memory error in realloc()
    
    commit 791f4641142e2aced85de082e5783b4fb0b977c2 upstream.
    
    Pass user_p_len to memcpy() instead of heap->len to prevent realloc()
    from copying an extra sizeof(heap) bytes from beyond the allocated
    region.
    
    Signed-off-by: Brennan Xavier McManus <[email protected]>
    Cc: [email protected]
    Reviewed-by: Ammar Faizi <[email protected]>
    Fixes: 0e0ff638400be8f497a35b51a4751fd823f6bd6a ("tools/nolibc/stdlib: Implement `malloc()`, `calloc()`, `realloc()` and `free()`")
    Signed-off-by: Willy Tarreau <[email protected]>
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tracing/user_events: Fix non-spaced field matching [+ + +]
Author: Beau Belgrave <[email protected]>
Date:   Tue Apr 23 16:23:37 2024 +0000

    tracing/user_events: Fix non-spaced field matching
    
    [ Upstream commit bd125a084091396f3e796bb3dc009940d9771811 ]
    
    When the ABI was updated to prevent same name w/different args, it
    missed an important corner case when fields don't end with a space.
    Typically, space is used for fields to help separate them, like
    "u8 field1; u8 field2". If no spaces are used, like
    "u8 field1;u8 field2", then the parsing works for the first time.
    However, the match check fails on a subsequent register, leading to
    confusion.
    
    This is because the match check uses argv_split() and assumes that all
    fields will be split upon the space. When spaces are used, we get back
    { "u8", "field1;" }, without spaces we get back { "u8", "field1;u8" }.
    This causes a mismatch, and the user program gets back -EADDRINUSE.
    
    Add a method to detect this case before calling argv_split(). If found
    force a space after the field separator character ';'. This ensures all
    cases work properly for matching.
    
    With this fix, the following are all treated as matching:
    u8 field1;u8 field2
    u8 field1; u8 field2
    u8 field1;\tu8 field2
    u8 field1;\nu8 field2
    
    Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
    
    Fixes: ba470eebc2f6 ("tracing/user_events: Prevent same name but different args event")
    Signed-off-by: Beau Belgrave <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

tracing/user_events: Prepare find/delete for same name events [+ + +]
Author: Beau Belgrave <[email protected]>
Date:   Thu Feb 22 00:18:04 2024 +0000

    tracing/user_events: Prepare find/delete for same name events
    
    [ Upstream commit 1e953de9e9b4ca77a9ce0fc17a0778eba3a4ca64 ]
    
    The current code for finding and deleting events assumes that there will
    never be cases when user_events are registered with the same name, but
    different formats. Scenarios exist where programs want to use the same
    name but have different formats. An example is multiple versions of a
    program running side-by-side using the same event name, but with updated
    formats in each version.
    
    This change does not yet allow for multi-format events. If user_events
    are registered with the same name but different arguments the programs
    see the same return values as before. This change simply makes it
    possible to easily accommodate for this.
    
    Update find_user_event() to take in argument parameters and register
    flags to accommodate future multi-format event scenarios. Have find
    validate argument matching and return error pointers to cover when
    an existing event has the same name but different format. Update
    callers to handle error pointer logic.
    
    Move delete_user_event() to use hash walking directly now that
    find_user_event() has changed. Delete all events found that match the
    register name, stop if an error occurs and report back to the user.
    
    Update user_fields_match() to cover list_empty() scenarios now that
    find_user_event() uses it directly. This makes the logic consistent
    across several callsites.
    
    Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
    
    Signed-off-by: Beau Belgrave <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Stable-dep-of: bd125a084091 ("tracing/user_events: Fix non-spaced field matching")
    Signed-off-by: Sasha Levin <[email protected]>

 
tty: n_gsm: fix missing receive state reset after mode switch [+ + +]
Author: Daniel Starke <[email protected]>
Date:   Wed Apr 24 07:48:42 2024 +0200

    tty: n_gsm: fix missing receive state reset after mode switch
    
    commit 70d7f1427afcf7fa2d21cb5a04c6f3555d5b9357 upstream.
    
    The current implementation uses either gsm0_receive() or gsm1_receive()
    depending on whether the user configured the mux in basic or advanced
    option mode. Both functions share some state values over the same logical
    elements of the frame. However, both frame types differ in their nature.
    gsm0_receive() uses non-transparency framing, whereas gsm1_receive() uses
    transparency mechanism. Switching between both modes leaves the receive
    function in an undefined state when done during frame reception.
    
    Fix this by splitting both states. Add gsm0_receive_state_check_and_fix()
    and gsm1_receive_state_check_and_fix() to ensure that gsm->state is reset
    after a change of gsm->receive.
    
    Note that gsm->state is only accessed in:
    - gsm0_receive()
    - gsm1_receive()
    - gsm_error()
    
    Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
    Cc: [email protected]
    Signed-off-by: Daniel Starke <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: n_gsm: fix possible out-of-bounds in gsm0_receive() [+ + +]
Author: Daniel Starke <[email protected]>
Date:   Wed Apr 24 07:48:41 2024 +0200

    tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
    
    commit 47388e807f85948eefc403a8a5fdc5b406a65d5a upstream.
    
    Assuming the following:
    - side A configures the n_gsm in basic option mode
    - side B sends the header of a basic option mode frame with data length 1
    - side A switches to advanced option mode
    - side B sends 2 data bytes which exceeds gsm->len
      Reason: gsm->len is not used in advanced option mode.
    - side A switches to basic option mode
    - side B keeps sending until gsm0_receive() writes past gsm->buf
      Reason: Neither gsm->state nor gsm->len have been reset after
      reconfiguration.
    
    Fix this by changing gsm->count to gsm->len comparison from equal to less
    than. Also add upper limit checks against the constant MAX_MRU in
    gsm0_receive() and gsm1_receive() to harden against memory corruption of
    gsm->len and gsm->mru.
    
    All other checks remain as we still need to limit the data according to the
    user configuration and actual payload size.
    
    Reported-by: [email protected]
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218708
    Tested-by: [email protected]
    Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
    Cc: [email protected]
    Signed-off-by: Daniel Starke <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
udp: Avoid call to compute_score on multiple sites [+ + +]
Author: Gabriel Krisman Bertazi <[email protected]>
Date:   Fri Apr 12 17:20:04 2024 -0400

    udp: Avoid call to compute_score on multiple sites
    
    [ Upstream commit 50aee97d15113b95a68848db1f0cb2a6c09f753a ]
    
    We've observed a 7-12% performance regression in iperf3 UDP ipv4 and
    ipv6 tests with multiple sockets on Zen3 cpus, which we traced back to
    commit f0ea27e7bfe1 ("udp: re-score reuseport groups when connected
    sockets are present").  The failing tests were those that would spawn
    UDP sockets per-cpu on systems that have a high number of cpus.
    
    Unsurprisingly, it is not caused by the extra re-scoring of the reused
    socket, but due to the compiler no longer inlining compute_score, once
    it has the extra call site in udp4_lib_lookup2.  This is augmented by
    the "Safe RET" mitigation for SRSO, needed in our Zen3 cpus.
    
    We could just explicitly inline it, but compute_score() is quite a large
    function, around 300b.  Inlining in two sites would almost double
    udp4_lib_lookup2, which is a silly thing to do just to workaround a
    mitigation.  Instead, this patch shuffles the code a bit to avoid the
    multiple calls to compute_score.  Since it is a static function used in
    one spot, the compiler can safely fold it in, as it did before, without
    increasing the text size.
    
    With this patch applied I ran my original iperf3 testcases.  The failing
    cases all looked like this (ipv4):
            iperf3 -c 127.0.0.1 --udp -4 -f K -b $R -l 8920 -t 30 -i 5 -P 64 -O 2
    
    where $R is either 1G/10G/0 (max, unlimited).  I ran 3 times each.
    baseline is v6.9-rc3. harmean == harmonic mean; CV == coefficient of
    variation.
    
    ipv4:
                     1G                10G                  MAX
                HARMEAN  (CV)      HARMEAN  (CV)    HARMEAN     (CV)
    baseline 1743852.66(0.0208) 1725933.02(0.0167) 1705203.78(0.0386)
    patched  1968727.61(0.0035) 1962283.22(0.0195) 1923853.50(0.0256)
    
    ipv6:
                     1G                10G                  MAX
                HARMEAN  (CV)      HARMEAN  (CV)    HARMEAN     (CV)
    baseline 1729020.03(0.0028) 1691704.49(0.0243) 1692251.34(0.0083)
    patched  1900422.19(0.0067) 1900968.01(0.0067) 1568532.72(0.1519)
    
    This restores the performance we had before the change above with this
    benchmark.  We obviously don't expect any real impact when mitigations
    are disabled, but just to be sure it also doesn't regresses:
    
    mitigations=off ipv4:
                     1G                10G                  MAX
                HARMEAN  (CV)      HARMEAN  (CV)    HARMEAN     (CV)
    baseline 3230279.97(0.0066) 3229320.91(0.0060) 2605693.19(0.0697)
    patched  3242802.36(0.0073) 3239310.71(0.0035) 2502427.19(0.0882)
    
    Cc: Lorenz Bauer <[email protected]>
    Fixes: f0ea27e7bfe1 ("udp: re-score reuseport groups when connected sockets are present")
    Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
usb: aqc111: stop lying about skb->truesize [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon May 6 13:55:46 2024 +0000

    usb: aqc111: stop lying about skb->truesize
    
    [ Upstream commit 9aad6e45c4e7d16b2bb7c3794154b828fb4384b4 ]
    
    Some usb drivers try to set small skb->truesize and break
    core networking stacks.
    
    I replace one skb_clone() by an allocation of a fresh
    and small skb, to get minimally sized skbs, like we did
    in commit 1e2c61172342 ("net: cdc_ncm: reduce skb truesize
    in rx path") and 4ce62d5b2f7a ("net: usb: ax88179_178a:
    stop lying about skb->truesize")
    
    Fixes: 361459cd9642 ("net: usb: aqc111: Implement RX data path")
    Signed-off-by: Eric Dumazet <