ˇđ╔ˤ╦ ╔┌═┼╬┼╬╔╩ Î Linux 5.15.159

 
9p: explicitly deny setlease attempts [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Tue Mar 19 12:34:45 2024 -0400

    9p: explicitly deny setlease attempts
    
    [ Upstream commit 7a84602297d36617dbdadeba55a2567031e5165b ]
    
    9p is a remote network protocol, and it doesn't support asynchronous
    notifications from the server. Ensure that we don't hand out any leases
    since we can't guarantee they'll be broken when a file's contents
    change.
    
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ACPI: CPPC: Fix access width used for PCC registers [+ + +]
Author: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
Date:   Thu May 9 19:41:26 2024 +0000

    ACPI: CPPC: Fix access width used for PCC registers
    
    commit f489c948028b69cea235d9c0de1cc10eeb26a172 upstream
    
    commit 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system
    memory accesses") modified cpc_read()/cpc_write() to use access_width to
    read CPC registers.
    
    However, for PCC registers the access width field in the ACPI register
    macro specifies the PCC subspace ID.  For non-zero PCC subspace ID it is
    incorrectly treated as access width. This causes errors when reading
    from PCC registers in the CPPC driver.
    
    For PCC registers, base the size of read/write on the bit width field.
    The debug message in cpc_read()/cpc_write() is updated to print relevant
    information for the address space type used to read the register.
    
    Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses")
    Signed-off-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
    Tested-by: Jarred White <jarredwhite@linux.microsoft.com>
    Reviewed-by: Jarred White <jarredwhite@linux.microsoft.com>
    Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com>
    Cc: 5.15+ <stable@vger.kernel.org> # 5.15+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    [ eahariha: Backport to v5.15 by dropping SystemIO bits as commit
      a2c8f92bea5f is not present ]
    Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: CPPC: Fix bit_offset shift in MASK_VAL() macro [+ + +]
Author: Jarred White <jarredwhite@linux.microsoft.com>
Date:   Thu May 9 19:41:25 2024 +0000

    ACPI: CPPC: Fix bit_offset shift in MASK_VAL() macro
    
    commit 05d92ee782eeb7b939bdd0189e6efcab9195bf95 upstream
    
    Commit 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for
    system memory accesses") neglected to properly wrap the bit_offset shift
    when it comes to applying the mask. This may cause incorrect values to be
    read and may cause the cpufreq module not be loaded.
    
    [   11.059751] cpu_capacity: CPU0 missing/invalid highest performance.
    [   11.066005] cpu_capacity: partial information: fallback to 1024 for all CPUs
    
    Also, corrected the bitmask generation in GENMASK (extra bit being added).
    
    Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses")
    Signed-off-by: Jarred White <jarredwhite@linux.microsoft.com>
    Cc: 5.15+ <stable@vger.kernel.org> # 5.15+
    Reviewed-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: hda/realtek: Fix mute led of HP Laptop 15-da3001TU [+ + +]
Author: Aman Dhoot <amandhoot12@gmail.com>
Date:   Mon Apr 22 18:08:23 2024 +0530

    ALSA: hda/realtek: Fix mute led of HP Laptop 15-da3001TU
    
    commit 2d5af3ab9e6f1cf1468b2a5221b5c1f7f46c3333 upstream.
    
    This patch simply add SND_PCI_QUIRK for HP Laptop 15-da3001TU to fixed
    mute led of laptop.
    
    Signed-off-by: Aman Dhoot <amandhoot12@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/CAMTp=B+3NG65Z684xMwHqdXDJhY+DJK-kuSw4adn6xwnG+b5JA@mail.gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node() [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Fri Apr 26 10:27:31 2024 -0500

    ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()
    
    [ Upstream commit c158cf914713efc3bcdc25680c7156c48c12ef6a ]
    
    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 <pierre-louis.bossart@linux.intel.com>
    Fixes: 08c2a4bc9f2a ("ALSA: hda: move Intel SoundWire ACPI scan to dedicated module")
    Message-ID: <20240426152731.38420-1-pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: line6: Zero-initialize message buffers [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Apr 2 08:36:25 2024 +0200

    ALSA: line6: Zero-initialize message buffers
    
    [ Upstream commit c4e51e424e2c772ce1836912a8b0b87cd61bc9d5 ]
    
    For shutting up spurious KMSAN uninit-value warnings, just replace
    kmalloc() calls with kzalloc() for the buffers used for
    communications.  There should be no real issue with the original code,
    but it's still better to cover.
    
    Reported-by: syzbot+7fb05ccf7b3d2f9617b3@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/r/00000000000084b18706150bcca5@google.com
    Message-ID: <20240402063628.26609-1-tiwai@suse.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: qcom: Fix 'interrupt-map' parent address cells [+ + +]
Author: Rob Herring <robh@kernel.org>
Date:   Tue Sep 28 14:22:09 2021 -0500

    arm64: dts: qcom: Fix 'interrupt-map' parent address cells
    
    commit 0ac10b291bee84b00bf9fb2afda444e77e7f88f4 upstream.
    
    The 'interrupt-map' in several QCom SoCs is malformed. The '#address-cells'
    size of the parent interrupt controller (the GIC) is not accounted for.
    
    Cc: Andy Gross <agross@kernel.org>
    Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
    Cc: linux-arm-msm@vger.kernel.org
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20210928192210.1842377-1-robh@kernel.org
    Cc: Alex Elder <elder@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ARM: 9381/1: kasan: clear stale stack poison [+ + +]
Author: Boy.Wu <boy.wu@mediatek.com>
Date:   Mon Apr 15 05:21:55 2024 +0100

    ARM: 9381/1: kasan: clear stale stack poison
    
    [ Upstream commit c4238686f9093b98bd6245a348bcf059cdce23af ]
    
    We found below OOB crash:
    
    [   33.452494] ==================================================================
    [   33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
    [   33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0
    [   33.455515]
    [   33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O       6.1.25-mainline #1
    [   33.456880] Hardware name: Generic DT based system
    [   33.457555]  unwind_backtrace from show_stack+0x18/0x1c
    [   33.458326]  show_stack from dump_stack_lvl+0x40/0x4c
    [   33.459072]  dump_stack_lvl from print_report+0x158/0x4a4
    [   33.459863]  print_report from kasan_report+0x9c/0x148
    [   33.460616]  kasan_report from kasan_check_range+0x94/0x1a0
    [   33.461424]  kasan_check_range from memset+0x20/0x3c
    [   33.462157]  memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
    [   33.463064]  refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c
    [   33.464181]  tick_nohz_idle_stop_tick from do_idle+0x264/0x354
    [   33.465029]  do_idle from cpu_startup_entry+0x20/0x24
    [   33.465769]  cpu_startup_entry from rest_init+0xf0/0xf4
    [   33.466528]  rest_init from arch_post_acpi_subsys_init+0x0/0x18
    [   33.467397]
    [   33.467644] The buggy address belongs to stack of task swapper/0/0
    [   33.468493]  and is located at offset 112 in frame:
    [   33.469172]  refresh_cpu_vm_stats.constprop.0+0x0/0x2ec
    [   33.469917]
    [   33.470165] This frame has 2 objects:
    [   33.470696]  [32, 76) 'global_zone_diff'
    [   33.470729]  [112, 276) 'global_node_diff'
    [   33.471294]
    [   33.472095] The buggy address belongs to the physical page:
    [   33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03
    [   33.473944] flags: 0x1000(reserved|zone=0)
    [   33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001
    [   33.475656] raw: 00000000
    [   33.476050] page dumped because: kasan: bad access detected
    [   33.476816]
    [   33.477061] Memory state around the buggy address:
    [   33.477732]  c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   33.478630]  c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
    [   33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1
    [   33.480415]                                                ^
    [   33.481195]  c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3
    [   33.482088]  c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
    [   33.482978] ==================================================================
    
    We find the root cause of this OOB is that arm does not clear stale stack
    poison in the case of cpuidle.
    
    This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.
    
    From cited commit [1] that explain the problem
    
    Functions which the compiler has instrumented for KASAN place poison on
    the stack shadow upon entry and remove this poison prior to returning.
    
    In the case of cpuidle, CPUs exit the kernel a number of levels deep in
    C code.  Any instrumented functions on this critical path will leave
    portions of the stack shadow poisoned.
    
    If CPUs lose context and return to the kernel via a cold path, we
    restore a prior context saved in __cpu_suspend_enter are forgotten, and
    we never remove the poison they placed in the stack shadow area by
    functions calls between this and the actual exit of the kernel.
    
    Thus, (depending on stackframe layout) subsequent calls to instrumented
    functions may hit this stale poison, resulting in (spurious) KASAN
    splats to the console.
    
    To avoid this, clear any stale poison from the idle thread for a CPU
    prior to bringing a CPU online.
    
    From cited commit [2]
    
    Extend to check for CONFIG_KASAN_STACK
    
    [1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison")
    [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK")
    
    Signed-off-by: Boy Wu <boy.wu@mediatek.com>
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Acked-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Fixes: 5615f69bc209 ("ARM: 9016/2: Initialize the mapping of KASan shadow memory")
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: meson: axg-card: make links nonatomic [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Wed Oct 20 13:42:16 2021 +0200

    ASoC: meson: axg-card: make links nonatomic
    
    [ Upstream commit e138233e56e9829e65b6293887063a1a3ccb2d68 ]
    
    Non atomic operations need to be performed in the trigger callback
    of the TDM interfaces. Those are BEs but what matters is the nonatomic
    flag of the FE in the DPCM context. Just set nonatomic for everything so,
    at least, it is clear.
    
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20211020114217.133153-2-jbrunet@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: meson: axg-fifo: use FIELD helpers [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Tue Feb 27 16:08:25 2024 +0100

    ASoC: meson: axg-fifo: use FIELD helpers
    
    [ Upstream commit 9e6f39535c794adea6ba802a52c722d193c28124 ]
    
    Use FIELD_GET() and FIELD_PREP() helpers instead of doing it manually.
    
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://msgid.link/r/20240227150826.573581-1-jbrunet@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: b11d26660dff ("ASoC: meson: axg-fifo: use threaded irq to check periods")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: meson: axg-fifo: use threaded irq to check periods [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Fri Apr 26 17:29:38 2024 +0200

    ASoC: meson: axg-fifo: use threaded irq to check periods
    
    [ Upstream commit b11d26660dff8d7430892008616452dc8e5fb0f3 ]
    
    With the AXG audio subsystem, there is a possible random channel shift on
    TDM capture, when the slot number per lane is more than 2, and there is
    more than one lane used.
    
    The problem has been there since the introduction of the axg audio support
    but such scenario is pretty uncommon. This is why there is no loud
    complains about the problem.
    
    Solving the problem require to make the links non-atomic and use the
    trigger() callback to start FEs and BEs in the appropriate order.
    
    This was tried in the past and reverted because it caused the block irq to
    sleep while atomic. However, instead of reverting, the solution is to call
    snd_pcm_period_elapsed() in a non atomic context.
    
    Use the bottom half of a threaded IRQ to do so.
    
    Fixes: 6dc4fa179fb8 ("ASoC: meson: add axg fifo base driver")
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20240426152946.3078805-2-jbrunet@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: meson: axg-tdm-interface: manage formatters in trigger [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Wed Oct 20 13:42:17 2021 +0200

    ASoC: meson: axg-tdm-interface: manage formatters in trigger
    
    [ Upstream commit bf5e4887eeddb48480568466536aa08ec7f179a5 ]
    
    So far, the formatters have been reset/enabled using the .prepare()
    callback. This was done in this callback because walking the formatters use
    a mutex so it could not be done in .trigger(), which is atomic by default.
    
    It turns out there is a problem on capture path of the AXG series.
    The FIFO may get out of sync with the TDM decoder if the IP are not enabled
    in a specific order. The FIFO must be enabled before the formatter starts
    producing data. IOW, we must deal with FE before the BE. The .prepare()
    callback is called on the BEs before the FE so it is not OK for the AXG.
    
    The .trigger() callback order can be configured, and it deals with the FE
    before the BEs by default. To solve our problem, we just need to start and
    stop the formatters from the .trigger() callback. It is OK do so now that
    the links have been made 'nonatomic' in the card driver.
    
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20211020114217.133153-3-jbrunet@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: meson: cards: select SND_DYNAMIC_MINORS [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Fri Apr 26 15:41:47 2024 +0200

    ASoC: meson: cards: select SND_DYNAMIC_MINORS
    
    [ Upstream commit 6db26f9ea4edd8a17d39ab3c20111e3ccd704aef ]
    
    Amlogic sound cards do create a lot of pcm interfaces, possibly more than
    8. Some pcm interfaces are internal (like DPCM backends and c2c) and not
    exposed to userspace.
    
    Those interfaces still increase the number passed to snd_find_free_minor(),
    which eventually exceeds 8 causing -EBUSY error on card registration if
    CONFIG_SND_DYNAMIC_MINORS=n and the interface is exposed to userspace.
    
    select CONFIG_SND_DYNAMIC_MINORS for Amlogic cards to avoid the problem.
    
    Fixes: 7864a79f37b5 ("ASoC: meson: add axg sound card support")
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20240426134150.3053741-1-jbrunet@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: tegra: Fix DSPK 16-bit playback [+ + +]
Author: Sameer Pujar <spujar@nvidia.com>
Date:   Fri Apr 5 10:43:06 2024 +0000

    ASoC: tegra: Fix DSPK 16-bit playback
    
    commit 2e93a29b48a017c777d4fcbfcc51aba4e6a90d38 upstream.
    
    DSPK configuration is wrong for 16-bit playback and this happens because
    the client config is always fixed at 24-bit in hw_params(). Fix this by
    updating the client config to 16-bit for the respective playback.
    
    Fixes: 327ef6470266 ("ASoC: tegra: Add Tegra186 based DSPK driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sameer Pujar <spujar@nvidia.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Link: https://msgid.link/r/20240405104306.551036-1-spujar@nvidia.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: ti: davinci-mcasp: Fix race condition during probe [+ + +]
Author: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Date:   Wed Apr 17 15:41:38 2024 -0300

    ASoC: ti: davinci-mcasp: Fix race condition during probe
    
    commit d18ca8635db2f88c17acbdf6412f26d4f6aff414 upstream.
    
    When using davinci-mcasp as CPU DAI with simple-card, there are some
    conditions that cause simple-card to finish registering a sound card before
    davinci-mcasp finishes registering all sound components. This creates a
    non-working sound card from userspace with no problem indication apart
    from not being able to play/record audio on a PCM stream. The issue
    arises during simultaneous probe execution of both drivers. Specifically,
    the simple-card driver, awaiting a CPU DAI, proceeds as soon as
    davinci-mcasp registers its DAI. However, this process can lead to the
    client mutex lock (client_mutex in soc-core.c) being held or davinci-mcasp
    being preempted before PCM DMA registration on davinci-mcasp finishes.
    This situation occurs when the probes of both drivers run concurrently.
    Below is the code path for this condition. To solve the issue, defer
    davinci-mcasp CPU DAI registration to the last step in the audio part of
    it. This way, simple-card CPU DAI parsing will be deferred until all
    audio components are registered.
    
    Fail Code Path:
    
    simple-card.c: probe starts
    simple-card.c: simple_dai_link_of: simple_parse_node(..,cpu,..) returns EPROBE_DEFER, no CPU DAI yet
    davinci-mcasp.c: probe starts
    davinci-mcasp.c: devm_snd_soc_register_component() register CPU DAI
    simple-card.c: probes again, finish CPU DAI parsing and call devm_snd_soc_register_card()
    simple-card.c: finish probe
    davinci-mcasp.c: *dma_pcm_platform_register() register PCM  DMA
    davinci-mcasp.c: probe finish
    
    Cc: stable@vger.kernel.org
    Fixes: 9fbd58cf4ab0 ("ASoC: davinci-mcasp: Choose PCM driver based on configured DMA controller")
    Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Reviewed-by: Jai Luthra <j-luthra@ti.com>
    Link: https://lore.kernel.org/r/20240417184138.1104774-1-jpaulo.silvagoncalves@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ata: sata_gemini: Check clk_enable() result [+ + +]
Author: Chen Ni <nichen@iscas.ac.cn>
Date:   Wed Apr 3 04:33:49 2024 +0000

    ata: sata_gemini: Check clk_enable() result
    
    [ Upstream commit e85006ae7430aef780cc4f0849692e266a102ec0 ]
    
    The call to clk_enable() in gemini_sata_start_bridge() can fail.
    Add a check to detect such failure.
    
    Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
blk-iocost: avoid out of bounds shift [+ + +]
Author: Rik van Riel <riel@surriel.com>
Date:   Thu Apr 4 12:32:53 2024 -0400

    blk-iocost: avoid out of bounds shift
    
    [ Upstream commit beaa51b36012fad5a4d3c18b88a617aea7a9b96d ]
    
    UBSAN catches undefined behavior in blk-iocost, where sometimes
    iocg->delay is shifted right by a number that is too large,
    resulting in undefined behavior on some architectures.
    
    [  186.556576] ------------[ cut here ]------------
    UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23
    shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long')
    CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S          E    N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1
    Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020
    Call Trace:
     <IRQ>
     dump_stack_lvl+0x8f/0xe0
     __ubsan_handle_shift_out_of_bounds+0x22c/0x280
     iocg_kick_delay+0x30b/0x310
     ioc_timer_fn+0x2fb/0x1f80
     __run_timer_base+0x1b6/0x250
    ...
    
    Avoid that undefined behavior by simply taking the
    "delay = 0" branch if the shift is too large.
    
    I am not sure what the symptoms of an undefined value
    delay will be, but I suspect it could be more than a
    little annoying to debug.
    
    Signed-off-by: Rik van Riel <riel@surriel.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Josef Bacik <josef@toxicpanda.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: https://lore.kernel.org/r/20240404123253.0f58010f@imladris.surriel.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Thu Apr 25 22:23:45 2024 +0800

    Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
    
    [ Upstream commit 483bc08181827fc475643272ffb69c533007e546 ]
    
    When the sco connection is established and then, the sco socket
    is releasing, timeout_work will be scheduled to judge whether
    the sco disconnection is timeout. The sock will be deallocated
    later, but it is dereferenced again in sco_sock_timeout. As a
    result, the use-after-free bugs will happen. The root cause is
    shown below:
    
        Cleanup Thread               |      Worker Thread
    sco_sock_release                 |
      sco_sock_close                 |
        __sco_sock_close             |
          sco_sock_set_timer         |
            schedule_delayed_work    |
      sco_sock_kill                  |    (wait a time)
        sock_put(sk) //FREE          |  sco_sock_timeout
                                     |    sock_hold(sk) //USE
    
    The KASAN report triggered by POC is shown below:
    
    [   95.890016] ==================================================================
    [   95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0
    [   95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7
    ...
    [   95.890755] Workqueue: events sco_sock_timeout
    [   95.890755] Call Trace:
    [   95.890755]  <TASK>
    [   95.890755]  dump_stack_lvl+0x45/0x110
    [   95.890755]  print_address_description+0x78/0x390
    [   95.890755]  print_report+0x11b/0x250
    [   95.890755]  ? __virt_addr_valid+0xbe/0xf0
    [   95.890755]  ? sco_sock_timeout+0x5e/0x1c0
    [   95.890755]  kasan_report+0x139/0x170
    [   95.890755]  ? update_load_avg+0xe5/0x9f0
    [   95.890755]  ? sco_sock_timeout+0x5e/0x1c0
    [   95.890755]  kasan_check_range+0x2c3/0x2e0
    [   95.890755]  sco_sock_timeout+0x5e/0x1c0
    [   95.890755]  process_one_work+0x561/0xc50
    [   95.890755]  worker_thread+0xab2/0x13c0
    [   95.890755]  ? pr_cont_work+0x490/0x490
    [   95.890755]  kthread+0x279/0x300
    [   95.890755]  ? pr_cont_work+0x490/0x490
    [   95.890755]  ? kthread_blkcg+0xa0/0xa0
    [   95.890755]  ret_from_fork+0x34/0x60
    [   95.890755]  ? kthread_blkcg+0xa0/0xa0
    [   95.890755]  ret_from_fork_asm+0x11/0x20
    [   95.890755]  </TASK>
    [   95.890755]
    [   95.890755] Allocated by task 506:
    [   95.890755]  kasan_save_track+0x3f/0x70
    [   95.890755]  __kasan_kmalloc+0x86/0x90
    [   95.890755]  __kmalloc+0x17f/0x360
    [   95.890755]  sk_prot_alloc+0xe1/0x1a0
    [   95.890755]  sk_alloc+0x31/0x4e0
    [   95.890755]  bt_sock_alloc+0x2b/0x2a0
    [   95.890755]  sco_sock_create+0xad/0x320
    [   95.890755]  bt_sock_create+0x145/0x320
    [   95.890755]  __sock_create+0x2e1/0x650
    [   95.890755]  __sys_socket+0xd0/0x280
    [   95.890755]  __x64_sys_socket+0x75/0x80
    [   95.890755]  do_syscall_64+0xc4/0x1b0
    [   95.890755]  entry_SYSCALL_64_after_hwframe+0x67/0x6f
    [   95.890755]
    [   95.890755] Freed by task 506:
    [   95.890755]  kasan_save_track+0x3f/0x70
    [   95.890755]  kasan_save_free_info+0x40/0x50
    [   95.890755]  poison_slab_object+0x118/0x180
    [   95.890755]  __kasan_slab_free+0x12/0x30
    [   95.890755]  kfree+0xb2/0x240
    [   95.890755]  __sk_destruct+0x317/0x410
    [   95.890755]  sco_sock_release+0x232/0x280
    [   95.890755]  sock_close+0xb2/0x210
    [   95.890755]  __fput+0x37f/0x770
    [   95.890755]  task_work_run+0x1ae/0x210
    [   95.890755]  get_signal+0xe17/0xf70
    [   95.890755]  arch_do_signal_or_restart+0x3f/0x520
    [   95.890755]  syscall_exit_to_user_mode+0x55/0x120
    [   95.890755]  do_syscall_64+0xd1/0x1b0
    [   95.890755]  entry_SYSCALL_64_after_hwframe+0x67/0x6f
    [   95.890755]
    [   95.890755] The buggy address belongs to the object at ffff88800c388000
    [   95.890755]  which belongs to the cache kmalloc-1k of size 1024
    [   95.890755] The buggy address is located 128 bytes inside of
    [   95.890755]  freed 1024-byte region [ffff88800c388000, ffff88800c388400)
    [   95.890755]
    [   95.890755] The buggy address belongs to the physical page:
    [   95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388
    [   95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
    [   95.890755] anon flags: 0x100000000000840(slab|head|node=0|zone=1)
    [   95.890755] page_type: 0xffffffff()
    [   95.890755] raw: 0100000000000840 ffff888006842dc0 0000000000000000 0000000000000001
    [   95.890755] raw: ffff88800c38a800 000000000010000a 00000001ffffffff 0000000000000000
    [   95.890755] head: 0100000000000840 ffff888006842dc0 0000000000000000 0000000000000001
    [   95.890755] head: ffff88800c38a800 000000000010000a 00000001ffffffff 0000000000000000
    [   95.890755] head: 0100000000000003 ffffea000030e201 ffffea000030e248 00000000ffffffff
    [   95.890755] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000
    [   95.890755] page dumped because: kasan: bad access detected
    [   95.890755]
    [   95.890755] Memory state around the buggy address:
    [   95.890755]  ffff88800c387f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   95.890755]  ffff88800c388000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [   95.890755] >ffff88800c388080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [   95.890755]                    ^
    [   95.890755]  ffff88800c388100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [   95.890755]  ffff88800c388180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [   95.890755] ==================================================================
    
    Fix this problem by adding a check protected by sco_conn_lock to judget
    whether the conn->hcon is null. Because the conn->hcon will be set to null,
    when the sock is releasing.
    
    Fixes: ba316be1b6a0 ("Bluetooth: schedule SCO timeouts with delayed_work")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Thu May 2 20:57:36 2024 +0800

    Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
    
    [ Upstream commit adf0398cee86643b8eacde95f17d073d022f782c ]
    
    There is a race condition between l2cap_chan_timeout() and
    l2cap_chan_del(). When we use l2cap_chan_del() to delete the
    channel, the chan->conn will be set to null. But the conn could
    be dereferenced again in the mutex_lock() of l2cap_chan_timeout().
    As a result the null pointer dereference bug will happen. The
    KASAN report triggered by POC is shown below:
    
    [  472.074580] ==================================================================
    [  472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0
    [  472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7
    [  472.075308]
    [  472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36
    [  472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
    [  472.075308] Workqueue: events l2cap_chan_timeout
    [  472.075308] Call Trace:
    [  472.075308]  <TASK>
    [  472.075308]  dump_stack_lvl+0x137/0x1a0
    [  472.075308]  print_report+0x101/0x250
    [  472.075308]  ? __virt_addr_valid+0x77/0x160
    [  472.075308]  ? mutex_lock+0x68/0xc0
    [  472.075308]  kasan_report+0x139/0x170
    [  472.075308]  ? mutex_lock+0x68/0xc0
    [  472.075308]  kasan_check_range+0x2c3/0x2e0
    [  472.075308]  mutex_lock+0x68/0xc0
    [  472.075308]  l2cap_chan_timeout+0x181/0x300
    [  472.075308]  process_one_work+0x5d2/0xe00
    [  472.075308]  worker_thread+0xe1d/0x1660
    [  472.075308]  ? pr_cont_work+0x5e0/0x5e0
    [  472.075308]  kthread+0x2b7/0x350
    [  472.075308]  ? pr_cont_work+0x5e0/0x5e0
    [  472.075308]  ? kthread_blkcg+0xd0/0xd0
    [  472.075308]  ret_from_fork+0x4d/0x80
    [  472.075308]  ? kthread_blkcg+0xd0/0xd0
    [  472.075308]  ret_from_fork_asm+0x11/0x20
    [  472.075308]  </TASK>
    [  472.075308] ==================================================================
    [  472.094860] Disabling lock debugging due to kernel taint
    [  472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158
    [  472.096136] #PF: supervisor write access in kernel mode
    [  472.096136] #PF: error_code(0x0002) - not-present page
    [  472.096136] PGD 0 P4D 0
    [  472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
    [  472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G    B              6.9.0-rc5-00356-g78c0094a146b #36
    [  472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
    [  472.096136] Workqueue: events l2cap_chan_timeout
    [  472.096136] RIP: 0010:mutex_lock+0x88/0xc0
    [  472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88
    [  472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246
    [  472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865
    [  472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78
    [  472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f
    [  472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000
    [  472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00
    [  472.096136] FS:  0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
    [  472.096136] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0
    [  472.096136] Call Trace:
    [  472.096136]  <TASK>
    [  472.096136]  ? __die_body+0x8d/0xe0
    [  472.096136]  ? page_fault_oops+0x6b8/0x9a0
    [  472.096136]  ? kernelmode_fixup_or_oops+0x20c/0x2a0
    [  472.096136]  ? do_user_addr_fault+0x1027/0x1340
    [  472.096136]  ? _printk+0x7a/0xa0
    [  472.096136]  ? mutex_lock+0x68/0xc0
    [  472.096136]  ? add_taint+0x42/0xd0
    [  472.096136]  ? exc_page_fault+0x6a/0x1b0
    [  472.096136]  ? asm_exc_page_fault+0x26/0x30
    [  472.096136]  ? mutex_lock+0x75/0xc0
    [  472.096136]  ? mutex_lock+0x88/0xc0
    [  472.096136]  ? mutex_lock+0x75/0xc0
    [  472.096136]  l2cap_chan_timeout+0x181/0x300
    [  472.096136]  process_one_work+0x5d2/0xe00
    [  472.096136]  worker_thread+0xe1d/0x1660
    [  472.096136]  ? pr_cont_work+0x5e0/0x5e0
    [  472.096136]  kthread+0x2b7/0x350
    [  472.096136]  ? pr_cont_work+0x5e0/0x5e0
    [  472.096136]  ? kthread_blkcg+0xd0/0xd0
    [  472.096136]  ret_from_fork+0x4d/0x80
    [  472.096136]  ? kthread_blkcg+0xd0/0xd0
    [  472.096136]  ret_from_fork_asm+0x11/0x20
    [  472.096136]  </TASK>
    [  472.096136] Modules linked in:
    [  472.096136] CR2: 0000000000000158
    [  472.096136] ---[ end trace 0000000000000000 ]---
    [  472.096136] RIP: 0010:mutex_lock+0x88/0xc0
    [  472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88
    [  472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246
    [  472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865
    [  472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78
    [  472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f
    [  472.132932] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000
    [  472.132932] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00
    [  472.132932] FS:  0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
    [  472.132932] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  472.132932] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0
    [  472.132932] Kernel panic - not syncing: Fatal exception
    [  472.132932] Kernel Offset: disabled
    [  472.132932] ---[ end Kernel panic - not syncing: Fatal exception ]---
    
    Add a check to judge whether the conn is null in l2cap_chan_timeout()
    in order to mitigate the bug.
    
    Fixes: 3df91ea20e74 ("Bluetooth: Revert to mutexes from RCU list")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: qca: add missing firmware sanity checks [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Tue Apr 30 19:07:39 2024 +0200

    Bluetooth: qca: add missing firmware sanity checks
    
    commit 2e4edfa1e2bd821a317e7d006517dcf2f3fac68d upstream.
    
    Add the missing sanity checks when parsing the firmware files before
    downloading them to avoid accessing and corrupting memory beyond the
    vmalloced buffer.
    
    Fixes: 83e81961ff7e ("Bluetooth: btqca: Introduce generic QCA ROME support")
    Cc: stable@vger.kernel.org      # 4.10
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: qca: fix firmware check error path [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Wed May 1 08:37:40 2024 +0200

    Bluetooth: qca: fix firmware check error path
    
    commit 40d442f969fb1e871da6fca73d3f8aef1f888558 upstream.
    
    A recent commit fixed the code that parses the firmware files before
    downloading them to the controller but introduced a memory leak in case
    the sanity checks ever fail.
    
    Make sure to free the firmware buffer before returning on errors.
    
    Fixes: f905ae0be4b7 ("Bluetooth: qca: add missing firmware sanity checks")
    Cc: stable@vger.kernel.org      # 4.19
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: qca: fix NVM configuration parsing [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Tue Apr 30 19:07:40 2024 +0200

    Bluetooth: qca: fix NVM configuration parsing
    
    commit a112d3c72a227f2edbb6d8094472cc6e503e52af upstream.
    
    The NVM configuration files used by WCN3988 and WCN3990/1/8 have two
    sets of configuration tags that are enclosed by a type-length header of
    type four which the current parser fails to account for.
    
    Instead the driver happily parses random data as if it were valid tags,
    something which can lead to the configuration data being corrupted if it
    ever encounters the words 0x0011 or 0x001b.
    
    As is clear from commit b63882549b2b ("Bluetooth: btqca: Fix the NVM
    baudrate tag offcet for wcn3991") the intention has always been to
    process the configuration data also for WCN3991 and WCN3998 which
    encodes the baud rate at a different offset.
    
    Fix the parser so that it can handle the WCN3xxx configuration files,
    which has an enclosing type-length header of type four and two sets of
    TLV tags enclosed by a type-length header of type two and three,
    respectively.
    
    Note that only the first set, which contains the tags the driver is
    currently looking for, will be parsed for now.
    
    With the parser fixed, the software in-band sleep bit will now be set
    for WCN3991 and WCN3998 (as it is for later controllers) and the default
    baud rate 3200000 may be updated by the driver also for WCN3xxx
    controllers.
    
    Notably the deep-sleep feature bit is already set by default in all
    configuration files in linux-firmware.
    
    Fixes: 4219d4686875 ("Bluetooth: btqca: Add wcn3990 firmware download support.")
    Cc: stable@vger.kernel.org      # 4.19
    Cc: Matthias Kaehlcke <mka@chromium.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bna: ensure the copied buf is NUL terminated [+ + +]
Author: Bui Quang Minh <minhquangbui99@gmail.com>
Date:   Wed Apr 24 21:44:19 2024 +0700

    bna: ensure the copied buf is NUL terminated
    
    [ Upstream commit 8c34096c7fdf272fd4c0c37fe411cd2e3ed0ee9f ]
    
    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: 7afc5dbde091 ("bna: Add debugfs interface.")
    Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
    Link: https://lore.kernel.org/r/20240424-fix-oob-read-v2-2-f1f1b53a10f4@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, kconfig: Fix DEBUG_INFO_BTF_MODULES Kconfig definition [+ + +]
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Thu Apr 4 15:03:44 2024 -0700

    bpf, kconfig: Fix DEBUG_INFO_BTF_MODULES Kconfig definition
    
    [ Upstream commit 229087f6f1dc2d0c38feba805770f28529980ec0 ]
    
    Turns out that due to CONFIG_DEBUG_INFO_BTF_MODULES not having an
    explicitly specified "menu item name" in Kconfig, it's basically
    impossible to turn it off (see [0]).
    
    This patch fixes the issue by defining menu name for
    CONFIG_DEBUG_INFO_BTF_MODULES, which makes it actually adjustable
    and independent of CONFIG_DEBUG_INFO_BTF, in the sense that one can
    have DEBUG_INFO_BTF=y and DEBUG_INFO_BTF_MODULES=n.
    
    We still keep it as defaulting to Y, of course.
    
    Fixes: 5f9ae91f7c0d ("kbuild: Build kernel module BTFs if BTF is enabled and pahole supports it")
    Reported-by: Vincent Li <vincent.mc.li@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/CAK3+h2xiFfzQ9UXf56nrRRP=p1+iUxGoEP5B+aq9MDT5jLXDSg@mail.gmail.com [0]
    Link: https://lore.kernel.org/bpf/20240404220344.3879270-1-andrii@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue [+ + +]
Author: Jason Xing <kernelxing@tencent.com>
Date:   Thu Apr 4 10:10:01 2024 +0800

    bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue
    
    [ Upstream commit 6648e613226e18897231ab5e42ffc29e63fa3365 ]
    
    Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which
    syzbot reported [1].
    
    [1]
    BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue
    
    write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:
     sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]
     sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843
     sk_psock_put include/linux/skmsg.h:459 [inline]
     sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648
     unix_release+0x4b/0x80 net/unix/af_unix.c:1048
     __sock_release net/socket.c:659 [inline]
     sock_close+0x68/0x150 net/socket.c:1421
     __fput+0x2c1/0x660 fs/file_table.c:422
     __fput_sync+0x44/0x60 fs/file_table.c:507
     __do_sys_close fs/open.c:1556 [inline]
     __se_sys_close+0x101/0x1b0 fs/open.c:1541
     __x64_sys_close+0x1f/0x30 fs/open.c:1541
     do_syscall_64+0xd3/0x1d0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:
     sk_psock_data_ready include/linux/skmsg.h:464 [inline]
     sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555
     sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606
     sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]
     sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202
     unix_read_skb net/unix/af_unix.c:2546 [inline]
     unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682
     sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223
     unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg+0x140/0x180 net/socket.c:745
     ____sys_sendmsg+0x312/0x410 net/socket.c:2584
     ___sys_sendmsg net/socket.c:2638 [inline]
     __sys_sendmsg+0x1e9/0x280 net/socket.c:2667
     __do_sys_sendmsg net/socket.c:2676 [inline]
     __se_sys_sendmsg net/socket.c:2674 [inline]
     __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674
     do_syscall_64+0xd3/0x1d0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    value changed: 0xffffffff83d7feb0 -> 0x0000000000000000
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G        W          6.8.0-syzkaller-08951-gfe46a7dd189e #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
    
    Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer
    dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer
    similarly due to no protection of saved_data_ready. Here is another
    different caller causing the same issue because of the same reason. So
    we should protect it with sk_callback_lock read lock because the writer
    side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);".
    
    To avoid errors that could happen in future, I move those two pairs of
    lock into the sk_psock_data_ready(), which is suggested by John Fastabend.
    
    Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
    Reported-by: syzbot+aa8c8ec2538929f18f2d@syzkaller.appspotmail.com
    Signed-off-by: Jason Xing <kernelxing@tencent.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=aa8c8ec2538929f18f2d
    Link: https://lore.kernel.org/all/20240329134037.92124-1-kerneljasonxing@gmail.com
    Link: https://lore.kernel.org/bpf/20240404021001.94815-1-kerneljasonxing@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, sockmap: Convert schedule_work into delayed_work [+ + +]
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Mon May 22 19:56:06 2023 -0700

    bpf, sockmap: Convert schedule_work into delayed_work
    
    [ Upstream commit 29173d07f79883ac94f5570294f98af3d4287382 ]
    
    Sk_buffs are fed into sockmap verdict programs either from a strparser
    (when the user might want to decide how framing of skb is done by attaching
    another parser program) or directly through tcp_read_sock. The
    tcp_read_sock is the preferred method for performance when the BPF logic is
    a stream parser.
    
    The flow for Cilium's common use case with a stream parser is,
    
     tcp_read_sock()
      sk_psock_verdict_recv
        ret = bpf_prog_run_pin_on_cpu()
        sk_psock_verdict_apply(sock, skb, ret)
         // if system is under memory pressure or app is slow we may
         // need to queue skb. Do this queuing through ingress_skb and
         // then kick timer to wake up handler
         skb_queue_tail(ingress_skb, skb)
         schedule_work(work);
    
    The work queue is wired up to sk_psock_backlog(). This will then walk the
    ingress_skb skb list that holds our sk_buffs that could not be handled,
    but should be OK to run at some later point. However, its possible that
    the workqueue doing this work still hits an error when sending the skb.
    When this happens the skbuff is requeued on a temporary 'state' struct
    kept with the workqueue. This is necessary because its possible to
    partially send an skbuff before hitting an error and we need to know how
    and where to restart when the workqueue runs next.
    
    Now for the trouble, we don't rekick the workqueue. This can cause a
    stall where the skbuff we just cached on the state variable might never
    be sent. This happens when its the last packet in a flow and no further
    packets come along that would cause the system to kick the workqueue from
    that side.
    
    To fix we could do simple schedule_work(), but while under memory pressure
    it makes sense to back off some instead of continue to retry repeatedly. So
    instead to fix convert schedule_work to schedule_delayed_work and add
    backoff logic to reschedule from backlog queue on errors. Its not obvious
    though what a good backoff is so use '1'.
    
    To test we observed some flakes whil running NGINX compliance test with
    sockmap we attributed these failed test to this bug and subsequent issue.
    
    >From on list discussion. This commit
    
     bec217197b41("skmsg: Schedule psock work if the cached skb exists on the psock")
    
    was intended to address similar race, but had a couple cases it missed.
    Most obvious it only accounted for receiving traffic on the local socket
    so if redirecting into another socket we could still get an sk_buff stuck
    here. Next it missed the case where copied=0 in the recv() handler and
    then we wouldn't kick the scheduler. Also its sub-optimal to require
    userspace to kick the internal mechanisms of sockmap to wake it up and
    copy data to user. It results in an extra syscall and requires the app
    to actual handle the EAGAIN correctly.
    
    Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()")
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: William Findlay <will@isovalent.com>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/20230523025618.113937-3-john.fastabend@gmail.com
    Stable-dep-of: 405df89dd52c ("bpf, sockmap: Improved check for empty queue")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf, sockmap: Handle fin correctly [+ + +]
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Mon May 22 19:56:09 2023 -0700

    bpf, sockmap: Handle fin correctly
    
    [ Upstream commit 901546fd8f9ca4b5c481ce00928ab425ce9aacc0 ]
    
    The sockmap code is returning EAGAIN after a FIN packet is received and no
    more data is on the receive queue. Correct behavior is to return 0 to the
    user and the user can then close the socket. The EAGAIN causes many apps
    to retry which masks the problem. Eventually the socket is evicted from
    the sockmap because its released from sockmap sock free handling. The
    issue creates a delay and can cause some errors on application side.
    
    To fix this check on sk_msg_recvmsg side if length is zero and FIN flag
    is set then set return to zero. A selftest will be added to check this
    condition.
    
    Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()")
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: William Findlay <will@isovalent.com>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/20230523025618.113937-6-john.fastabend@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf, sockmap: Improved check for empty queue [+ + +]
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Mon May 22 19:56:08 2023 -0700

    bpf, sockmap: Improved check for empty queue
    
    [ Upstream commit 405df89dd52cbcd69a3cd7d9a10d64de38f854b2 ]
    
    We noticed some rare sk_buffs were stepping past the queue when system was
    under memory pressure. The general theory is to skip enqueueing
    sk_buffs when its not necessary which is the normal case with a system
    that is properly provisioned for the task, no memory pressure and enough
    cpu assigned.
    
    But, if we can't allocate memory due to an ENOMEM error when enqueueing
    the sk_buff into the sockmap receive queue we push it onto a delayed
    workqueue to retry later. When a new sk_buff is received we then check
    if that queue is empty. However, there is a problem with simply checking
    the queue length. When a sk_buff is being processed from the ingress queue
    but not yet on the sockmap msg receive queue its possible to also recv
    a sk_buff through normal path. It will check the ingress queue which is
    zero and then skip ahead of the pkt being processed.
    
    Previously we used sock lock from both contexts which made the problem
    harder to hit, but not impossible.
    
    To fix instead of popping the skb from the queue entirely we peek the
    skb from the queue and do the copy there. This ensures checks to the
    queue length are non-zero while skb is being processed. Then finally
    when the entire skb has been copied to user space queue or another
    socket we pop it off the queue. This way the queue length check allows
    bypassing the queue only after the list has been completely processed.
    
    To reproduce issue we run NGINX compliance test with sockmap running and
    observe some flakes in our testing that we attributed to this issue.
    
    Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()")
    Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: William Findlay <will@isovalent.com>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/20230523025618.113937-5-john.fastabend@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf, sockmap: Reschedule is now done through backlog [+ + +]
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Mon May 22 19:56:07 2023 -0700

    bpf, sockmap: Reschedule is now done through backlog
    
    [ Upstream commit bce22552f92ea7c577f49839b8e8f7d29afaf880 ]
    
    Now that the backlog manages the reschedule() logic correctly we can drop
    the partial fix to reschedule from recvmsg hook.
    
    Rescheduling on recvmsg hook was added to address a corner case where we
    still had data in the backlog state but had nothing to kick it and
    reschedule the backlog worker to run and finish copying data out of the
    state. This had a couple limitations, first it required user space to
    kick it introducing an unnecessary EBUSY and retry. Second it only
    handled the ingress case and egress redirects would still be hung.
    
    With the correct fix, pushing the reschedule logic down to where the
    enomem error occurs we can drop this fix.
    
    Fixes: bec217197b412 ("skmsg: Schedule psock work if the cached skb exists on the psock")
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/20230523025618.113937-4-john.fastabend@gmail.com
    Stable-dep-of: 405df89dd52c ("bpf, sockmap: Improved check for empty queue")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf, sockmap: TCP data stall on recv before accept [+ + +]
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Mon May 22 19:56:10 2023 -0700

    bpf, sockmap: TCP data stall on recv before accept
    
    [ Upstream commit ea444185a6bf7da4dd0df1598ee953e4f7174858 ]
    
    A common mechanism to put a TCP socket into the sockmap is to hook the
    BPF_SOCK_OPS_{ACTIVE_PASSIVE}_ESTABLISHED_CB event with a BPF program
    that can map the socket info to the correct BPF verdict parser. When
    the user adds the socket to the map the psock is created and the new
    ops are assigned to ensure the verdict program will 'see' the sk_buffs
    as they arrive.
    
    Part of this process hooks the sk_data_ready op with a BPF specific
    handler to wake up the BPF verdict program when data is ready to read.
    The logic is simple enough (posted here for easy reading)
    
     static void sk_psock_verdict_data_ready(struct sock *sk)
     {
            struct socket *sock = sk->sk_socket;
    
            if (unlikely(!sock || !sock->ops || !sock->ops->read_skb))
                    return;
            sock->ops->read_skb(sk, sk_psock_verdict_recv);
     }
    
    The oversight here is sk->sk_socket is not assigned until the application
    accepts() the new socket. However, its entirely ok for the peer application
    to do a connect() followed immediately by sends. The socket on the receiver
    is sitting on the backlog queue of the listening socket until its accepted
    and the data is queued up. If the peer never accepts the socket or is slow
    it will eventually hit data limits and rate limit the session. But,
    important for BPF sockmap hooks when this data is received TCP stack does
    the sk_data_ready() call but the read_skb() for this data is never called
    because sk_socket is missing. The data sits on the sk_receive_queue.
    
    Then once the socket is accepted if we never receive more data from the
    peer there will be no further sk_data_ready calls and all the data
    is still on the sk_receive_queue(). Then user calls recvmsg after accept()
    and for TCP sockets in sockmap we use the tcp_bpf_recvmsg_parser() handler.
    The handler checks for data in the sk_msg ingress queue expecting that
    the BPF program has already run from the sk_data_ready hook and enqueued
    the data as needed. So we are stuck.
    
    To fix do an unlikely check in recvmsg handler for data on the
    sk_receive_queue and if it exists wake up data_ready. We have the sock
    locked in both read_skb and recvmsg so should avoid having multiple
    runners.
    
    Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()")
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/20230523025618.113937-7-john.fastabend@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Fix a verifier verbose message [+ + +]
Author: Anton Protopopov <aspsk@isovalent.com>
Date:   Fri Apr 12 16:11:00 2024 +0200

    bpf: Fix a verifier verbose message
    
    [ Upstream commit 37eacb9f6e89fb399a79e952bc9c78eb3e16290e ]
    
    Long ago a map file descriptor in a pseudo ldimm64 instruction could
    only be present as an immediate value insn[0].imm, and thus this value
    was used in a verbose verifier message printed when the file descriptor
    wasn't valid. Since addition of BPF_PSEUDO_MAP_IDX_VALUE/BPF_PSEUDO_MAP_IDX
    the insn[0].imm field can also contain an index pointing to the file
    descriptor in the attr.fd_array array. However, if the file descriptor
    is invalid, the verifier still prints the verbose message containing
    value of insn[0].imm. Patch the verifier message to always print the
    actual file descriptor value.
    
    Fixes: 387544bfa291 ("bpf: Introduce fd_idx")
    Signed-off-by: Anton Protopopov <aspsk@isovalent.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20240412141100.3562942-1-aspsk@isovalent.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: add missing mutex_unlock in btrfs_relocate_sys_chunks() [+ + +]
Author: Dominique Martinet <dominique.martinet@atmark-techno.com>
Date:   Fri Apr 19 11:22:48 2024 +0900

    btrfs: add missing mutex_unlock in btrfs_relocate_sys_chunks()
    
    commit 9af503d91298c3f2945e73703f0e00995be08c30 upstream.
    
    The previous patch that replaced BUG_ON by error handling forgot to
    unlock the mutex in the error path.
    
    Link: https://lore.kernel.org/all/Zh%2fHpAGFqa7YAFuM@duo.ucw.cz
    Reported-by: Pavel Machek <pavel@denx.de>
    Fixes: 7411055db5ce ("btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()")
    CC: stable@vger.kernel.org
    Reviewed-by: Pavel Machek <pavel@denx.de>
    Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: always clear PERTRANS metadata during commit [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Tue Mar 26 12:01:28 2024 -0700

    btrfs: always clear PERTRANS metadata during commit
    
    [ Upstream commit 6e68de0bb0ed59e0554a0c15ede7308c47351e2d ]
    
    It is possible to clear a root's IN_TRANS tag from the radix tree, but
    not clear its PERTRANS, if there is some error in between. Eliminate
    that possibility by moving the free up to where we clear the tag.
    
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: fix kvcalloc() arguments order in btrfs_ioctl_send() [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Thu Dec 21 11:47:45 2023 +0300

    btrfs: fix kvcalloc() arguments order in btrfs_ioctl_send()
    
    commit 6ff09b6b8c2fb6b3edda4ffaa173153a40653067 upstream.
    
    When compiling with gcc version 14.0.0 20231220 (experimental)
    and W=1, I've noticed the following warning:
    
    fs/btrfs/send.c: In function 'btrfs_ioctl_send':
    fs/btrfs/send.c:8208:44: warning: 'kvcalloc' sizes specified with 'sizeof'
    in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
     8208 |         sctx->clone_roots = kvcalloc(sizeof(*sctx->clone_roots),
          |                                            ^
    
    Since 'n' and 'size' arguments of 'kvcalloc()' are multiplied to
    calculate the final size, their actual order doesn't affect the result
    and so this is not a bug. But it's still worth to fix it.
    
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: make btrfs_clear_delalloc_extent() free delalloc reserve [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Tue Mar 26 11:55:22 2024 -0700

    btrfs: make btrfs_clear_delalloc_extent() free delalloc reserve
    
    [ Upstream commit 3c6f0c5ecc8910d4ffb0dfe85609ebc0c91c8f34 ]
    
    Currently, this call site in btrfs_clear_delalloc_extent() only converts
    the reservation. We are marking it not delalloc, so I don't think it
    makes sense to keep the rsv around.  This is a path where we are not
    sure to join a transaction, so it leads to incorrect free-ing during
    umount.
    
    Helps with the pass rate of generic/269 and generic/475.
    
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: return accurate error code on open failure in open_fs_devices() [+ + +]
Author: Anand Jain <anand.jain@oracle.com>
Date:   Tue Mar 19 08:28:18 2024 +0530

    btrfs: return accurate error code on open failure in open_fs_devices()
    
    [ Upstream commit 2f1aeab9fca1a5f583be1add175d1ee95c213cfa ]
    
    When attempting to exclusive open a device which has no exclusive open
    permission, such as a physical device associated with the flakey dm
    device, the open operation will fail, resulting in a mount failure.
    
    In this particular scenario, we erroneously return -EINVAL instead of the
    correct error code provided by the bdev_open_by_path() function, which is
    -EBUSY.
    
    Fix this, by returning error code from the bdev_open_by_path() function.
    With this correction, the mount error message will align with that of
    ext4 and xfs.
    
    Reviewed-by: Boris Burkov <boris@bur.io>
    Signed-off-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: Don't hold prepare_lock when calling kref_put() [+ + +]
Author: Stephen Boyd <sboyd@kernel.org>
Date:   Mon Mar 25 11:41:56 2024 -0700

    clk: Don't hold prepare_lock when calling kref_put()
    
    [ Upstream commit 6f63af7511e7058f3fa4ad5b8102210741c9f947 ]
    
    We don't need to hold the prepare_lock when dropping a ref on a struct
    clk_core. The release function is only freeing memory and any code with
    a pointer reference has already unlinked anything pointing to the
    clk_core. This reduces the holding area of the prepare_lock a bit.
    
    Note that we also don't call free_clk() with the prepare_lock held.
    There isn't any reason to do that.
    
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Link: https://lore.kernel.org/r/20240325184204.745706-3-sboyd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change [+ + +]
Author: Jernej Skrabec <jernej.skrabec@gmail.com>
Date:   Fri Oct 13 20:17:12 2023 +0200

    clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change
    
    [ Upstream commit 7e91ed763dc07437777bd012af7a2bd4493731ff ]
    
    While PLL CPUX clock rate change when CPU is running from it works in
    vast majority of cases, now and then it causes instability. This leads
    to system crashes and other undefined behaviour. After a lot of testing
    (30+ hours) while also doing a lot of frequency switches, we can't
    observe any instability issues anymore when doing reparenting to stable
    clock like 24 MHz oscillator.
    
    Fixes: 524353ea480b ("clk: sunxi-ng: add support for the Allwinner H6 CCU")
    Reported-by: Chad Wagner <wagnerch42@gmail.com>
    Link: https://forum.libreelec.tv/thread/27295-orange-pi-3-lts-freezes/
    Tested-by: Chad Wagner <wagnerch42@gmail.com>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Link: https://lore.kernel.org/r/20231013181712.2128037-1-jernej.skrabec@gmail.com
    Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxgb4: Properly lock TX queue for the selftest. [+ + +]
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Mon Apr 29 11:11:47 2024 +0200

    cxgb4: Properly lock TX queue for the selftest.
    
    [ Upstream commit 9067eccdd7849dd120d5495dbd5a686fa6ed2c1a ]
    
    The selftest for the driver sends a dummy packet and checks if the
    packet will be received properly as it should be. The regular TX path
    and the selftest can use the same network queue so locking is required
    and was missing in the selftest path. This was addressed in the commit
    cited below.
    Unfortunately locking the TX queue requires BH to be disabled which is
    not the case in selftest path which is invoked in process context.
    Lockdep should be complaining about this.
    
    Use __netif_tx_lock_bh() for TX queue locking.
    
    Fixes: c650e04898072 ("cxgb4: Fix race between loopback and normal Tx path")
    Reported-by: "John B. Wyatt IV" <jwyatt@redhat.com>
    Closes: https://lore.kernel.org/all/Zic0ot5aGgR-V4Ks@thinkpad2021/
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Link: https://lore.kernel.org/r/20240429091147.YWAaal4v@linutronix.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: pl330: issue_pending waits until WFP state [+ + +]
Author: Bumyong Lee <bumyong.lee@samsung.com>
Date:   Tue Dec 19 14:50:26 2023 +0900

    dmaengine: pl330: issue_pending waits until WFP state
    
    [ Upstream commit 22a9d9585812440211b0b34a6bc02ade62314be4 ]
    
    According to DMA-330 errata notice[1] 71930, DMAKILL
    cannot clear internal signal, named pipeline_req_active.
    it makes that pl330 would wait forever in WFP state
    although dma already send dma request if pl330 gets
    dma request before entering WFP state.
    
    The errata suggests that polling until entering WFP state
    as workaround and then peripherals allows to issue dma request.
    
    [1]: https://developer.arm.com/documentation/genc008428/latest
    
    Signed-off-by: Bumyong Lee <bumyong.lee@samsung.com>
    Link: https://lore.kernel.org/r/20231219055026.118695-1-bumyong.lee@samsung.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Stable-dep-of: afc89870ea67 ("dmaengine: Revert "dmaengine: pl330: issue_pending waits until WFP state"")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
dmaengine: Revert "dmaengine: pl330: issue_pending waits until WFP state" [+ + +]
Author: Vinod Koul <vkoul@kernel.org>
Date:   Thu Mar 28 12:21:51 2024 +0530

    dmaengine: Revert "dmaengine: pl330: issue_pending waits until WFP state"
    
    [ Upstream commit afc89870ea677bd5a44516eb981f7a259b74280c ]
    
    This reverts commit 22a9d9585812 ("dmaengine: pl330: issue_pending waits
    until WFP state") as it seems to cause regression in pl330 driver.
    Note the issue now exists in mainline so a fix to be done.
    
    Cc: stable@vger.kernel.org
    Reported-by: karthikeyan <karthikeyan@linumiz.com>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Atom Integrated System Info v2_2 for DCN35 [+ + +]
Author: Gabe Teeger <gabe.teeger@amd.com>
Date:   Tue Apr 9 10:38:58 2024 -0400

    drm/amd/display: Atom Integrated System Info v2_2 for DCN35
    
    [ Upstream commit 9a35d205f466501dcfe5625ca313d944d0ac2d60 ]
    
    New request from KMD/VBIOS in order to support new UMA carveout
    model. This fixes a null dereference from accessing
    Ctx->dc_bios->integrated_info while it was NULL.
    
    DAL parses through the BIOS and extracts the necessary
    integrated_info but was missing a case for the new BIOS
    version 2.3.
    
    Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Gabe Teeger <gabe.teeger@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/connector: Add \n to message about demoting connector force-probes [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu May 2 15:32:35 2024 -0700

    drm/connector: Add \n to message about demoting connector force-probes
    
    [ Upstream commit 6897204ea3df808d342c8e4613135728bc538bcd ]
    
    The debug print clearly lacks a \n at the end. Add it.
    
    Fixes: 8f86c82aba8b ("drm/connector: demote connector force-probes for non-master clients")
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Reviewed-by: Simon Ser <contact@emersion.fr>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240502153234.1.I2052f01c8d209d9ae9c300b87c6e4f60bd3cc99e@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/meson: dw-hdmi: add bandgap setting for g12 [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Fri Apr 26 18:02:54 2024 +0200

    drm/meson: dw-hdmi: add bandgap setting for g12
    
    [ Upstream commit 08001033121dd92b8297a5b7333636b466c30f13 ]
    
    When no mode is set, the utility pin appears to be grounded. No signal
    is getting through.
    
    This is problematic because ARC and eARC use this line and may do so even
    if no display mode is set.
    
    This change enable the bandgap setting on g12 chip, which fix the problem
    with the utility pin. This is done by restoring init values on PHY init and
    disable.
    
    Fixes: 3b7c1237a72a ("drm/meson: Add G12A support for the DW-HDMI Glue")
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20240426160256.3089978-3-jbrunet@baylibre.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240426160256.3089978-3-jbrunet@baylibre.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/meson: dw-hdmi: power up phy on device init [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Fri Apr 26 18:02:53 2024 +0200

    drm/meson: dw-hdmi: power up phy on device init
    
    [ Upstream commit 04703bfd7f99c016a823c74712b97f8b5590ce87 ]
    
    The phy is not in a useful state right after init. It will become useful,
    including for auxiliary function such as CEC or ARC, after the first mode
    is set. This is a problem on systems where the display is using another
    interface like DSI or CVBS.
    
    This change refactor the init and mode change callback to power up the PHY
    on init and leave only what is necessary for mode changes in the related
    function. This is enough to fix CEC operation when HDMI display is not
    enabled.
    
    Fixes: 3f68be7d8e96 ("drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY")
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20240426160256.3089978-2-jbrunet@baylibre.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240426160256.3089978-2-jbrunet@baylibre.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/nouveau/dp: Don't probe eDP ports twice harder [+ + +]
Author: Lyude Paul <lyude@redhat.com>
Date:   Thu Apr 4 19:35:54 2024 -0400

    drm/nouveau/dp: Don't probe eDP ports twice harder
    
    [ Upstream commit bf52d7f9b2067f02efe7e32697479097aba4a055 ]
    
    I didn't pay close enough attention the last time I tried to fix this
    problem - while we currently do correctly take care to make sure we don't
    probe a connected eDP port more then once, we don't do the same thing for
    eDP ports we found to be disconnected.
    
    So, fix this and make sure we only ever probe eDP ports once and then leave
    them at that connector state forever (since without HPD, it's not going to
    change on its own anyway). This should get rid of the last few GSP errors
    getting spit out during runtime suspend and resume on some machines, as we
    tried to reprobe eDP ports in response to ACPI hotplug probe events.
    
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240404233736.7946-3-lyude@redhat.com
    (cherry picked from commit fe6660b661c3397af0867d5d098f5b26581f1290)
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/panel: ili9341: Respect deferred probe [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Apr 25 17:26:18 2024 +0300

    drm/panel: ili9341: Respect deferred probe
    
    [ Upstream commit 740fc1e0509be3f7e2207e89125b06119ed62943 ]
    
    GPIO controller might not be available when driver is being probed.
    There are plenty of reasons why, one of which is deferred probe.
    
    Since GPIOs are optional, return any error code we got to the upper
    layer, including deferred probe. With that in mind, use dev_err_probe()
    in order to avoid spamming the logs.
    
    Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Reviewed-by: Sui Jingfeng <sui.jingfeng@linux.dev>
    Link: https://lore.kernel.org/r/20240425142706.2440113-3-andriy.shevchenko@linux.intel.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240425142706.2440113-3-andriy.shevchenko@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/panel: ili9341: Use predefined error codes [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Apr 25 17:26:19 2024 +0300

    drm/panel: ili9341: Use predefined error codes
    
    [ Upstream commit da85f0aaa9f21999753b01d45c0343f885a8f905 ]
    
    In one case the -1 is returned which is quite confusing code for
    the wrong device ID, in another the ret is returning instead of
    plain 0 that also confusing as readed may ask the possible meaning
    of positive codes, which are never the case there. Convert both
    to use explicit predefined error codes to make it clear what's going
    on there.
    
    Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Reviewed-by: Sui Jingfeng <sui.jingfeng@linux.dev>
    Link: https://lore.kernel.org/r/20240425142706.2440113-4-andriy.shevchenko@linux.intel.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240425142706.2440113-4-andriy.shevchenko@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/vmwgfx: Fix invalid reads in fence signaled events [+ + +]
Author: Zack Rusin <zack.rusin@broadcom.com>
Date:   Thu Apr 25 15:27:48 2024 -0400

    drm/vmwgfx: Fix invalid reads in fence signaled events
    
    commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.
    
    Correctly set the length of the drm_event to the size of the structure
    that's actually used.
    
    The length of the drm_event was set to the parent structure instead of
    to the drm_vmw_event_fence which is supposed to be read. drm_read
    uses the length parameter to copy the event to the user space thus
    resuling in oob reads.
    
    Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
    Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-23566
    Cc: David Airlie <airlied@gmail.com>
    CC: Daniel Vetter <daniel@ffwll.ch>
    Cc: Zack Rusin <zack.rusin@broadcom.com>
    Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: linux-kernel@vger.kernel.org
    Cc: <stable@vger.kernel.org> # v3.4+
    Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
    Reviewed-by: Martin Krastev <martin.krastev@broadcom.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.rusin@broadcom.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dt-bindings: iio: health: maxim,max30102: fix compatible check [+ + +]
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Sat Mar 16 23:56:57 2024 +0100

    dt-bindings: iio: health: maxim,max30102: fix compatible check
    
    commit 89384a2b656b9dace4c965432a209d5c9c3a2a6f upstream.
    
    The "maxim,green-led-current-microamp" property is only available for
    the max30105 part (it provides an extra green LED), and must be set to
    false for the max30102 part.
    
    Instead, the max30100 part has been used for that, which is not
    supported by this binding (it has its own binding).
    
    This error was introduced during the txt to yaml conversion.
    
    Fixes: 5a6a65b11e3a ("dt-bindings:iio:health:maxim,max30102: txt to yaml conversion")
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Acked-by: Conor Dooley <conor.dooley@microchip.com>
    Link: https://lore.kernel.org/r/20240316-max30102_binding_fix-v1-1-e8e58f69ef8a@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dyndbg: fix old BUG_ON in >control parser [+ + +]
Author: Jim Cromie <jim.cromie@gmail.com>
Date:   Mon Apr 29 13:31:11 2024 -0600

    dyndbg: fix old BUG_ON in >control parser
    
    commit 00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c upstream.
    
    Fix a BUG_ON from 2009.  Even if it looks "unreachable" (I didn't
    really look), lets make sure by removing it, doing pr_err and return
    -EINVAL instead.
    
    Cc: stable <stable@kernel.org>
    Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
    Link: https://lore.kernel.org/r/20240429193145.66543-2-jim.cromie@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
eeprom: at24: fix memory corruption race condition [+ + +]
Author: Daniel Okazaki <dtokazaki@google.com>
Date:   Mon Apr 22 17:43:36 2024 +0000

    eeprom: at24: fix memory corruption race condition
    
    [ Upstream commit f42c97027fb75776e2e9358d16bf4a99aeb04cf2 ]
    
    If the eeprom is not accessible, an nvmem device will be registered, the
    read will fail, and the device will be torn down. If another driver
    accesses the nvmem device after the teardown, it will reference
    invalid memory.
    
    Move the failure point before registering the nvmem device.
    
    Signed-off-by: Daniel Okazaki <dtokazaki@google.com>
    Fixes: b20eb4c1f026 ("eeprom: at24: drop unnecessary label")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240422174337.2487142-1-dtokazaki@google.com
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

eeprom: at24: Probe for DDR3 thermal sensor in the SPD case [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed Dec 20 13:55:58 2023 +0100

    eeprom: at24: Probe for DDR3 thermal sensor in the SPD case
    
    [ Upstream commit caba40ec3531b0849f44502a03117796e8c9f4a1 ]
    
    The DDR3 SPD data structure advertises the presence of a thermal
    sensor on a DDR3 module in byte 32, bit 7. Let's use this information
    to explicitly instantiate the thermal sensor I2C client instead of
    having to rely on class-based I2C probing.
    
    The temp sensor i2c address can be derived from the SPD i2c address,
    so we can directly instantiate the device and don't have to probe
    for it. If the temp sensor has been instantiated already by other
    means (e.g. class-based auto-detection), then the busy-check in
    i2c_new_client_device will detect this.
    
    Note: Thermal sensors on DDR4 DIMM's are instantiated from the
          ee1004 driver.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/68113672-3724-44d5-9ff8-313dd6628f8c@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: f42c97027fb7 ("eeprom: at24: fix memory corruption race condition")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

eeprom: at24: Use dev_err_probe for nvmem register failure [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Tue May 16 10:05:53 2023 +0200

    eeprom: at24: Use dev_err_probe for nvmem register failure
    
    [ Upstream commit a3c10035d12f5ec10915d5c00c2e8f7d7c066182 ]
    
    When using nvmem layouts it is possible devm_nvmem_register returns
    -EPROBE_DEFER, resulting in an 'empty' in
    /sys/kernel/debug/devices_deferred. Use dev_err_probe for providing
    additional information.
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Stable-dep-of: f42c97027fb7 ("eeprom: at24: fix memory corruption race condition")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
firewire: nosy: ensure user_length is taken into account when fetching packet contents [+ + +]
Author: Thanassis Avgerinos <thanassis.avgerinos@gmail.com>
Date:   Wed Apr 17 11:30:02 2024 -0400

    firewire: nosy: ensure user_length is taken into account when fetching packet contents
    
    commit 38762a0763c10c24a4915feee722d7aa6e73eb98 upstream.
    
    Ensure that packet_buffer_get respects the user_length provided. If
    the length of the head packet exceeds the user_length, packet_buffer_get
    will now return 0 to signify to the user that no data were read
    and a larger buffer size is required. Helps prevent user space overflows.
    
    Signed-off-by: Thanassis Avgerinos <thanassis.avgerinos@gmail.com>
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

firewire: ohci: mask bus reset interrupts between ISR and bottom half [+ + +]
Author: Adam Goldman <adamg@pobox.com>
Date:   Mon Mar 25 07:38:41 2024 +0900

    firewire: ohci: mask bus reset interrupts between ISR and bottom half
    
    [ Upstream commit 752e3c53de0fa3b7d817a83050b6699b8e9c6ec9 ]
    
    In the FireWire OHCI interrupt handler, if a bus reset interrupt has
    occurred, mask bus reset interrupts until bus_reset_work has serviced and
    cleared the interrupt.
    
    Normally, we always leave bus reset interrupts masked. We infer the bus
    reset from the self-ID interrupt that happens shortly thereafter. A
    scenario where we unmask bus reset interrupts was introduced in 2008 in
    a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
    OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
    will unmask bus reset interrupts so we can log them.
    
    irq_handler logs the bus reset interrupt. However, we can't clear the bus
    reset event flag in irq_handler, because we won't service the event until
    later. irq_handler exits with the event flag still set. If the
    corresponding interrupt is still unmasked, the first bus reset will
    usually freeze the system due to irq_handler being called again each
    time it exits. This freeze can be reproduced by loading firewire_ohci
    with "modprobe firewire_ohci debug=-1" (to enable all debugging output).
    Apparently there are also some cases where bus_reset_work will get called
    soon enough to clear the event, and operation will continue normally.
    
    This freeze was first reported a few months after a007bb85 was committed,
    but until now it was never fixed. The debug level could safely be set
    to -1 through sysfs after the module was loaded, but this would be
    ineffectual in logging bus reset interrupts since they were only
    unmasked during initialization.
    
    irq_handler will now leave the event flag set but mask bus reset
    interrupts, so irq_handler won't be called again and there will be no
    freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
    unmask the interrupt after servicing the event, so future interrupts
    will be caught as desired.
    
    As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
    enabled through sysfs in addition to during initial module loading.
    However, when enabled through sysfs, logging of bus reset interrupts will
    be effective only starting with the second bus reset, after
    bus_reset_work has executed.
    
    Signed-off-by: Adam Goldman <adamg@pobox.com>
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs/9p: drop inodes immediately on non-.L too [+ + +]
Author: Joakim Sindholt <opensource@zhasha.com>
Date:   Mon Mar 18 12:22:32 2024 +0100

    fs/9p: drop inodes immediately on non-.L too
    
    [ Upstream commit 7fd524b9bd1be210fe79035800f4bd78a41b349f ]
    
    Signed-off-by: Joakim Sindholt <opensource@zhasha.com>
    Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/9p: only translate RWX permissions for plain 9P2000 [+ + +]
Author: Joakim Sindholt <opensource@zhasha.com>
Date:   Mon Mar 18 12:22:31 2024 +0100

    fs/9p: only translate RWX permissions for plain 9P2000
    
    [ Upstream commit cd25e15e57e68a6b18dc9323047fe9c68b99290b ]
    
    Garbage in plain 9P2000's perm bits is allowed through, which causes it
    to be able to set (among others) the suid bit. This was presumably not
    the intent since the unix extended bits are handled explicitly and
    conditionally on .u.
    
    Signed-off-by: Joakim Sindholt <opensource@zhasha.com>
    Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/9p: translate O_TRUNC into OTRUNC [+ + +]
Author: Joakim Sindholt <opensource@zhasha.com>
Date:   Mon Mar 18 12:22:33 2024 +0100

    fs/9p: translate O_TRUNC into OTRUNC
    
    [ Upstream commit 87de39e70503e04ddb58965520b15eb9efa7eef3 ]
    
    This one hits both 9P2000 and .u as it appears v9fs has never translated
    the O_TRUNC flag.
    
    Signed-off-by: Joakim Sindholt <opensource@zhasha.com>
    Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gfs2: Fix invalid metadata access in punch_hole [+ + +]
Author: Andrew Price <anprice@redhat.com>
Date:   Mon Mar 11 16:40:36 2024 +0100

    gfs2: Fix invalid metadata access in punch_hole
    
    [ Upstream commit c95346ac918c5badf51b9a7ac58a26d3bd5bb224 ]
    
    In punch_hole(), when the offset lies in the final block for a given
    height, there is no hole to punch, but the maximum size check fails to
    detect that.  Consequently, punch_hole() will try to punch a hole beyond
    the end of the metadata and fail.  Fix the maximum size check.
    
    Signed-off-by: Andrew Price <anprice@redhat.com>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gpio: crystalcove: Use -ENOTSUPP consistently [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Apr 5 19:26:22 2024 +0300

    gpio: crystalcove: Use -ENOTSUPP consistently
    
    [ Upstream commit ace0ebe5c98d66889f19e0f30e2518d0c58d0e04 ]
    
    The GPIO library expects the drivers to return -ENOTSUPP in some
    cases and not using analogue POSIX code. Make the driver to follow
    this.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gpio: wcove: Use -ENOTSUPP consistently [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Apr 5 19:25:21 2024 +0300

    gpio: wcove: Use -ENOTSUPP consistently
    
    [ Upstream commit 0c3b532ad3fbf82884a2e7e83e37c7dcdd4d1d99 ]
    
    The GPIO library expects the drivers to return -ENOTSUPP in some
    cases and not using analogue POSIX code. Make the driver to follow
    this.
    
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gpu: host1x: Do not setup DMA for virtual devices [+ + +]
Author: Thierry Reding <treding@nvidia.com>
Date:   Thu Mar 14 16:49:43 2024 +0100

    gpu: host1x: Do not setup DMA for virtual devices
    
    [ Upstream commit 8ab58f6841b19423231c5db3378691ec80c778f8 ]
    
    The host1x devices are virtual compound devices and do not perform DMA
    accesses themselves, so they do not need to be set up for DMA.
    
    Ideally we would also not need to set up DMA masks for the virtual
    devices, but we currently still need those for legacy support on old
    hardware.
    
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Acked-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240314154943.2487549-1-thierry.reding@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwmon: (corsair-cpro) Protect ccp->wait_input_report with a spinlock [+ + +]
Author: Aleksa Savic <savicaleksa83@gmail.com>
Date:   Sat May 4 11:25:03 2024 +0200

    hwmon: (corsair-cpro) Protect ccp->wait_input_report with a spinlock
    
    [ Upstream commit d02abd57e79469a026213f7f5827a98d909f236a ]
    
    Through hidraw, userspace can cause a status report to be sent
    from the device. The parsing in ccp_raw_event() may happen in
    parallel to a send_usb_cmd() call (which resets the completion
    for tracking the report) if it's running on a different CPU where
    bottom half interrupts are not disabled.
    
    Add a spinlock around the complete_all() in ccp_raw_event() and
    reinit_completion() in send_usb_cmd() to prevent race issues.
    
    Fixes: 40c3a4454225 ("hwmon: add Corsair Commander Pro driver")
    Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com>
    Acked-by: Marius Zachmann <mail@mariuszachmann.de>
    Link: https://lore.kernel.org/r/20240504092504.24158-4-savicaleksa83@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (corsair-cpro) Use a separate buffer for sending commands [+ + +]
Author: Aleksa Savic <savicaleksa83@gmail.com>
Date:   Sat May 4 11:25:01 2024 +0200

    hwmon: (corsair-cpro) Use a separate buffer for sending commands
    
    [ Upstream commit e0cd85dc666cb08e1bd313d560cb4eff4d04219e ]
    
    Introduce cmd_buffer, a separate buffer for storing only
    the command that is sent to the device. Before this separation,
    the existing buffer was shared for both the command and the
    report received in ccp_raw_event(), which was copied into it.
    
    However, because of hidraw, the raw event parsing may be triggered
    in the middle of sending a command, resulting in outputting gibberish
    to the device. Using a separate buffer resolves this.
    
    Fixes: 40c3a4454225 ("hwmon: add Corsair Commander Pro driver")
    Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com>
    Acked-by: Marius Zachmann <mail@mariuszachmann.de>
    Link: https://lore.kernel.org/r/20240504092504.24158-2-savicaleksa83@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (corsair-cpro) Use complete_all() instead of complete() in ccp_raw_event() [+ + +]
Author: Aleksa Savic <savicaleksa83@gmail.com>
Date:   Sat May 4 11:25:02 2024 +0200

    hwmon: (corsair-cpro) Use complete_all() instead of complete() in ccp_raw_event()
    
    [ Upstream commit 3a034a7b0715eb51124a5263890b1ed39978ed3a ]
    
    In ccp_raw_event(), the ccp->wait_input_report completion is
    completed once. Since we're waiting for exactly one report in
    send_usb_cmd(), use complete_all() instead of complete()
    to mark the completion as spent.
    
    Fixes: 40c3a4454225 ("hwmon: add Corsair Commander Pro driver")
    Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com>
    Acked-by: Marius Zachmann <mail@mariuszachmann.de>
    Link: https://lore.kernel.org/r/20240504092504.24158-3-savicaleksa83@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (pmbus/ucd9000) Increase delay from 250 to 500us [+ + +]
Author: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
Date:   Tue May 7 14:46:03 2024 -0500

    hwmon: (pmbus/ucd9000) Increase delay from 250 to 500us
    
    commit 26e8383b116d0dbe74e28f86646563ab46d66d83 upstream.
    
    Following the failure observed with a delay of 250us, experiments were
    conducted with various delays. It was found that a delay of 350us
    effectively mitigated the issue.
    
    To provide a more optimal solution while still allowing a margin for
    stability, the delay is being adjusted to 500us.
    
    Signed-off-by: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
    Link: https://lore.kernel.org/r/20240507194603.1305750-1-lakshmiy@us.ibm.com
    Fixes: 8d655e6523764 ("hwmon: (ucd90320) Add minimum delay between bus accesses")
    Reviewed-by: Eddie James <eajames@linux.ibm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iio: accel: mxc4005: Interrupt handling fixes [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Mar 26 12:36:59 2024 +0100

    iio: accel: mxc4005: Interrupt handling fixes
    
    commit 57a1592784d622ecee0b71940c65429173996b33 upstream.
    
    There are 2 issues with interrupt handling in the mxc4005 driver:
    
    1. mxc4005_set_trigger_state() writes MXC4005_REG_INT_MASK1_BIT_DRDYE
    (0x01) to INT_MASK1 to enable the interrupt, but to disable the interrupt
    it writes ~MXC4005_REG_INT_MASK1_BIT_DRDYE which is 0xfe, so it enables
    all other interrupt sources in the INT_SRC1 register. On the MXC4005 this
    is not an issue because only bit 0 of the register is used. On the MXC6655
    OTOH this is a problem since bit7 is used as TC (Temperature Compensation)
    disable bit and writing 1 to this disables Temperature Compensation which
    should only be done when running self-tests on the chip.
    
    Write 0 instead of ~MXC4005_REG_INT_MASK1_BIT_DRDYE to disable
    the interrupts to fix this.
    
    2. The datasheets for the MXC4005 / MXC6655 do not state what the reset
    value for the INT_MASK0 and INT_MASK1 registers is and since these are
    write only we also cannot learn this from the hw. Presumably the reset
    value for both is all 0, which means all interrupts disabled.
    
    Explicitly set both registers to 0 from mxc4005_chip_init() to ensure
    both masks are actually set to 0.
    
    Fixes: 79846e33aac1 ("iio: accel: mxc4005: add support for mxc6655")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240326113700.56725-2-hdegoede@redhat.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: iio:imu: adis16475: Fix sync mode setting [+ + +]
Author: Ramona Gradinariu <ramona.bolboaca13@gmail.com>
Date:   Fri Apr 5 07:53:09 2024 +0300

    iio:imu: adis16475: Fix sync mode setting
    
    commit 74a72baf204fd509bbe8b53eec35e39869d94341 upstream.
    
    Fix sync mode setting by applying the necessary shift bits.
    
    Fixes: fff7352bf7a3 ("iio: imu: Add support for adis16475")
    Signed-off-by: Ramona Gradinariu <ramona.bolboaca13@gmail.com>
    Reviewed-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20240405045309.816328-2-ramona.bolboaca13@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iommu: mtk: fix module autoloading [+ + +]
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Wed Apr 10 18:41:09 2024 +0200

    iommu: mtk: fix module autoloading
    
    [ Upstream commit 7537e31df80cb58c27f3b6fef702534ea87a5957 ]
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
    based on the alias from of_device_id table.
    
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Link: https://lore.kernel.org/r/20240410164109.233308-1-krzk@kernel.org
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue May 7 16:31:45 2024 +0000

    ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
    
    [ Upstream commit d101291b2681e5ab938554e3e323f7a7ee33e3aa ]
    
    syzbot is able to trigger the following crash [1],
    caused by unsafe ip6_dst_idev() use.
    
    Indeed ip6_dst_idev() can return NULL, and must always be checked.
    
    [1]
    
    Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
     RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]
     RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267
    Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c
    RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700
    RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760
    RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd
    R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000
    R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00
    FS:  00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
      fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317
      fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108
      ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]
      ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649
      ip6_route_output include/net/ip6_route.h:93 [inline]
      ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120
      ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250
      sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326
      sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455
      sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662
      sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099
      __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197
      sctp_connect net/sctp/socket.c:4819 [inline]
      sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834
      __sys_connect_file net/socket.c:2048 [inline]
      __sys_connect+0x2df/0x310 net/socket.c:2065
      __do_sys_connect net/socket.c:2075 [inline]
      __se_sys_connect net/socket.c:2072 [inline]
      __x64_sys_connect+0x7a/0x90 net/socket.c:2072
      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: 5e5f3f0f8013 ("[IPV6] ADDRCONF: Convert ipv6_get_saddr() to ipv6_dev_get_saddr().")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20240507163145.835254-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kbuild: Disable KCSAN for autogenerated *.mod.c intermediaries [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Tue Mar 26 21:25:48 2024 +0100

    kbuild: Disable KCSAN for autogenerated *.mod.c intermediaries
    
    [ Upstream commit 54babdc0343fff2f32dfaafaaa9e42c4db278204 ]
    
    When KCSAN and CONSTRUCTORS are enabled, one can trigger the
    
      "Unpatched return thunk in use. This should not happen!"
    
    catch-all warning.
    
    Usually, when objtool runs on the .o objects, it does generate a section
    .return_sites which contains all offsets in the objects to the return
    thunks of the functions present there. Those return thunks then get
    patched at runtime by the alternatives.
    
    KCSAN and CONSTRUCTORS add this to the object file's .text.startup
    section:
    
      -------------------
      Disassembly of section .text.startup:
    
      ...
    
      0000000000000010 <_sub_I_00099_0>:
        10:   f3 0f 1e fa             endbr64
        14:   e8 00 00 00 00          call   19 <_sub_I_00099_0+0x9>
                              15: R_X86_64_PLT32      __tsan_init-0x4
        19:   e9 00 00 00 00          jmp    1e <__UNIQUE_ID___addressable_cryptd_alloc_aead349+0x6>
                              1a: R_X86_64_PLT32      __x86_return_thunk-0x4
      -------------------
    
    which, if it is built as a module goes through the intermediary stage of
    creating a <module>.mod.c file which, when translated, receives a second
    constructor:
    
      -------------------
      Disassembly of section .text.startup:
    
      0000000000000010 <_sub_I_00099_0>:
        10:   f3 0f 1e fa             endbr64
        14:   e8 00 00 00 00          call   19 <_sub_I_00099_0+0x9>
                              15: R_X86_64_PLT32      __tsan_init-0x4
        19:   e9 00 00 00 00          jmp    1e <_sub_I_00099_0+0xe>
                              1a: R_X86_64_PLT32      __x86_return_thunk-0x4
    
      ...
    
      0000000000000030 <_sub_I_00099_0>:
        30:   f3 0f 1e fa             endbr64
        34:   e8 00 00 00 00          call   39 <_sub_I_00099_0+0x9>
                              35: R_X86_64_PLT32      __tsan_init-0x4
        39:   e9 00 00 00 00          jmp    3e <__ksymtab_cryptd_alloc_ahash+0x2>
                              3a: R_X86_64_PLT32      __x86_return_thunk-0x4
      -------------------
    
    in the .ko file.
    
    Objtool has run already so that second constructor's return thunk cannot
    be added to the .return_sites section and thus the return thunk remains
    unpatched and the warning rightfully fires.
    
    Drop KCSAN flags from the mod.c generation stage as those constructors
    do not contain data races one would be interested about.
    
    Debugged together with David Kaplan <David.Kaplan@amd.com> and Nikolay
    Borisov <nik.borisov@suse.com>.
    
    Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Closes: https://lore.kernel.org/r/0851a207-7143-417e-be31-8bf2b3afb57d@molgen.mpg.de
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> # Dell XPS 13
    Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
    Reviewed-by: Marco Elver <elver@google.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
keys: Fix overwrite of key expiration on instantiation [+ + +]
Author: Silvio Gissi <sifonsec@amazon.com>
Date:   Fri Mar 15 15:05:39 2024 -0400

    keys: Fix overwrite of key expiration on instantiation
    
    commit 9da27fb65a14c18efd4473e2e82b76b53ba60252 upstream.
    
    The expiry time of a key is unconditionally overwritten during
    instantiation, defaulting to turn it permanent. This causes a problem
    for DNS resolution as the expiration set by user-space is overwritten to
    TIME64_MAX, disabling further DNS updates. Fix this by restoring the
    condition that key_set_expiry is only called when the pre-parser sets a
    specific expiry.
    
    Fixes: 39299bdd2546 ("keys, dns: Allow key types (eg. DNS) to be reclaimed immediately on expiry")
    Signed-off-by: Silvio Gissi <sifonsec@amazon.com>
    cc: David Howells <dhowells@redhat.com>
    cc: Hazem Mohamed Abuelfotoh <abuehaze@amazon.com>
    cc: linux-afs@lists.infradead.org
    cc: linux-cifs@vger.kernel.org
    cc: keyrings@vger.kernel.org
    cc: netdev@vger.kernel.org
    cc: stable@vger.kernel.org
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ksmbd: clear RENAME_NOREPLACE before calling vfs_rename [+ + +]
Author: Marios Makassikis <mmakassikis@freebox.fr>
Date:   Mon Apr 15 15:12:48 2024 +0200

    ksmbd: clear RENAME_NOREPLACE before calling vfs_rename
    
    [ Upstream commit 4973b04d3ea577db80c501c5f14e68ec69fe1794 ]
    
    File overwrite case is explicitly handled, so it is not necessary to
    pass RENAME_NOREPLACE to vfs_rename.
    
    Clearing the flag fixes rename operations when the share is a ntfs-3g
    mount. The latter uses an older version of fuse with no support for
    flags in the ->rename op.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Marios Makassikis <mmakassikis@freebox.fr>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Thu Apr 11 23:02:15 2024 +0900

    ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf
    
    [ Upstream commit c119f4ede3fa90a9463f50831761c28f989bfb20 ]
    
    If ->ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size
    validation could be skipped. if request size is smaller than
    sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in
    smb2_allocate_rsp_buf(). This patch allocate response buffer after
    decrypting transform request. smb3_decrypt_req() will validate transform
    request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf().
    
    Reported-by: Norbert Szetei <norbert@doyensec.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: validate request buffer size in smb2_allocate_rsp_buf() [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Fri Apr 12 09:45:00 2024 +0900

    ksmbd: validate request buffer size in smb2_allocate_rsp_buf()
    
    [ Upstream commit 17cf0c2794bdb6f39671265aa18aea5c22ee8c4a ]
    
    The response buffer should be allocated in smb2_allocate_rsp_buf
    before validating request. But the fields in payload as well as smb2 header
    is used in smb2_allocate_rsp_buf(). This patch add simple buffer size
    validation to avoid potencial out-of-bounds in request buffer.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr() [+ + +]
Author: Oliver Upton <oliver.upton@linux.dev>
Date:   Wed Apr 24 17:39:58 2024 +0000

    KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr()
    
    [ Upstream commit 6ddb4f372fc63210034b903d96ebbeb3c7195adb ]
    
    vgic_v2_parse_attr() is responsible for finding the vCPU that matches
    the user-provided CPUID, which (of course) may not be valid. If the ID
    is invalid, kvm_get_vcpu_by_id() returns NULL, which isn't handled
    gracefully.
    
    Similar to the GICv3 uaccess flow, check that kvm_get_vcpu_by_id()
    actually returns something and fail the ioctl if not.
    
    Cc: stable@vger.kernel.org
    Fixes: 7d450e282171 ("KVM: arm/arm64: vgic-new: Add userland access to VGIC dist registers")
    Reported-by: Alexander Potapenko <glider@google.com>
    Tested-by: Alexander Potapenko <glider@google.com>
    Reviewed-by: Alexander Potapenko <glider@google.com>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20240424173959.3776798-2-oliver.upton@linux.dev
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: arm64: vgic-v2: Use cpuid from userspace as vcpu_id [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Wed Sep 27 10:09:04 2023 +0100

    KVM: arm64: vgic-v2: Use cpuid from userspace as vcpu_id
    
    [ Upstream commit 4e7728c81a54b17bd33be402ac140bc11bb0c4f4 ]
    
    When parsing a GICv2 attribute that contains a cpuid, handle this
    as the vcpu_id, not a vcpu_idx, as userspace cannot really know
    the mapping between the two. For this, use kvm_get_vcpu_by_id()
    instead of kvm_get_vcpu().
    
    Take this opportunity to get rid of the pointless check against
    online_vcpus, which doesn't make much sense either, and switch
    to FIELD_GET as a way to extract the vcpu_id.
    
    Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20230927090911.3355209-5-maz@kernel.org
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Stable-dep-of: 6ddb4f372fc6 ("KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.15.159 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri May 17 11:51:06 2024 +0200

    Linux 5.15.159
    
    Link: https://lore.kernel.org/r/20240514101006.678521560@linuxfoundation.org
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20240515082414.316080594@linuxfoundation.org
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
md: fix kmemleak of rdev->serial [+ + +]
Author: Li Nan <linan122@huawei.com>
Date:   Thu Feb 8 16:55:56 2024 +0800

    md: fix kmemleak of rdev->serial
    
    commit 6cf350658736681b9d6b0b6e58c5c76b235bb4c4 upstream.
    
    If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be
    alloc not be freed, and kmemleak occurs.
    
    unreferenced object 0xffff88815a350000 (size 49152):
      comm "mdadm", pid 789, jiffies 4294716910
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace (crc f773277a):
        [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0
        [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270
        [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f
        [<00000000f206d60a>] kvmalloc_node+0x74/0x150
        [<0000000034bf3363>] rdev_init_serial+0x67/0x170
        [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220
        [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630
        [<0000000073c28560>] md_add_new_disk+0x400/0x9f0
        [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10
        [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0
        [<0000000085086a11>] vfs_ioctl+0x22/0x60
        [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0
        [<00000000e54e675e>] do_syscall_64+0x71/0x150
        [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
    
    Fixes: 963c555e75b0 ("md: introduce mddev_create/destroy_wb_pool for the change of member device")
    Signed-off-by: Li Nan <linan122@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240208085556.2412922-1-linan666@huaweicloud.com
    [ mddev_destroy_serial_pool third parameter was removed in mainline,
      where there is no need to suspend within this function anymore. ]
    Signed-off-by: Jeremy Bongio <jbongio@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mei: me: add lunar lake point M DID [+ + +]
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Sun Apr 21 16:56:31 2024 +0300

    mei: me: add lunar lake point M DID
    
    commit 4108a30f1097eead0f6bd5d885e6bf093b4d460f upstream.
    
    Add Lunar (Point) Lake M device id.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Link: https://lore.kernel.org/r/20240421135631.223362-1-tomas.winkler@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
MIPS: scall: Save thread_info.syscall unconditionally on entry [+ + +]
Author: Jiaxun Yang <jiaxun.yang@flygoat.com>
Date:   Thu Mar 28 14:27:56 2024 +0000

    MIPS: scall: Save thread_info.syscall unconditionally on entry
    
    [ Upstream commit 4370b673ccf240bf7587b0cb8e6726a5ccaf1f17 ]
    
    thread_info.syscall is used by syscall_get_nr to supply syscall nr
    over a thread stack frame.
    
    Previously, thread_info.syscall is only saved at syscall_trace_enter
    when syscall tracing is enabled. However rest of the kernel code do
    expect syscall_get_nr to be available without syscall tracing. The
    previous design breaks collect_syscall.
    
    Move saving process to syscall entry to fix it.
    
    Reported-by: Xi Ruoyao <xry111@xry111.site>
    Link: https://github.com/util-linux/util-linux/issues/2867
    Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mptcp: ensure snd_nxt is properly initialized on connect [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Mon Apr 29 20:00:31 2024 +0200

    mptcp: ensure snd_nxt is properly initialized on connect
    
    commit fb7a0d334894206ae35f023a82cad5a290fd7386 upstream.
    
    Christoph reported a splat hinting at a corrupted snd_una:
    
      WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
      Modules linked in:
      CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
      Workqueue: events mptcp_worker
      RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
      Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
            8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
            <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
      RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293
      RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
      RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
      RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
      R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
      FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
      Call Trace:
       <TASK>
       __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
       mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
       __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615
       mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767
       process_one_work+0x1e0/0x560 kernel/workqueue.c:3254
       process_scheduled_works kernel/workqueue.c:3335 [inline]
       worker_thread+0x3c7/0x640 kernel/workqueue.c:3416
       kthread+0x121/0x170 kernel/kthread.c:388
       ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147
       ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
       </TASK>
    
    When fallback to TCP happens early on a client socket, snd_nxt
    is not yet initialized and any incoming ack will copy such value
    into snd_una. If the mptcp worker (dumbly) tries mptcp-level
    re-injection after such ack, that would unconditionally trigger a send
    buffer cleanup using 'bad' snd_una values.
    
    We could easily disable re-injection for fallback sockets, but such
    dumb behavior already helped catching a few subtle issues and a very
    low to zero impact in practice.
    
    Instead address the issue always initializing snd_nxt (and write_seq,
    for consistency) at connect time.
    
    Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect")
    Cc: stable@vger.kernel.org
    Reported-by: Christoph Paasch <cpaasch@apple.com>
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485
    Tested-by: Christoph Paasch <cpaasch@apple.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net l2tp: drop flow hash on forward [+ + +]
Author: David Bauer <mail@david-bauer.net>
Date:   Wed Apr 24 19:11:10 2024 +0200

    net l2tp: drop flow hash on forward
    
    [ Upstream commit 42f853b42899d9b445763b55c3c8adc72be0f0e1 ]
    
    Drop the flow-hash of the skb when forwarding to the L2TP netdev.
    
    This avoids the L2TP qdisc from using the flow-hash from the outer
    packet, which is identical for every flow within the tunnel.
    
    This does not affect every platform but is specific for the ethernet
    driver. It depends on the platform including L4 information in the
    flow-hash.
    
    One such example is the Mediatek Filogic MT798x family of networking
    processors.
    
    Fixes: d9e31d17ceba ("l2tp: Add L2TP ethernet pseudowire support")
    Acked-by: James Chapman <jchapman@katalix.com>
    Signed-off-by: David Bauer <mail@david-bauer.net>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240424171110.13701-1-mail@david-bauer.net
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: bcmgenet: Reset RBUF on first open [+ + +]
Author: Phil Elwell <phil@raspberrypi.com>
Date:   Mon Apr 1 13:09:33 2024 +0200

    net: bcmgenet: Reset RBUF on first open
    
    [ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ]
    
    If the RBUF logic is not reset when the kernel starts then there
    may be some data left over from any network boot loader. If the
    64-byte packet headers are enabled then this can be fatal.
    
    Extend bcmgenet_dma_disable to do perform the reset, but not when
    called from bcmgenet_resume in order to preserve a wake packet.
    
    N.B. This different handling of resume is just based on a hunch -
    why else wouldn't one reset the RBUF as well as the TBUF? If this
    isn't the case then it's easy to change the patch to make the RBUF
    reset unconditional.
    
    See: https://github.com/raspberrypi/linux/issues/3850
    See: https://github.com/raspberrypi/firmware/issues/1882
    
    Signed-off-by: Phil Elwell <phil@raspberrypi.com>
    Signed-off-by: Maarten Vanraes <maarten@rmail.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bcmgenet: synchronize use of bcmgenet_set_rx_mode() [+ + +]
Author: Doug Berger <opendmb@gmail.com>
Date:   Thu Apr 25 15:27:20 2024 -0700

    net: bcmgenet: synchronize use of bcmgenet_set_rx_mode()
    
    commit 2dbe5f19368caae63b1f59f5bc2af78c7d522b3a upstream.
    
    The ndo_set_rx_mode function is synchronized with the
    netif_addr_lock spinlock and BHs disabled. Since this
    function is also invoked directly from the driver the
    same synchronization should be applied.
    
    Fixes: 72f96347628e ("net: bcmgenet: set Rx mode before starting netif")
    Cc: stable@vger.kernel.org
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: bridge: fix corrupted ethernet header on multicast-to-unicast [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Sun May 5 20:42:38 2024 +0200

    net: bridge: fix corrupted ethernet header on multicast-to-unicast
    
    [ Upstream commit 86b29d830ad69eecff25b22dc96c14c6573718e6 ]
    
    The change from skb_copy to pskb_copy unfortunately changed the data
    copying to omit the ethernet header, since it was pulled before reaching
    this point. Fix this by calling __skb_push/pull around pskb_copy.
    
    Fixes: 59c878cbcdd8 ("net: bridge: fix multicast-to-unicast with fraglist GSO")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bridge: fix multicast-to-unicast with fraglist GSO [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Sat Apr 27 20:24:18 2024 +0200

    net: bridge: fix multicast-to-unicast with fraglist GSO
    
    [ Upstream commit 59c878cbcdd80ed39315573b3511d0acfd3501b5 ]
    
    Calling skb_copy on a SKB_GSO_FRAGLIST skb is not valid, since it returns
    an invalid linearized skb. This code only needs to change the ethernet
    header, so pskb_copy is the right function to call here.
    
    Fixes: 6db6f0eae605 ("bridge: multicast to unicast")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: core: reject skb_copy(_expand) for fraglist GSO skbs [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Sat Apr 27 20:24:19 2024 +0200

    net: core: reject skb_copy(_expand) for fraglist GSO skbs
    
    [ Upstream commit d091e579b864fa790dd6a0cd537a22c383126681 ]
    
    SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become
    invalid. Return NULL if such an skb is passed to skb_copy or
    skb_copy_expand, in order to prevent a crash on a potential later
    call to skb_gso_segment.
    
    Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: mv88e6xxx: Fix number of databases for 88E6141 / 88E6341 [+ + +]
Author: Marek Beh├║n <kabel@kernel.org>
Date:   Mon Apr 29 15:38:32 2024 +0200

    net: dsa: mv88e6xxx: Fix number of databases for 88E6141 / 88E6341
    
    [ Upstream commit b9a61c20179fda7bdfe2c1210aa72451991ab81a ]
    
    The Topaz family (88E6141 and 88E6341) only support 256 Forwarding
    Information Tables.
    
    Fixes: a75961d0ebfd ("net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341")
    Fixes: 1558727a1c1b ("net: dsa: mv88e6xxx: Add support for ethernet switch 88E6141")
    Signed-off-by: Marek Beh├║n <kabel@kernel.org>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://lore.kernel.org/r/20240429133832.9547-1-kabel@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: fix out-of-bounds access in ops_init [+ + +]
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Thu May 2 10:20:06 2024 -0300

    net: fix out-of-bounds access in ops_init
    
    commit a26ff37e624d12e28077e5b24d2b264f62764ad6 upstream.
    
    net_alloc_generic is called by net_alloc, which is called without any
    locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It
    is read twice, first to allocate an array, then to set s.len, which is
    later used to limit the bounds of the array access.
    
    It is possible that the array is allocated and another thread is
    registering a new pernet ops, increments max_gen_ptrs, which is then used
    to set s.len with a larger than allocated length for the variable array.
    
    Fix it by reading max_gen_ptrs only once in net_alloc_generic. If
    max_gen_ptrs is later incremented, it will be caught in net_assign_generic.
    
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Fixes: 073862ba5d24 ("netns: fix net_alloc_generic()")
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240502132006.3430840-1-cascardo@igalia.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: gro: add flush check in udp_gro_receive_segment [+ + +]
Author: Richard Gobert <richardbgobert@gmail.com>
Date:   Tue Apr 30 16:35:55 2024 +0200

    net: gro: add flush check in udp_gro_receive_segment
    
    [ Upstream commit 5babae777c61aa8a8679d59d3cdc54165ad96d42 ]
    
    GRO-GSO path is supposed to be transparent and as such L3 flush checks are
    relevant to all UDP flows merging in GRO. This patch uses the same logic
    and code from tcp_gro_receive, terminating merge if flush is non zero.
    
    Fixes: e20cf8d3f1f7 ("udp: implement GRO for plain UDP sockets.")
    Signed-off-by: Richard Gobert <richardbgobert@gmail.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: add log for workqueue scheduled late [+ + +]
Author: Yufeng Mo <moyufeng@huawei.com>
Date:   Wed Nov 24 09:06:51 2021 +0800

    net: hns3: add log for workqueue scheduled late
    
    [ Upstream commit d9069dab207534d9f6f41993ee78a651733becea ]
    
    When the mbx or reset message arrives, the driver is informed
    through an interrupt. This task can be processed only after
    the workqueue is scheduled. In some cases, this workqueue
    scheduling takes a long time. As a result, the mbx or reset
    service task cannot be processed in time. So add some warning
    message to improve debugging efficiency for this case.
    
    Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 669554c512d2 ("net: hns3: direct return when receive a unknown mailbox message")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: add query vf ring and vector map relation [+ + +]
Author: Guangbin Huang <huangguangbin2@huawei.com>
Date:   Mon May 9 15:55:31 2022 +0800

    net: hns3: add query vf ring and vector map relation
    
    [ Upstream commit a1aed456e3261c0096e36618db9aa61d5974ad16 ]
    
    This patch adds a new mailbox opcode to query map relation between
    vf ring and vector.
    
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 669554c512d2 ("net: hns3: direct return when receive a unknown mailbox message")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: change type of numa_node_mask as nodemask_t [+ + +]
Author: Peiyang Wang <wangpeiyang1@huawei.com>
Date:   Tue May 7 21:42:20 2024 +0800

    net: hns3: change type of numa_node_mask as nodemask_t
    
    [ Upstream commit 6639a7b953212ac51aa4baa7d7fb855bf736cf56 ]
    
    It provides nodemask_t to describe the numa node mask in kernel. To
    improve transportability, change the type of numa_node_mask as nodemask_t.
    
    Fixes: 38caee9d3ee8 ("net: hns3: Add support of the HNAE3 framework")
    Signed-off-by: Peiyang Wang <wangpeiyang1@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: create new cmdq hardware description structure hclge_comm_hw [+ + +]
Author: Jie Wang <wangjie125@huawei.com>
Date:   Fri Dec 31 18:22:32 2021 +0800

    net: hns3: create new cmdq hardware description structure hclge_comm_hw
    
    [ Upstream commit 0a7b6d221868be6aa3249c70ffab707a265b89d6 ]
    
    Currently PF and VF cmdq APIs use struct hclge(vf)_hw to describe cmdq
    hardware information needed by hclge(vf)_cmd_send. There are a little
    differences between its child struct hclge_cmq_ring and hclgevf_cmq_ring.
    It is redundent to use two sets of structures to support same functions.
    
    So this patch creates new set of common cmdq hardware description
    structures(hclge_comm_hw) to unify PF and VF cmdq functions. The struct
    hclge_desc is still kept to avoid too many meaningless replacement.
    
    These new structures will be used to unify hclge(vf)_hw structures in PF
    and VF cmdq APIs in next patches.
    
    Signed-off-by: Jie Wang <wangjie125@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 6639a7b95321 ("net: hns3: change type of numa_node_mask as nodemask_t")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: create new set of unified hclge_comm_cmd_send APIs [+ + +]
Author: Jie Wang <wangjie125@huawei.com>
Date:   Fri Dec 31 18:22:34 2021 +0800

    net: hns3: create new set of unified hclge_comm_cmd_send APIs
    
    [ Upstream commit 8d307f8e8cf195921b10939dde673f1f039bd732 ]
    
    This patch create new set of unified hclge_comm_cmd_send APIs for PF and VF
    cmdq module. Subfunctions called by hclge_comm_cmd_send are also created
    include cmdq result check, cmdq return code conversion and ring space
    opertaion APIs.
    
    These new common cmdq APIs will be used to replace the old PF and VF cmdq
    APIs in next patches.
    
    Signed-off-by: Jie Wang <wangjie125@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 6639a7b95321 ("net: hns3: change type of numa_node_mask as nodemask_t")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: direct return when receive a unknown mailbox message [+ + +]
Author: Jian Shen <shenjian15@huawei.com>
Date:   Tue May 7 21:42:19 2024 +0800

    net: hns3: direct return when receive a unknown mailbox message
    
    [ Upstream commit 669554c512d2107e2f21616f38e050d40655101f ]
    
    Currently, the driver didn't return when receive a unknown
    mailbox message, and continue checking whether need to
    generate a response. It's unnecessary and may be incorrect.
    
    Fixes: bb5790b71bad ("net: hns3: refactor mailbox response scheme between PF and VF")
    Signed-off-by: Jian Shen <shenjian15@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: fix port vlan filter not disabled issue [+ + +]
Author: Yonglong Liu <liuyonglong@huawei.com>
Date:   Tue May 7 21:42:23 2024 +0800

    net: hns3: fix port vlan filter not disabled issue
    
    [ Upstream commit f5db7a3b65c84d723ca5e2bb6e83115180ab6336 ]
    
    According to hardware limitation, for device support modify
    VLAN filter state but not support bypass port VLAN filter,
    it should always disable the port VLAN filter. but the driver
    enables port VLAN filter when initializing, if there is no
    VLAN(except VLAN 0) id added, the driver will disable it
    in service task. In most time, it works fine. But there is
    a time window before the service task shceduled and net device
    being registered. So if user adds VLAN at this time, the driver
    will not update the VLAN filter state,  and the port VLAN filter
    remains enabled.
    
    To fix the problem, if support modify VLAN filter state but not
    support bypass port VLAN filter, set the port vlan filter to "off".
    
    Fixes: 184cd221a863 ("net: hns3: disable port VLAN filter when support function level VLAN filter control")
    Fixes: 2ba306627f59 ("net: hns3: add support for modify VLAN filter state")
    Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: PF support get unicast MAC address space assigned by firmware [+ + +]
Author: Guangbin Huang <huangguangbin2@huawei.com>
Date:   Tue Sep 14 20:11:16 2021 +0800

    net: hns3: PF support get unicast MAC address space assigned by firmware
    
    [ Upstream commit e435a6b5315a05a4e4e9f77679a57fd0d679e384 ]
    
    Currently, there are two ways for PF to set the unicast MAC address space
    size: specified by config parameters in firmware or set to default value.
    
    That's mean if the config parameters in firmware is zero, driver will
    divide the whole unicast MAC address space equally to 8 PFs. However, in
    this case, the unicast MAC address space will be wasted a lot when the
    hardware actually has less then 8 PFs. And in the other hand, if one PF has
    much more VFs than other PFs, then each function of this PF will has much
    less address space than other PFs.
    
    In order to ameliorate the above two situations, introduce the third way
    of unicast MAC address space assignment: firmware divides the whole unicast
    MAC address space equally to functions of all PFs, and calculates the space
    size of each PF according to its function number. PF queries the space size
    by the querying device specification command when in initialization
    process.
    
    The third way assignment is lower priority than specified by config
    parameters, only if the config parameters is zero can be used, and if
    firmware does not support the third way assignment, then driver still
    divides the whole unicast MAC address space equally to 8 PFs.
    
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 05eb60e9648c ("net: hns3: using user configure after hardware reset")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: refactor function hclge_mbx_handler() [+ + +]
Author: Hao Lan <lanhao@huawei.com>
Date:   Fri Sep 16 10:38:02 2022 +0800

    net: hns3: refactor function hclge_mbx_handler()
    
    [ Upstream commit 09431ed8de874881e2d5d430042d718ae074d371 ]
    
    Currently, the function hclge_mbx_handler() has too many switch-case
    statements, it makes this function too long. To improve code readability,
    refactor this function and use lookup table instead.
    
    Signed-off-by: Hao Lan <lanhao@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 669554c512d2 ("net: hns3: direct return when receive a unknown mailbox message")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: refactor hclge_cmd_send with new hclge_comm_cmd_send API [+ + +]
Author: Jie Wang <wangjie125@huawei.com>
Date:   Fri Dec 31 18:22:35 2021 +0800

    net: hns3: refactor hclge_cmd_send with new hclge_comm_cmd_send API
    
    [ Upstream commit eaa5607db377a73e639162a459d8b125c6a67bfb ]
    
    This patch firstly uses new hardware description struct hclge_comm_hw as
    child member of hclge_hw and deletes the original child memebers of
    hclge_hw. All the hclge_hw variables used in PF module is modified
    according to the new hclge_hw.
    
    Secondly hclge_cmd_send is refactored to use hclge_comm_cmd_send APIs. The
    old functions called by hclge_cmd_send are deleted and hclge_cmd_send is
    kept to avoid too many meaningless modifications.
    
    Signed-off-by: Jie Wang <wangjie125@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 6639a7b95321 ("net: hns3: change type of numa_node_mask as nodemask_t")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: refactor hns3 makefile to support hns3_common module [+ + +]
Author: Jie Wang <wangjie125@huawei.com>
Date:   Fri Dec 31 18:22:31 2021 +0800

    net: hns3: refactor hns3 makefile to support hns3_common module
    
    [ Upstream commit 5f20be4e90e603d8967962f81ac89307fd4f8af9 ]
    
    Currently we plan to refactor PF and VF cmdq module. A new file folder
    hns3_common will be created to store new common APIs used by PF and VF
    cmdq module. Thus the PF and VF compilation process will both depends on
    the hns3_common. This may cause parallel building problems if we add a new
    makefile building unit.
    
    So this patch combined the PF and VF makefile scripts to the top level
    makefile to support the new hns3_common which will be created in the next
    patch.
    
    Signed-off-by: Jie Wang <wangjie125@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 6639a7b95321 ("net: hns3: change type of numa_node_mask as nodemask_t")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: split function hclge_init_vlan_config() [+ + +]
Author: Jian Shen <shenjian15@huawei.com>
Date:   Thu Dec 2 16:35:57 2021 +0800

    net: hns3: split function hclge_init_vlan_config()
    
    [ Upstream commit b60f9d2ec479966383c7f2cdf3b1a3a66c25f212 ]
    
    Currently the function hclge_init_vlan_config() is a bit long.
    Split it to several small functions, to simplify code and
    improve code readability.
    
    Signed-off-by: Jian Shen <shenjian15@huawei.com>
    Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: f5db7a3b65c8 ("net: hns3: fix port vlan filter not disabled issue")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: use appropriate barrier function after setting a bit value [+ + +]
Author: Peiyang Wang <wangpeiyang1@huawei.com>
Date:   Tue May 7 21:42:22 2024 +0800

    net: hns3: use appropriate barrier function after setting a bit value
    
    [ Upstream commit 094c281228529d333458208fd02fcac3b139d93b ]
    
    There is a memory barrier in followed case. When set the port down,
    hclgevf_set_timmer will set DOWN in state. Meanwhile, the service task has
    different behaviour based on whether the state is DOWN. Thus, to make sure
    service task see DOWN, use smp_mb__after_atomic after calling set_bit().
    
              CPU0                        CPU1
    ========================== ===================================
    hclgevf_set_timer_task()    hclgevf_periodic_service_task()
      set_bit(DOWN,state)         test_bit(DOWN,state)
    
    pf also has this issue.
    
    Fixes: ff200099d271 ("net: hns3: remove unnecessary work in hclgevf_main")
    Fixes: 1c6dfe6fc6f7 ("net: hns3: remove mailbox and reset work in hclge_main")
    Signed-off-by: Peiyang Wang <wangpeiyang1@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: using user configure after hardware reset [+ + +]
Author: Peiyang Wang <wangpeiyang1@huawei.com>
Date:   Tue May 7 21:42:18 2024 +0800

    net: hns3: using user configure after hardware reset
    
    [ Upstream commit 05eb60e9648cca0beeebdbcd263b599fb58aee48 ]
    
    When a reset occurring, it's supposed to recover user's configuration.
    Currently, the port info(speed, duplex and autoneg) is stored in hclge_mac
    and will be scheduled updated. Consider the case that reset was happened
    consecutively. During the first reset, the port info is configured with
    a temporary value cause the PHY is reset and looking for best link config.
    Second reset start and use pervious configuration which is not the user's.
    The specific process is as follows:
    
    +------+               +----+                +----+
    | USER |               | PF |                | HW |
    +---+--+               +-+--+                +-+--+
        |  ethtool --reset   |                     |
        +------------------->|    reset command    |
        |  ethtool --reset   +-------------------->|
        +------------------->|                     +---+
        |                    +---+                 |   |
        |                    |   |reset currently  |   | HW RESET
        |                    |   |and wait to do   |   |
        |                    |<--+                 |   |
        |                    | send pervious cfg   |<--+
        |                    | (1000M FULL AN_ON)  |
        |                    +-------------------->|
        |                    | read cfg(time task) |
        |                    | (10M HALF AN_OFF)   +---+
        |                    |<--------------------+   | cfg take effect
        |                    |    reset command    |<--+
        |                    +-------------------->|
        |                    |                     +---+
        |                    | send pervious cfg   |   | HW RESET
        |                    | (10M HALF AN_OFF)   |<--+
        |                    +-------------------->|
        |                    | read cfg(time task) |
        |                    |  (10M HALF AN_OFF)  +---+
        |                    |<--------------------+   | cfg take effect
        |                    |                     |   |
        |                    | read cfg(time task) |<--+
        |                    |  (10M HALF AN_OFF)  |
        |                    |<--------------------+
        |                    |                     |
        v                    v                     v
    
    To avoid aboved situation, this patch introduced req_speed, req_duplex,
    req_autoneg to store user's configuration and it only be used after
    hardware reset and to recover user's configuration
    
    Fixes: f5f2b3e4dcc0 ("net: hns3: add support for imp-controlled PHYs")
    Signed-off-by: Peiyang Wang <wangpeiyang1@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mark racy access on sk->sk_rcvbuf [+ + +]
Author: linke li <lilinke99@qq.com>
Date:   Thu Mar 21 16:44:10 2024 +0800

    net: mark racy access on sk->sk_rcvbuf
    
    [ Upstream commit c2deb2e971f5d9aca941ef13ee05566979e337a4 ]
    
    sk->sk_rcvbuf in __sock_queue_rcv_skb() and __sk_receive_skb() can be
    changed by other threads. Mark this as benign using READ_ONCE().
    
    This patch is aimed at reducing the number of benign races reported by
    KCSAN in order to focus future debugging effort on harmful races.
    
    Signed-off-by: linke li <lilinke99@qq.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: qede: sanitize 'rc' in qede_add_tc_flower_fltr() [+ + +]
Author: Asbj├Şrn Sloth T├Şnnesen <ast@fiberby.net>
Date:   Fri Apr 26 09:12:23 2024 +0000

    net: qede: sanitize 'rc' in qede_add_tc_flower_fltr()
    
    [ Upstream commit e25714466abd9d96901b15efddf82c60a38abd86 ]
    
    Explicitly set 'rc' (return code), before jumping to the
    unlock and return path.
    
    By not having any code depend on that 'rc' remains at
    it's initial value of -EINVAL, then we can re-use 'rc' for
    the return code of function calls in subsequent patches.
    
    Only compile tested.
    
    Signed-off-by: Asbj├Şrn Sloth T├Şnnesen <ast@fiberby.net>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: fcee2065a178 ("net: qede: use return from qede_parse_flow_attr() for flower")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: qede: use return from qede_parse_actions() [+ + +]
Author: Asbj├Şrn Sloth T├Şnnesen <ast@fiberby.net>
Date:   Fri Apr 26 09:12:26 2024 +0000

    net: qede: use return from qede_parse_actions()
    
    [ Upstream commit f26f719a36e56381a1f4230e5364e7ad4d485888 ]
    
    When calling qede_parse_actions() then the
    return code was only used for a non-zero check,
    and then -EINVAL was returned.
    
    qede_parse_actions() can currently fail with:
    * -EINVAL
    * -EOPNOTSUPP
    
    This patch changes the code to use the actual
    return code, not just return -EINVAL.
    
    The blaimed commit broke the implicit assumption
    that only -EINVAL would ever be returned.
    
    Only compile tested.
    
    Fixes: 319a1d19471e ("flow_offload: check for basic action hw stats type")
    Signed-off-by: Asbj├Şrn Sloth T├Şnnesen <ast@fiberby.net>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: qede: use return from qede_parse_flow_attr() for flow_spec [+ + +]
Author: Asbj├Şrn Sloth T├Şnnesen <ast@fiberby.net>
Date:   Fri Apr 26 09:12:25 2024 +0000

    net: qede: use return from qede_parse_flow_attr() for flow_spec
    
    [ Upstream commit 27b44414a34b108c5a37cd5b4894f606061d86e7 ]
    
    In qede_flow_spec_to_rule(), when calling
    qede_parse_flow_attr() then the return code
    was only used for a non-zero check, and then
    -EINVAL was returned.
    
    qede_parse_flow_attr() can currently fail with:
    * -EINVAL
    * -EOPNOTSUPP
    * -EPROTONOSUPPORT
    
    This patch changes the code to use the actual
    return code, not just return -EINVAL.
    
    The blaimed commit introduced qede_flow_spec_to_rule(),
    and this call to qede_parse_flow_attr(), it looks
    like it just duplicated how it was already used.
    
    Only compile tested.
    
    Fixes: 37c5d3efd7f8 ("qede: use ethtool_rx_flow_rule() to remove duplicated parser code")
    Signed-off-by: Asbj├Şrn Sloth T├Şnnesen <ast@fiberby.net>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: qede: use return from qede_parse_flow_attr() for flower [+ + +]
Author: Asbj├Şrn Sloth T├Şnnesen <ast@fiberby.net>
Date:   Fri Apr 26 09:12:24 2024 +0000

    net: qede: use return from qede_parse_flow_attr() for flower
    
    [ Upstream commit fcee2065a178f78be6fd516302830378b17dba3d ]
    
    In qede_add_tc_flower_fltr(), when calling
    qede_parse_flow_attr() then the return code
    was only used for a non-zero check, and then
    -EINVAL was returned.
    
    qede_parse_flow_attr() can currently fail with:
    * -EINVAL
    * -EOPNOTSUPP
    * -EPROTONOSUPPORT
    
    This patch changes the code to use the actual
    return code, not just return -EINVAL.
    
    The blaimed commit introduced these functions.
    
    Only compile tested.
    
    Fixes: 2ce9c93eaca6 ("qede: Ingress tc flower offload (drop action) support.")
    Signed-off-by: Asbj├Şrn Sloth T├Şnnesen <ast@fiberby.net>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: net:usb:qmi_wwan: support Rolling modules [+ + +]
Author: Vanillan Wang <vanillanwang@163.com>
Date:   Tue Apr 16 20:07:13 2024 +0800

    net:usb:qmi_wwan: support Rolling modules
    
    [ Upstream commit d362046021ea122309da8c8e0b6850c792ca97b5 ]
    
    Update the qmi_wwan driver support for the Rolling
    LTE modules.
    
    - VID:PID 33f8:0104, RW101-GL for laptop debug M.2 cards(with RMNET
    interface for /Linux/Chrome OS)
    0x0104: RMNET, diag, at, pipe
    
    Here are the outputs of usb-devices:
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=33f8 ProdID=0104 Rev=05.04
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=Rolling Module
    S:  SerialNumber=ba2eb033
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=83(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=1024 Ivl=0ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=88(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=89(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    Signed-off-by: Vanillan Wang <vanillanwang@163.com>
    Link: https://lore.kernel.org/r/20240416120713.24777-1-vanillanwang@163.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfs: expose /proc/net/sunrpc/nfs in net namespaces [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Thu Feb 15 14:57:31 2024 -0500

    nfs: expose /proc/net/sunrpc/nfs in net namespaces
    
    [ Upstream commit d47151b79e3220e72ae323b8b8e9d6da20dc884e ]
    
    We're using nfs mounts inside of containers in production and noticed
    that the nfs stats are not exposed in /proc.  This is a problem for us
    as we use these stats for monitoring, and have to do this awkward bind
    mount from the main host into the container in order to get to these
    states.
    
    Add the rpc_proc_register call to the pernet operations entry and exit
    points so these stats can be exposed inside of network namespaces.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Stable-dep-of: 24457f1be29f ("nfs: Handle error of rpc_proc_register() in nfs_net_init().")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nfs: Handle error of rpc_proc_register() in nfs_net_init(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu Apr 4 15:12:00 2024 -0700

    nfs: Handle error of rpc_proc_register() in nfs_net_init().
    
    [ Upstream commit 24457f1be29f1e7042e50a7749f5c2dde8c433c8 ]
    
    syzkaller reported a warning [0] triggered while destroying immature
    netns.
    
    rpc_proc_register() was called in init_nfs_fs(), but its error
    has been ignored since at least the initial commit 1da177e4c3f4
    ("Linux-2.6.12-rc2").
    
    Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs
    in net namespaces") converted the procfs to per-netns and made
    the problem more visible.
    
    Even when rpc_proc_register() fails, nfs_net_init() could succeed,
    and thus nfs_net_exit() will be called while destroying the netns.
    
    Then, remove_proc_entry() will be called for non-existing proc
    directory and trigger the warning below.
    
    Let's handle the error of rpc_proc_register() properly in nfs_net_init().
    
    [0]:
    name 'nfs'
    WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
    Modules linked in:
    CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
    Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb
    RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286
    RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c
    RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001
    RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc
    R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8
    FS:  00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <TASK>
     rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310
     nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438
     ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170
     setup_net+0x46c/0x660 net/core/net_namespace.c:372
     copy_net_ns+0x244/0x590 net/core/net_namespace.c:505
     create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110
     unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228
     ksys_unshare+0x342/0x760 kernel/fork.c:3322
     __do_sys_unshare kernel/fork.c:3393 [inline]
     __se_sys_unshare kernel/fork.c:3391 [inline]
     __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x46/0x4e
    RIP: 0033:0x7f30d0febe5d
    Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
    RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
    RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600
    RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
    R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000
     </TASK>
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nfs: make the rpc_stat per net namespace [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Thu Feb 15 14:57:32 2024 -0500

    nfs: make the rpc_stat per net namespace
    
    [ Upstream commit 1548036ef1204df65ca5a16e8b199c858cb80075 ]
    
    Now that we're exposing the rpc stats on a per-network namespace basis,
    move this struct into struct nfs_net and use that to make sure only the
    per-network namespace stats are exposed.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Stable-dep-of: 24457f1be29f ("nfs: Handle error of rpc_proc_register() in nfs_net_init().")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Apr 23 19:35:49 2024 -0700

    nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment().
    
    [ Upstream commit 4b911a9690d72641879ea6d13cce1de31d346d79 ]
    
    syzbot triggered various splats (see [0] and links) by a crafted GSO
    packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:
    
      ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP
    
    NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS.  As the inner
    protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls
    skb_mac_gso_segment() to invoke inner protocol GSO handlers.
    
    nsh_gso_segment() does the following for the original skb before
    calling skb_mac_gso_segment()
    
      1. reset skb->network_header
      2. save the original skb->{mac_heaeder,mac_len} in a local variable
      3. pull the NSH header
      4. resets skb->mac_header
      5. set up skb->mac_len and skb->protocol for the inner protocol.
    
    and does the following for the segmented skb
    
      6. set ntohs(ETH_P_NSH) to skb->protocol
      7. push the NSH header
      8. restore skb->mac_header
      9. set skb->mac_header + mac_len to skb->network_header
     10. restore skb->mac_len
    
    There are two problems in 6-7 and 8-9.
    
      (a)
      After 6 & 7, skb->data points to the NSH header, so the outer header
      (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.
    
      Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),
      skb_pull() in the first nsh_gso_segment() will make skb->data point
      to the middle of the outer NSH or Ethernet header because the Ethernet
      header is not pulled by the second nsh_gso_segment().
    
      (b)
      While restoring skb->{mac_header,network_header} in 8 & 9,
      nsh_gso_segment() does not assume that the data in the linear
      buffer is shifted.
    
      However, udp6_ufo_fragment() could shift the data and change
      skb->mac_header accordingly as demonstrated by syzbot.
    
      If this happens, even the restored skb->mac_header points to
      the middle of the outer header.
    
    It seems nsh_gso_segment() has never worked with outer headers so far.
    
    At the end of nsh_gso_segment(), the outer header must be restored for
    the segmented skb, instead of the NSH header.
    
    To do that, let's calculate the outer header position relatively from
    the inner header and set skb->{data,mac_header,protocol} properly.
    
    [0]:
    BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]
    BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
    BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668
     ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]
     ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
     ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668
     ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222
     __netdev_start_xmit include/linux/netdevice.h:4989 [inline]
     netdev_start_xmit include/linux/netdevice.h:5003 [inline]
     xmit_one net/core/dev.c:3547 [inline]
     dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563
     __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351
     dev_queue_xmit include/linux/netdevice.h:3171 [inline]
     packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
     packet_snd net/packet/af_packet.c:3081 [inline]
     packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg net/socket.c:745 [inline]
     __sys_sendto+0x735/0xa10 net/socket.c:2191
     __do_sys_sendto net/socket.c:2203 [inline]
     __se_sys_sendto net/socket.c:2199 [inline]
     __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
     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+0x63/0x6b
    
    Uninit was created at:
     slab_post_alloc_hook mm/slub.c:3819 [inline]
     slab_alloc_node mm/slub.c:3860 [inline]
     __do_kmalloc_node mm/slub.c:3980 [inline]
     __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001
     kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
     __alloc_skb+0x352/0x790 net/core/skbuff.c:651
     skb_segment+0x20aa/0x7080 net/core/skbuff.c:4647
     udp6_ufo_fragment+0xcab/0x1150 net/ipv6/udp_offload.c:109
     ipv6_gso_segment+0x14be/0x2ca0 net/ipv6/ip6_offload.c:152
     skb_mac_gso_segment+0x3e8/0x760 net/core/gso.c:53
     nsh_gso_segment+0x6f4/0xf70 net/nsh/nsh.c:108
     skb_mac_gso_segment+0x3e8/0x760 net/core/gso.c:53
     __skb_gso_segment+0x4b0/0x730 net/core/gso.c:124
     skb_gso_segment include/net/gso.h:83 [inline]
     validate_xmit_skb+0x107f/0x1930 net/core/dev.c:3628
     __dev_queue_xmit+0x1f28/0x51c0 net/core/dev.c:4343
     dev_queue_xmit include/linux/netdevice.h:3171 [inline]
     packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
     packet_snd net/packet/af_packet.c:3081 [inline]
     packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg net/socket.c:745 [inline]
     __sys_sendto+0x735/0xa10 net/socket.c:2191
     __do_sys_sendto net/socket.c:2203 [inline]
     __se_sys_sendto net/socket.c:2199 [inline]
     __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
     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+0x63/0x6b
    
    CPU: 1 PID: 5101 Comm: syz-executor421 Not tainted 6.8.0-rc5-syzkaller-00297-gf2e367d6ad3b #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
    
    Fixes: c411ed854584 ("nsh: add GSO support")
    Reported-and-tested-by: syzbot+42a0dc856239de4de60e@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=42a0dc856239de4de60e
    Reported-and-tested-by: syzbot+c298c9f0e46a3c86332b@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=c298c9f0e46a3c86332b
    Link: https://lore.kernel.org/netdev/20240415222041.18537-1-kuniyu@amazon.com/
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240424023549.21862-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-af: avoid off-by-one read from userspace [+ + +]
Author: Bui Quang Minh <minhquangbui99@gmail.com>
Date:   Wed Apr 24 21:44:23 2024 +0700

    octeontx2-af: avoid off-by-one read from userspace
    
    [ Upstream commit f299ee709fb45036454ca11e90cb2810fe771878 ]
    
    We try to access count + 1 byte from userspace with memdup_user(buffer,
    count + 1). However, the userspace only provides buffer of count bytes and
    only these count bytes are verified to be okay to access. To ensure the
    copied buffer is NUL terminated, we use memdup_user_nul instead.
    
    Fixes: 3a2eb515d136 ("octeontx2-af: Fix an off by one in rvu_dbg_qsize_write()")
    Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
    Link: https://lore.kernel.org/r/20240424-fix-oob-read-v2-6-f1f1b53a10f4@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
phonet: fix rtm_phonet_notify() skb allocation [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu May 2 16:17:00 2024 +0000

    phonet: fix rtm_phonet_notify() skb allocation
    
    [ Upstream commit d8cac8568618dcb8a51af3db1103e8d4cc4aeea7 ]
    
    fill_route() stores three components in the skb:
    
    - struct rtmsg
    - RTA_DST (u8)
    - RTA_OIF (u32)
    
    Therefore, rtm_phonet_notify() should use
    
    NLMSG_ALIGN(sizeof(struct rtmsg)) +
    nla_total_size(1) +
    nla_total_size(4)
    
    Fixes: f062f41d0657 ("Phonet: routing table Netlink interface")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: R├ęmi Denis-Courmont <courmisch@gmail.com>
    Link: https://lore.kernel.org/r/20240502161700.1804476-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl/meson: fix typo in PDM's pin name [+ + +]
Author: Jan Dakinevich <jan.dakinevich@salutedevices.com>
Date:   Mon Mar 25 14:30:58 2024 +0300

    pinctrl/meson: fix typo in PDM's pin name
    
    [ Upstream commit 368a90e651faeeb7049a876599cf2b0d74954796 ]
    
    Other pins have _a or _x suffix, but this one doesn't have any. Most
    likely this is a typo.
    
    Fixes: dabad1ff8561 ("pinctrl: meson: add pinctrl driver support for Meson-A1 SoC")
    Signed-off-by: Jan Dakinevich <jan.dakinevich@salutedevices.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Message-ID: <20240325113058.248022-1-jan.dakinevich@salutedevices.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: core: delete incorrect free in pinctrl_enable() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Mar 21 09:38:39 2024 +0300

    pinctrl: core: delete incorrect free in pinctrl_enable()
    
    [ Upstream commit 5038a66dad0199de60e5671603ea6623eb9e5c79 ]
    
    The "pctldev" struct is allocated in devm_pinctrl_register_and_init().
    It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
    so freeing it in pinctrl_enable() will lead to a double free.
    
    The devm_pinctrl_dev_release() function frees the pindescs and destroys
    the mutex as well.
    
    Fixes: 6118714275f0 ("pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Message-ID: <578fbe56-44e9-487c-ae95-29b695650f7c@moroto.mountain>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map() [+ + +]
Author: Zeng Heng <zengheng4@huawei.com>
Date:   Mon Apr 15 18:53:28 2024 +0800

    pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()
    
    [ Upstream commit a0cedbcc8852d6c77b00634b81e41f17f29d9404 ]
    
    If we fail to allocate propname buffer, we need to drop the reference
    count we just took. Because the pinctrl_dt_free_maps() includes the
    droping operation, here we call it directly.
    
    Fixes: 91d5c5060ee2 ("pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map")
    Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Zeng Heng <zengheng4@huawei.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Message-ID: <20240415105328.3651441-1-zengheng4@huawei.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: mediatek: paris: Fix PIN_CONFIG_INPUT_SCHMITT_ENABLE readback [+ + +]
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Mar 27 17:13:33 2024 +0800

    pinctrl: mediatek: paris: Fix PIN_CONFIG_INPUT_SCHMITT_ENABLE readback
    
    [ Upstream commit 08f66a8edd08f6f7cfa769c81634b29a2b123908 ]
    
    In the generic pin config library, readback of some options are handled
    differently compared to the setting of those options: the argument value
    is used to convey enable/disable of an option in the set path, but
    success or -EINVAL is used to convey if an option is enabled or disabled
    in the debugfs readback path.
    
    PIN_CONFIG_INPUT_SCHMITT_ENABLE is one such option. Fix the readback of
    the option in the mediatek-paris library, so that the debugfs dump is
    not showing "input schmitt enabled" for pins that don't have it enabled.
    
    Fixes: 1bea6afbc842 ("pinctrl: mediatek: Refine mtk_pinconf_get()")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Message-ID: <20240327091336.3434141-2-wenst@chromium.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: mediatek: paris: Rework mtk_pinconf_{get,set} switch/case logic [+ + +]
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Tue Mar 8 18:09:52 2022 +0800

    pinctrl: mediatek: paris: Rework mtk_pinconf_{get,set} switch/case logic
    
    [ Upstream commit 9b780fa1ff14663c2e0f07ad098b96b8337f27a4 ]
    
    The current code deals with optional features by testing for the
    function pointers and returning -ENOTSUPP if it is not valid. This is
    done for multiple pin config settings and results in the code that
    handles the supporting cases to get indented by one level. This is
    aggrevated by the fact that some features require another level of
    conditionals.
    
    Instead of assigning the same error code in all unsupported optional
    feature cases, simply have that error code as the default, and break
    out of the switch/case block whenever a feature is unsupported, or an
    error is returned. This reduces indentation by one level for the useful
    code.
    
    Also replace the goto statements with break statements. The result is
    the same, as the gotos simply exit the switch/case block, which can
    also be achieved with a break statement. With the latter the intent
    is clear and easier to understand.
    
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20220308100956.2750295-8-wenst@chromium.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Stable-dep-of: 08f66a8edd08 ("pinctrl: mediatek: paris: Fix PIN_CONFIG_INPUT_SCHMITT_ENABLE readback")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: mediatek: paris: Rework support for PIN_CONFIG_{INPUT,OUTPUT}_ENABLE [+ + +]
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Mar 27 17:13:34 2024 +0800

    pinctrl: mediatek: paris: Rework support for PIN_CONFIG_{INPUT,OUTPUT}_ENABLE
    
    [ Upstream commit c5d3b64c568a344e998830e0e94a7c04e372f89b ]
    
    There is a misinterpretation of some of the PIN_CONFIG_* options in this
    driver library. PIN_CONFIG_OUTPUT_ENABLE should refer to a buffer or
    switch in the output direction of the electrical path. The MediaTek
    hardware does not have such a thing. The driver incorrectly maps this
    option to the GPIO function's direction.
    
    Likewise, PIN_CONFIG_INPUT_ENABLE should refer to a buffer or switch in
    the input direction. The hardware does have such a mechanism, and is
    mapped to the IES bit. The driver however sets the direction in addition
    to the IES bit, which is incorrect. On readback, the IES bit isn't even
    considered.
    
    Ironically, the driver does not support readback for PIN_CONFIG_OUTPUT,
    while its readback of PIN_CONFIG_{INPUT,OUTPUT}_ENABLE is what it should
    be doing for PIN_CONFIG_OUTPUT.
    
    Rework support for these three options, so that PIN_CONFIG_OUTPUT_ENABLE
    is completely removed, PIN_CONFIG_INPUT_ENABLE is only linked to the IES
    bit, and PIN_CONFIG_OUTPUT is linked to the GPIO function's direction
    and output level.
    
    Fixes: 805250982bb5 ("pinctrl: mediatek: add pinctrl-paris that implements the vendor dt-bindings")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Message-ID: <20240327091336.3434141-3-wenst@chromium.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: pinctrl-aspeed-g6: Fix register offset for pinconf of GPIOR-T [+ + +]
Author: Billy Tsai <billy_tsai@aspeedtech.com>
Date:   Wed Mar 13 17:28:09 2024 +0800

    pinctrl: pinctrl-aspeed-g6: Fix register offset for pinconf of GPIOR-T
    
    [ Upstream commit c10cd03d69403fa0f00be8631bd4cb4690440ebd ]
    
    The register offset to disable the internal pull-down of GPIOR~T is 0x630
    instead of 0x620, as specified in the Ast2600 datasheet v15
    The datasheet can download from the official Aspeed website.
    
    Fixes: 15711ba6ff19 ("pinctrl: aspeed-g6: Add AST2600 pinconf support")
    Reported-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com>
    Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
    Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
    Message-ID: <20240313092809.2596644-1-billy_tsai@aspeedtech.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
power: rt9455: hide unused rt9455_boost_voltage_values [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Apr 3 10:06:27 2024 +0200

    power: rt9455: hide unused rt9455_boost_voltage_values
    
    [ Upstream commit 452d8950db3e839aba1bb13bc5378f4bac11fa04 ]
    
    The rt9455_boost_voltage_values[] array is only used when USB PHY
    support is enabled, causing a W=1 warning otherwise:
    
    drivers/power/supply/rt9455_charger.c:200:18: error: 'rt9455_boost_voltage_values' defined but not used [-Werror=unused-const-variable=]
    
    Enclose the definition in the same #ifdef as the references to it.
    
    Fixes: e86d69dd786e ("power_supply: Add support for Richtek RT9455 battery charger")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20240403080702.3509288-10-arnd@kernel.org
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

power: supply: mt6360_charger: Fix of_match for usb-otg-vbus regulator [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Wed Apr 10 10:44:05 2024 +0200

    power: supply: mt6360_charger: Fix of_match for usb-otg-vbus regulator
    
    [ Upstream commit 1e0fb113646182e073539db96016b00cfeb18ecc ]
    
    The of_match shall correspond to the name of the regulator subnode,
    or the deprecated `regulator-compatible` property must be used:
    failing to do so, the regulator won't probe (and the driver will
    as well not probe).
    
    Since the devicetree binding for this driver is actually correct
    and wants DTs to use the "usb-otg-vbus-regulator" subnode name,
    fix this driver by aligning the `of_match` string to what the DT
    binding wants.
    
    Fixes: 0402e8ebb8b8 ("power: supply: mt6360_charger: add MT6360 charger support")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
    Link: https://lore.kernel.org/r/20240410084405.1389378-1-angelogioacchino.delregno@collabora.com
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
qibfs: fix dentry leak [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Feb 25 23:58:42 2024 -0500

    qibfs: fix dentry leak
    
    [ Upstream commit aa23317d0268b309bb3f0801ddd0d61813ff5afb ]
    
    simple_recursive_removal() drops the pinning references to all positives
    in subtree.  For the cases when its argument has been kept alive by
    the pinning alone that's exactly the right thing to do, but here
    the argument comes from dcache lookup, that needs to be balanced by
    explicit dput().
    
    Fixes: e41d237818598 "qib_fs: switch to simple_recursive_removal()"
    Fucked-up-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Reapply "drm/qxl: simplify qxl_fence_wait" [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon May 6 13:28:59 2024 -0700

    Reapply "drm/qxl: simplify qxl_fence_wait"
    
    commit 3628e0383dd349f02f882e612ab6184e4bb3dc10 upstream.
    
    This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.
    
    Stephen Rostedt reports:
     "I went to run my tests on my VMs and the tests hung on boot up.
      Unfortunately, the most I ever got out was:
    
      [   93.607888] Testing event system initcall: OK
      [   93.667730] Running tests on all trace events:
      [   93.669757] Testing all events: OK
      [   95.631064] ------------[ cut here ]------------
      Timed out after 60 seconds"
    
    and further debugging points to a possible circular locking dependency
    between the console_owner locking and the worker pool locking.
    
    Reverting the commit allows Steve's VM to boot to completion again.
    
    [ This may obviously result in the "[TTM] Buffer eviction failed"
      messages again, which was the reason for that original revert. But at
      this point this seems preferable to a non-booting system... ]
    
    Reported-and-bisected-by: Steven Rostedt <rostedt@goodmis.org>
    Link: https://lore.kernel.org/all/20240502081641.457aa25f@gandalf.local.home/
    Acked-by: Maxime Ripard <mripard@kernel.org>
    Cc: Alex Constantino <dreaming.about.electric.sheep@gmail.com>
    Cc: Maxime Ripard <mripard@kernel.org>
    Cc: Timo Lindfors <timo.lindfors@iki.fi>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Gerd Hoffmann <kraxel@redhat.com>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
regulator: core: fix debugfs creation regression [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Thu May 9 15:33:04 2024 +0200

    regulator: core: fix debugfs creation regression
    
    commit 2a4b49bb58123bad6ec0e07b02845f74c23d5e04 upstream.
    
    regulator_get() may sometimes be called more than once for the same
    consumer device, something which before commit dbe954d8f163 ("regulator:
    core: Avoid debugfs: Directory ...  already present! error") resulted in
    errors being logged.
    
    A couple of recent commits broke the handling of such cases so that
    attributes are now erroneously created in the debugfs root directory the
    second time a regulator is requested and the log is filled with errors
    like:
    
            debugfs: File 'uA_load' in directory '/' already present!
            debugfs: File 'min_uV' in directory '/' already present!
            debugfs: File 'max_uV' in directory '/' already present!
            debugfs: File 'constraint_flags' in directory '/' already present!
    
    on any further calls.
    
    Fixes: 2715bb11cfff ("regulator: core: Fix more error checking for debugfs_create_dir()")
    Fixes: 08880713ceec ("regulator: core: Streamline debugfs operations")
    Cc: stable@vger.kernel.org
    Cc: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20240509133304.8883-1-johan+linaro@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: mt6360: De-capitalize devicetree regulator subnodes [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Tue Apr 9 16:44:38 2024 +0200

    regulator: mt6360: De-capitalize devicetree regulator subnodes
    
    [ Upstream commit d3cf8a17498dd9104c04ad28eeac3ef3339f9f9f ]
    
    The MT6360 regulator binding, the example in the MT6360 mfd binding, and
    the devicetree users of those bindings are rightfully declaring MT6360
    regulator subnodes with non-capital names, and luckily without using the
    deprecated regulator-compatible property.
    
    With this driver declaring capitalized BUCKx/LDOx as of_match string for
    the node names, obviously no regulator gets probed: fix that by changing
    the MT6360_REGULATOR_DESC macro to add a "match" parameter which gets
    assigned to the of_match.
    
    Fixes: d321571d5e4c ("regulator: mt6360: Add support for MT6360 regulator")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://msgid.link/r/20240409144438.410060-1-angelogioacchino.delregno@collabora.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "Revert "ACPI: CPPC: Use access_width over bit_width for system memory accesses"" [+ + +]
Author: Easwar Hariharan <eahariha@linux.microsoft.com>
Date:   Thu May 9 19:41:24 2024 +0000

    Revert "Revert "ACPI: CPPC: Use access_width over bit_width for system memory accesses""
    
    This reverts commit b54c4632946ae42f2b39ed38abd909bbf78cbcc2 which was a
    revert of a backport of commit 2f4a4d63a193be6fd530d180bb13c3592052904c
    upstream to 5.15.y.
    
    Cc: Jarred White <jarredwhite@linux.microsoft.com>
    Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation [+ + +]
Author: Roded Zats <rzats@paloaltonetworks.com>
Date:   Thu May 2 18:57:51 2024 +0300

    rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
    
    [ Upstream commit 1aec77b2bb2ed1db0f5efc61c4c1ca3813307489 ]
    
    Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a
    struct ifla_vf_vlan_info so the size of such attribute needs to be at least
    of sizeof(struct ifla_vf_vlan_info) which is 14 bytes.
    The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)
    which is less than sizeof(struct ifla_vf_vlan_info) so this validation
    is not enough and a too small attribute might be cast to a
    struct ifla_vf_vlan_info, this might result in an out of bands
    read access when accessing the saved (casted) entry in ivvl.
    
    Fixes: 79aab093a0b5 ("net: Update API for VF vlan protocol 802.1ad support")
    Signed-off-by: Roded Zats <rzats@paloaltonetworks.com>
    Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
    Link: https://lore.kernel.org/r/20240502155751.75705-1-rzats@paloaltonetworks.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/cio: Ensure the copied buf is NUL terminated [+ + +]
Author: Bui Quang Minh <minhquangbui99@gmail.com>
Date:   Wed Apr 24 21:44:22 2024 +0700

    s390/cio: Ensure the copied buf is NUL terminated
    
    [ Upstream commit da7c622cddd4fe36be69ca61e8c42e43cde94784 ]
    
    Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
    userspace to that buffer. Later, we use scanf on this buffer but we don't
    ensure that the string is terminated inside the buffer, this can lead to
    OOB read when using scanf. Fix this issue by using memdup_user_nul instead.
    
    Fixes: a4f17cc72671 ("s390/cio: add CRW inject functionality")
    Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240424-fix-oob-read-v2-5-f1f1b53a10f4@gmail.com
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/mm: Fix clearing storage keys for huge pages [+ + +]
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
Date:   Tue Apr 16 13:42:20 2024 +0200

    s390/mm: Fix clearing storage keys for huge pages
    
    [ Upstream commit 412050af2ea39407fe43324b0be4ab641530ce88 ]
    
    The function __storage_key_init_range() expects the end address to be
    the first byte outside the range to be initialized. I.e. end - start
    should be the size of the area to be initialized.
    
    The current code works because __storage_key_init_range() will still loop
    over every page in the range, but it is slower than using sske_frame().
    
    Fixes: 3afdfca69870 ("s390/mm: Clear skeys for newly mapped huge guest pmds")
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240416114220.28489-3-imbrenda@linux.ibm.com
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

s390/mm: Fix storage key clearing for guest huge pages [+ + +]
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
Date:   Tue Apr 16 13:42:19 2024 +0200

    s390/mm: Fix storage key clearing for guest huge pages
    
    [ Upstream commit 843c3280686fc1a83d89ee1e0b5599c9f6b09d0c ]
    
    The function __storage_key_init_range() expects the end address to be
    the first byte outside the range to be initialized. I.e. end - start
    should be the size of the area to be initialized.
    
    The current code works because __storage_key_init_range() will still loop
    over every page in the range, but it is slower than using sske_frame().
    
    Fixes: 964c2c05c9f3 ("s390/mm: Clear huge page storage keys on enable_skey")
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240416114220.28489-2-imbrenda@linux.ibm.com
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/qeth: don't keep track of Input Queue count [+ + +]
Author: Julian Wiedmann <jwi@linux.ibm.com>
Date:   Mon Oct 25 11:56:54 2021 +0200

    s390/qeth: don't keep track of Input Queue count
    
    [ Upstream commit dc15012bb083c70502b625cf56fbf32b6cf17fe4 ]
    
    The only actual user of qdio.no_input_queues is qeth_qdio_establish(),
    and there we already have full awareness of the current Input Queue
    configuration (1 RX queue, plus potentially 1 TX Completion queue).
    
    So avoid this state tracking, and the ambiguity it brings with it.
    
    Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 8a2e4d37afb8 ("s390/qeth: Fix kernel panic after setting hsuid")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

s390/qeth: Fix kernel panic after setting hsuid [+ + +]
Author: Alexandra Winter <wintera@linux.ibm.com>
Date:   Tue Apr 30 11:10:04 2024 +0200

    s390/qeth: Fix kernel panic after setting hsuid
    
    [ Upstream commit 8a2e4d37afb8500b276e5ee903dee06f50ab0494 ]
    
    Symptom:
    When the hsuid attribute is set for the first time on an IQD Layer3
    device while the corresponding network interface is already UP,
    the kernel will try to execute a napi function pointer that is NULL.
    
    Example:
    ---------------------------------------------------------------------------
    [ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP
    [ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6
    nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de
    s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod
     qdio ccwgroup pkey zcrypt
    [ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1
    [ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)
    [ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)
    [ 2057.572748]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
    [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000
    [ 2057.572754]            00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80
    [ 2057.572756]            000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8
    [ 2057.572758]            00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68
    [ 2057.572762] Krnl Code:#0000000000000000: 0000                illegal
                             >0000000000000002: 0000                illegal
                              0000000000000004: 0000                illegal
                              0000000000000006: 0000                illegal
                              0000000000000008: 0000                illegal
                              000000000000000a: 0000                illegal
                              000000000000000c: 0000                illegal
                              000000000000000e: 0000                illegal
    [ 2057.572800] Call Trace:
    [ 2057.572801] ([<00000000ec639700>] 0xec639700)
    [ 2057.572803]  [<00000000913183e2>] net_rx_action+0x2ba/0x398
    [ 2057.572809]  [<0000000091515f76>] __do_softirq+0x11e/0x3a0
    [ 2057.572813]  [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58
    [ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60)
    [ 2057.572822]  [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98
    [ 2057.572825]  [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70
    [ 2057.572827]  [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv]
    [ 2057.572830]  [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv]
    [ 2057.572833]  [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv]
    [ 2057.572835]  [<00000000912e7e90>] __sys_connect+0xa0/0xd8
    [ 2057.572839]  [<00000000912e9580>] sys_socketcall+0x228/0x348
    [ 2057.572841]  [<0000000091514e1a>] system_call+0x2a6/0x2c8
    [ 2057.572843] Last Breaking-Event-Address:
    [ 2057.572844]  [<0000000091317e44>] __napi_poll+0x4c/0x1d8
    [ 2057.572846]
    [ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt
    -------------------------------------------------------------------------------------------
    
    Analysis:
    There is one napi structure per out_q: card->qdio.out_qs[i].napi
    The napi.poll functions are set during qeth_open().
    
    Since
    commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)")
    qeth_set_offline()/qeth_set_online() no longer call dev_close()/
    dev_open(). So if qeth_free_qdio_queues() cleared
    card->qdio.out_qs[i].napi.poll while the network interface was UP and the
    card was offline, they are not set again.
    
    Reproduction:
    chzdev -e $devno layer2=0
    ip link set dev $network_interface up
    echo 0 > /sys/bus/ccwgroup/devices/0.0.$devno/online
    echo foo > /sys/bus/ccwgroup/devices/0.0.$devno/hsuid
    echo 1 > /sys/bus/ccwgroup/devices/0.0.$devno/online
    -> Crash (can be enforced e.g. by af_iucv connect(), ip link down/up, ...)
    
    Note that a Completion Queue (CQ) is only enabled or disabled, when hsuid
    is set for the first time or when it is removed.
    
    Workarounds:
    - Set hsuid before setting the device online for the first time
    or
    - Use chzdev -d $devno; chzdev $devno hsuid=xxx; chzdev -e $devno;
    to set hsuid on an existing device. (this will remove and recreate the
    network interface)
    
    Fix:
    There is no need to free the output queues when a completion queue is
    added or removed.
    card->qdio.state now indicates whether the inbound buffer pool and the
    outbound queues are allocated.
    card->qdio.c_q indicates whether a CQ is allocated.
    
    Fixes: 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)")
    Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240430091004.2265683-1-wintera@linux.ibm.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/vdso: Add CFI for RA register to asm macro vdso_func [+ + +]
Author: Jens Remus <jremus@linux.ibm.com>
Date:   Tue Apr 23 17:35:52 2024 +0200

    s390/vdso: Add CFI for RA register to asm macro vdso_func
    
    [ Upstream commit b961ec10b9f9719987470236feb50c967db5a652 ]
    
    The return-address (RA) register r14 is specified as volatile in the
    s390x ELF ABI [1]. Nevertheless proper CFI directives must be provided
    for an unwinder to restore the return address, if the RA register
    value is changed from its value at function entry, as it is the case.
    
    [1]: s390x ELF ABI, https://github.com/IBM/s390x-abi/releases
    
    Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO")
    Signed-off-by: Jens Remus <jremus@linux.ibm.com>
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload [+ + +]
Author: Saurav Kashyap <skashyap@marvell.com>
Date:   Fri Mar 15 12:44:27 2024 +0530

    scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
    
    [ Upstream commit c214ed2a4dda35b308b0b28eed804d7ae66401f9 ]
    
    The session resources are used by FW and driver when session is offloaded,
    once session is uploaded these resources are not used. The lock is not
    required as these fields won't be used any longer. The offload and upload
    calls are sequential, hence lock is not required.
    
    This will suppress following BUG_ON():
    
    [  449.843143] ------------[ cut here ]------------
    [  449.848302] kernel BUG at mm/vmalloc.c:2727!
    [  449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI
    [  449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1
    Rebooting.
    [  449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016
    [  449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]
    [  449.882910] RIP: 0010:vunmap+0x2e/0x30
    [  449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41
    [  449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206
    [  449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005
    [  449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000
    [  449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf
    [  449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000
    [  449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0
    [  449.953701] FS:  0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000
    [  449.962732] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0
    [  449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  449.993028] Call Trace:
    [  449.995756]  __iommu_dma_free+0x96/0x100
    [  450.000139]  bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]
    [  450.006171]  bnx2fc_upload_session+0xce/0x100 [bnx2fc]
    [  450.011910]  bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]
    [  450.018136]  fc_rport_work+0x103/0x5b0 [libfc]
    [  450.023103]  process_one_work+0x1e8/0x3c0
    [  450.027581]  worker_thread+0x50/0x3b0
    [  450.031669]  ? rescuer_thread+0x370/0x370
    [  450.036143]  kthread+0x149/0x170
    [  450.039744]  ? set_kthread_struct+0x40/0x40
    [  450.044411]  ret_from_fork+0x22/0x30
    [  450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls
    [  450.048497]  libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler
    [  450.159753] ---[ end trace 712de2c57c64abc8 ]---
    
    Reported-by: Guangwu Zhang <guazhang@redhat.com>
    Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Link: https://lore.kernel.org/r/20240315071427.31842-1-skashyap@marvell.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: Move NPIV's transport unregistration to after resource clean up [+ + +]
Author: Justin Tee <justin.tee@broadcom.com>
Date:   Tue Mar 5 12:04:53 2024 -0800

    scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
    
    [ Upstream commit 4ddf01f2f1504fa08b766e8cfeec558e9f8eef6c ]
    
    There are cases after NPIV deletion where the fabric switch still believes
    the NPIV is logged into the fabric.  This occurs when a vport is
    unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the
    fabric.
    
    Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including
    the fabric D_ID, removes the last ndlp reference and frees the ndlp rport
    object.  This sometimes causes the race condition where the final DA_ID and
    LOGO are skipped from being sent to the fabric switch.
    
    Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID
    and LOGO are sent.
    
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Link: https://lore.kernel.org/r/20240305200503.57317-3-justintee8345@gmail.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: Replace hbalock with ndlp lock in lpfc_nvme_unregister_port() [+ + +]
Author: Justin Tee <justin.tee@broadcom.com>
Date:   Tue Mar 5 12:04:56 2024 -0800

    scsi: lpfc: Replace hbalock with ndlp lock in lpfc_nvme_unregister_port()
    
    [ Upstream commit d11272be497e48a8e8f980470eb6b70e92eed0ce ]
    
    The ndlp object update in lpfc_nvme_unregister_port() should be protected
    by the ndlp lock rather than hbalock.
    
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Link: https://lore.kernel.org/r/20240305200503.57317-6-justintee8345@gmail.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: Update lpfc_ramp_down_queue_handler() logic [+ + +]
Author: Justin Tee <justin.tee@broadcom.com>
Date:   Tue Mar 5 12:04:55 2024 -0800

    scsi: lpfc: Update lpfc_ramp_down_queue_handler() logic
    
    [ Upstream commit bb011631435c705cdeddca68d5c85fd40a4320f9 ]
    
    Typically when an out of resource CQE status is detected, the
    lpfc_ramp_down_queue_handler() logic is called to help reduce I/O load by
    reducing an sdev's queue_depth.
    
    However, the current lpfc_rampdown_queue_depth() logic does not help reduce
    queue_depth.  num_cmd_success is never updated and is always zero, which
    means new_queue_depth will always be set to sdev->queue_depth.  So,
    new_queue_depth = sdev->queue_depth - new_queue_depth always sets
    new_queue_depth to zero.  And, scsi_change_queue_depth(sdev, 0) is
    essentially a no-op.
    
    Change the lpfc_ramp_down_queue_handler() logic to set new_queue_depth
    equal to sdev->queue_depth subtracted from number of times num_rsrc_err was
    incremented.  If num_rsrc_err is >= sdev->queue_depth, then set
    new_queue_depth equal to 1.  Eventually, the frequency of Good_Status
    frames will signal SCSI upper layer to auto increase the queue_depth back
    to the driver default of 64 via scsi_handle_queue_ramp_up().
    
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Link: https://lore.kernel.org/r/20240305200503.57317-5-justintee8345@gmail.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: target: Fix SELinux error when systemd-modules loads the target module [+ + +]
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Thu Feb 15 15:39:43 2024 +0100

    scsi: target: Fix SELinux error when systemd-modules loads the target module
    
    [ Upstream commit 97a54ef596c3fd24ec2b227ba8aaf2cf5415e779 ]
    
    If the systemd-modules service loads the target module, the credentials of
    that userspace process will be used to validate the access to the target db
    directory.  SELinux will prevent it, reporting an error like the following:
    
    kernel: audit: type=1400 audit(1676301082.205:4): avc: denied  { read }
    for  pid=1020 comm="systemd-modules" name="target" dev="dm-3"
    ino=4657583 scontext=system_u:system_r:systemd_modules_load_t:s0
    tcontext=system_u:object_r:targetd_etc_rw_t:s0 tclass=dir permissive=0
    
    Fix the error by using the kernel credentials to access the db directory
    
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Link: https://lore.kernel.org/r/20240215143944.847184-2-mlombard@redhat.com
    Reviewed-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: timers: Fix valid-adjtimex signed left-shift undefined behavior [+ + +]
Author: John Stultz <jstultz@google.com>
Date:   Tue Apr 9 13:22:12 2024 -0700

    selftests: timers: Fix valid-adjtimex signed left-shift undefined behavior
    
    [ Upstream commit 076361362122a6d8a4c45f172ced5576b2d4a50d ]
    
    The struct adjtimex freq field takes a signed value who's units are in
    shifted (<<16) parts-per-million.
    
    Unfortunately for negative adjustments, the straightforward use of:
    
      freq = ppm << 16 trips undefined behavior warnings with clang:
    
    valid-adjtimex.c:66:6: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
            -499<<16,
            ~~~~^
    valid-adjtimex.c:67:6: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
            -450<<16,
            ~~~~^
    ..
    
    Fix it by using a multiply by (1 << 16) instead of shifting negative values
    in the valid-adjtimex test case. Align the values for better readability.
    
    Reported-by: Lee Jones <joneslee@google.com>
    Reported-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Signed-off-by: John Stultz <jstultz@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Link: https://lore.kernel.org/r/20240409202222.2830476-1-jstultz@google.com
    Link: https://lore.kernel.org/lkml/0c6d4f0d-2064-4444-986b-1d1ed782135f@collabora.com/
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
slimbus: qcom-ngd-ctrl: Add timeout for wait operation [+ + +]
Author: Viken Dadhaniya <quic_vdadhani@quicinc.com>
Date:   Tue Apr 30 10:12:38 2024 +0100

    slimbus: qcom-ngd-ctrl: Add timeout for wait operation
    
    commit 98241a774db49988f25b7b3657026ce51ccec293 upstream.
    
    In current driver qcom_slim_ngd_up_worker() indefinitely
    waiting for ctrl->qmi_up completion object. This is
    resulting in workqueue lockup on Kthread.
    
    Added wait_for_completion_interruptible_timeout to
    allow the thread to wait for specific timeout period and
    bail out instead waiting infinitely.
    
    Fixes: a899d324863a ("slimbus: qcom-ngd-ctrl: add Sub System Restart support")
    Cc: stable@vger.kernel.org
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Viken Dadhaniya <quic_vdadhani@quicinc.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240430091238.35209-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
spi: hisi-kunpeng: Delete the dump interface of data registers in debugfs [+ + +]
Author: Devyn Liu <liudingyuan@huawei.com>
Date:   Tue Apr 16 09:58:39 2024 +0800

    spi: hisi-kunpeng: Delete the dump interface of data registers in debugfs
    
    [ Upstream commit 7430764f5a85d30314aeef2d5438dff1fb0b1d68 ]
    
    Due to the reading of FIFO during the dump of data registers in
    debugfs, if SPI transmission is in progress, it will be affected
    and may result in transmission failure. Therefore, the dump
    interface of data registers in debugfs is removed.
    
    Fixes: 2b2142f247eb ("spi: hisi-kunpeng: Add debugfs support")
    Signed-off-by: Devyn Liu <liudingyuan@huawei.com>
    Reviewed-by: Jay Fang <f.fangjian@huawei.com>
    Link: https://lore.kernel.org/r/20240416015839.3323398-1-liudingyuan@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sunrpc: add a struct rpc_stats arg to rpc_create_args [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Thu Feb 15 14:57:30 2024 -0500

    sunrpc: add a struct rpc_stats arg to rpc_create_args
    
    [ Upstream commit 2057a48d0dd00c6a2a94ded7df2bf1d3f2a4a0da ]
    
    We want to be able to have our rpc stats handled in a per network
    namespace manner, so add an option to rpc_create_args to specify a
    different rpc_stats struct instead of using the one on the rpc_program.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Stable-dep-of: 24457f1be29f ("nfs: Handle error of rpc_proc_register() in nfs_net_init().")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed May 1 12:54:48 2024 +0000

    tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
    
    [ Upstream commit 94062790aedb505bdda209b10bea47b294d6394f ]
    
    TCP_SYN_RECV state is really special, it is only used by
    cross-syn connections, mostly used by fuzzers.
    
    In the following crash [1], syzbot managed to trigger a divide
    by zero in tcp_rcv_space_adjust()
    
    A socket makes the following state transitions,
    without ever calling tcp_init_transfer(),
    meaning tcp_init_buffer_space() is also not called.
    
             TCP_CLOSE
    connect()
             TCP_SYN_SENT
             TCP_SYN_RECV
    shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN)
             TCP_FIN_WAIT1
    
    To fix this issue, change tcp_shutdown() to not
    perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition,
    which makes no sense anyway.
    
    When tcp_rcv_state_process() later changes socket state
    from TCP_SYN_RECV to TCP_ESTABLISH, then look at
    sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state,
    and send a FIN packet from a sane socket state.
    
    This means tcp_send_fin() can now be called from BH
    context, and must use GFP_ATOMIC allocations.
    
    [1]
    divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
    CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
     RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767
    Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48
    RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246
    RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7
    R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30
    R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da
    FS:  00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0
    Call Trace:
     <TASK>
      tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513
      tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578
      inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680
      sock_recvmsg_nosec net/socket.c:1046 [inline]
      sock_recvmsg+0x109/0x280 net/socket.c:1068
      ____sys_recvmsg+0x1db/0x470 net/socket.c:2803
      ___sys_recvmsg net/socket.c:2845 [inline]
      do_recvmmsg+0x474/0xae0 net/socket.c:2939
      __sys_recvmmsg net/socket.c:3018 [inline]
      __do_sys_recvmmsg net/socket.c:3041 [inline]
      __se_sys_recvmmsg net/socket.c:3034 [inline]
      __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034
      do_syscall_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
    RIP: 0033:0x7faeb6363db9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9
    RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005
    RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c
    R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000
    R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Link: https://lore.kernel.org/r/20240501125448.896529-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: Use refcount_inc_not_zero() in tcp_twsk_unique(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Wed May 1 14:31:45 2024 -0700

    tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().
    
    [ Upstream commit f2db7230f73a80dbb179deab78f88a7947f0ab7e ]
    
    Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique()
    with nice analysis.
    
    Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for
    timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's
    sk_refcnt after putting it into ehash and releasing the bucket lock.
    
    Thus, there is a small race window where other threads could try to
    reuse the port during connect() and call sock_hold() in tcp_twsk_unique()
    for the TIME-WAIT socket with zero refcnt.
    
    If that happens, the refcnt taken by tcp_twsk_unique() is overwritten
    and sock_put() will cause underflow, triggering a real use-after-free
    somewhere else.
    
    To avoid the use-after-free, we need to use refcount_inc_not_zero() in
    tcp_twsk_unique() and give up on reusing the port if it returns false.
    
    [0]:
    refcount_t: addition on 0; use-after-free.
    WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
    CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1
    Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023
    RIP: 0010:refcount_warn_saturate+0xe5/0x110
    Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8
    RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027
    RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0
    RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0
    R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84
    R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0
    FS:  00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? refcount_warn_saturate+0xe5/0x110
     ? __warn+0x81/0x130
     ? refcount_warn_saturate+0xe5/0x110
     ? report_bug+0x171/0x1a0
     ? refcount_warn_saturate+0xe5/0x110
     ? handle_bug+0x3c/0x80
     ? exc_invalid_op+0x17/0x70
     ? asm_exc_invalid_op+0x1a/0x20
     ? refcount_warn_saturate+0xe5/0x110
     tcp_twsk_unique+0x186/0x190
     __inet_check_established+0x176/0x2d0
     __inet_hash_connect+0x74/0x7d0
     ? __pfx___inet_check_established+0x10/0x10
     tcp_v4_connect+0x278/0x530
     __inet_stream_connect+0x10f/0x3d0
     inet_stream_connect+0x3a/0x60
     __sys_connect+0xa8/0xd0
     __x64_sys_connect+0x18/0x20
     do_syscall_64+0x83/0x170
     entry_SYSCALL_64_after_hwframe+0x78/0x80
    RIP: 0033:0x7f62c11a885d
    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 a3 45 0c 00 f7 d8 64 89 01 48
    RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a
    RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d
    RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003
    RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0
    R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0
     </TASK>
    
    Fixes: ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance")
    Reported-by: Anderson Nascimento <anderson@allelesecurity.com>
    Closes: https://lore.kernel.org/netdev/37a477a6-d39e-486b-9577-3463f655a6b7@allelesecurity.com/
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240501213145.62261-1-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tipc: fix a possible memleak in tipc_buf_append [+ + +]
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Apr 30 10:03:38 2024 -0400

    tipc: fix a possible memleak in tipc_buf_append
    
    [ Upstream commit 97bf6f81b29a8efaf5d0983251a7450e5794370d ]
    
    __skb_linearize() doesn't free the skb when it fails, so move
    '*buf = NULL' after __skb_linearize(), so that the skb can be
    freed on the err path.
    
    Fixes: b7df21cf1b79 ("tipc: skb_linearize the head skb when reassembling msgs")
    Reported-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
    Link: https://lore.kernel.org/r/90710748c29a1521efac4f75ea01b3b7e61414cf.1714485818.git.lucien.xin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tipc: fix UAF in error path [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Apr 30 15:53:37 2024 +0200

    tipc: fix UAF in error path
    
    commit 080cbb890286cd794f1ee788bbc5463e2deb7c2b upstream.
    
    Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported
    a UAF in the tipc_buf_append() error path:
    
    BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0
    linux/net/core/skbuff.c:1183
    Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
    
    CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    1.16.0-debian-1.16.0-5 04/01/2014
    Call Trace:
     <IRQ>
     __dump_stack linux/lib/dump_stack.c:88
     dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106
     print_address_description linux/mm/kasan/report.c:377
     print_report+0xc4/0x620 linux/mm/kasan/report.c:488
     kasan_report+0xda/0x110 linux/mm/kasan/report.c:601
     kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183
     skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026
     skb_release_all linux/net/core/skbuff.c:1094
     __kfree_skb linux/net/core/skbuff.c:1108
     kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144
     kfree_skb linux/./include/linux/skbuff.h:1244
     tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186
     tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324
     tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824
     tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159
     tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390
     udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108
     udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186
     udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346
     __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422
     ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205
     ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233
     NF_HOOK linux/./include/linux/netfilter.h:314
     NF_HOOK linux/./include/linux/netfilter.h:308
     ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254
     dst_input linux/./include/net/dst.h:461
     ip_rcv_finish linux/net/ipv4/ip_input.c:449
     NF_HOOK linux/./include/linux/netfilter.h:314
     NF_HOOK linux/./include/linux/netfilter.h:308
     ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569
     __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534
     __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648
     process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976
     __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576
     napi_poll linux/net/core/dev.c:6645
     net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781
     __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553
     do_softirq linux/kernel/softirq.c:454
     do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441
     </IRQ>
     <TASK>
     __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381
     local_bh_enable linux/./include/linux/bottom_half.h:33
     rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851
     __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378
     dev_queue_xmit linux/./include/linux/netdevice.h:3169
     neigh_hh_output linux/./include/net/neighbour.h:526
     neigh_output linux/./include/net/neighbour.h:540
     ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235
     __ip_finish_output linux/net/ipv4/ip_output.c:313
     __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295
     ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323
     NF_HOOK_COND linux/./include/linux/netfilter.h:303
     ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433
     dst_output linux/./include/net/dst.h:451
     ip_local_out linux/net/ipv4/ip_output.c:129
     ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492
     udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963
     udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250
     inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850
     sock_sendmsg_nosec linux/net/socket.c:730
     __sock_sendmsg linux/net/socket.c:745
     __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191
     __do_sys_sendto linux/net/socket.c:2203
     __se_sys_sendto linux/net/socket.c:2199
     __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199
     do_syscall_x64 linux/arch/x86/entry/common.c:52
     do_syscall_64+0xd8/0x270 linux/arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x6f/0x77 linux/arch/x86/entry/entry_64.S:120
    RIP: 0033:0x7f3434974f29
    Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 37 8f 0d 00 f7 d8 64 89 01 48
    RSP: 002b:00007fff9154f2b8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3434974f29
    RDX: 00000000000032c8 RSI: 00007fff9154f300 RDI: 0000000000000003
    RBP: 00007fff915532e0 R08: 00007fff91553360 R09: 0000000000000010
    R10: 0000000000000000 R11: 0000000000000212 R12: 000055ed86d261d0
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
     </TASK>
    
    In the critical scenario, either the relevant skb is freed or its
    ownership is transferred into a frag_lists. In both cases, the cleanup
    code must not free it again: we need to clear the skb reference earlier.
    
    Fixes: 1149557d64c9 ("tipc: eliminate unnecessary linearization of incoming buffers")
    Cc: stable@vger.kernel.org
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-23852
    Acked-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/752f1ccf762223d109845365d07f55414058e5a3.1714484273.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tools/power turbostat: Fix added raw MSR output [+ + +]
Author: Doug Smythies <dsmythies@telus.net>
Date:   Mon Apr 3 14:11:38 2023 -0700

    tools/power turbostat: Fix added raw MSR output
    
    [ Upstream commit e5f4e68eed85fa8495d78cd966eecc2b27bb9e53 ]
    
    When using --Summary mode, added MSRs in raw mode always
    print zeros. Print the actual register contents.
    
    Example, with patch:
    
    note the added column:
    --add msr0x64f,u32,package,raw,REASON
    
    Where:
    
    0x64F is MSR_CORE_PERF_LIMIT_REASONS
    
    Busy%   Bzy_MHz PkgTmp  PkgWatt CorWatt     REASON
    0.00    4800    35      1.42    0.76    0x00000000
    0.00    4801    34      1.42    0.76    0x00000000
    80.08   4531    66      108.17  107.52  0x08000000
    98.69   4530    66      133.21  132.54  0x08000000
    99.28   4505    66      128.26  127.60  0x0c000400
    99.65   4486    68      124.91  124.25  0x0c000400
    99.63   4483    68      124.90  124.25  0x0c000400
    79.34   4481    41      99.80   99.13   0x0c000000
    0.00    4801    41      1.40    0.73    0x0c000000
    
    Where, for the test processor (i5-10600K):
    
    PKG Limit #1: 125.000 Watts, 8.000000 sec
    MSR bit 26 = log; bit 10 = status
    
    PKG Limit #2: 136.000 Watts, 0.002441 sec
    MSR bit 27 = log; bit 11 = status
    
    Example, without patch:
    
    Busy%   Bzy_MHz PkgTmp  PkgWatt CorWatt     REASON
    0.01    4800    35      1.43    0.77    0x00000000
    0.00    4801    35      1.39    0.73    0x00000000
    83.49   4531    66      112.71  112.06  0x00000000
    98.69   4530    68      133.35  132.69  0x00000000
    99.31   4500    67      127.96  127.30  0x00000000
    99.63   4483    69      124.91  124.25  0x00000000
    99.61   4481    69      124.90  124.25  0x00000000
    99.61   4481    71      124.92  124.25  0x00000000
    59.35   4479    42      75.03   74.37   0x00000000
    0.00    4800    42      1.39    0.73    0x00000000
    0.00    4801    42      1.42    0.76    0x00000000
    
    c000000
    
    [lenb: simplified patch to apply only to package scope]
    
    Signed-off-by: Doug Smythies <dsmythies@telus.net>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tools/power turbostat: Fix Bzy_MHz documentation typo [+ + +]
Author: Peng Liu <liupeng17@lenovo.com>
Date:   Sat Oct 7 13:46:22 2023 +0800

    tools/power turbostat: Fix Bzy_MHz documentation typo
    
    [ Upstream commit 0b13410b52c4636aacb6964a4253a797c0fa0d16 ]
    
    The code calculates Bzy_MHz by multiplying TSC_delta * APERF_delta/MPERF_delta
    The man page erroneously showed that TSC_delta was divided.
    
    Signed-off-by: Peng Liu <liupeng17@lenovo.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: dwc3: core: Prevent phy suspend during init [+ + +]
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Wed Apr 17 23:14:36 2024 +0000

    usb: dwc3: core: Prevent phy suspend during init
    
    commit 6d735722063a945de56472bdc6bfcb170fd43b86 upstream.
    
    GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared
    during initialization. Suspend during initialization can result in
    undefined behavior due to clock synchronization failure, which often
    seen as core soft reset timeout.
    
    The programming guide recommended these bits to be cleared during
    initialization for DWC_usb3.0 version 1.94 and above (along with
    DWC_usb31 and DWC_usb32). The current check in the driver does not
    account if it's set by default setting from coreConsultant.
    
    This is especially the case for DRD when switching mode to ensure the
    phy clocks are available to change mode. Depending on the
    platforms/design, some may be affected more than others. This is noted
    in the DWC_usb3x programming guide under the above registers.
    
    Let's just disable them during driver load and mode switching. Restore
    them when the controller initialization completes.
    
    Note that some platforms workaround this issue by disabling phy suspend
    through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when
    they should not need to.
    
    Cc: stable@vger.kernel.org
    Fixes: 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset")
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20da4e5a0c4678c9587d3da23f83bdd6d77353e9.1713394973.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: Fix regression caused by invalid ep0 maxpacket in virtual SuperSpeed device [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Apr 30 10:33:48 2024 -0400

    usb: Fix regression caused by invalid ep0 maxpacket in virtual SuperSpeed device
    
    commit c78c3644b772e356ca452ae733a3c4de0fb11dc8 upstream.
    
    A virtual SuperSpeed device in the FreeBSD BVCP package
    (https://bhyve.npulse.net/) presents an invalid ep0 maxpacket size of 256.
    It stopped working with Linux following a recent commit because now we
    check these sizes more carefully than before.
    
    Fix this regression by using the bMaxpacketSize0 value in the device
    descriptor for SuperSpeed or faster devices, even if it is invalid.  This
    is a very simple-minded change; we might want to check more carefully for
    values that actually make some sense (for instance, no smaller than 64).
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: Roger Whittaker <roger.whittaker@suse.com>
    Closes: https://bugzilla.suse.com/show_bug.cgi?id=1220569
    Link: https://lore.kernel.org/linux-usb/9efbd569-7059-4575-983f-0ea30df41871@suse.com/
    Fixes: 59cf44575456 ("USB: core: Fix oversight in SuperSpeed initialization")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/4058ac05-237c-4db4-9ecc-5af42bdb4501@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: composite: fix OS descriptors w_value logic [+ + +]
Author: Peter Korsgaard <peter@korsgaard.com>
Date:   Thu Apr 4 12:06:35 2024 +0200

    usb: gadget: composite: fix OS descriptors w_value logic
    
    commit ec6ce7075ef879b91a8710829016005dc8170f17 upstream.
    
    The OS descriptors logic had the high/low byte of w_value inverted, causing
    the extended properties to not be accessible for interface != 0.
    
    >From the Microsoft documentation:
    https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-os-1-0-descriptors-specification
    
    OS_Desc_CompatID.doc (w_index = 0x4):
    
    - wValue:
    
      High Byte = InterfaceNumber.  InterfaceNumber is set to the number of the
      interface or function that is associated with the descriptor, typically
      0x00.  Because a device can have only one extended compat ID descriptor,
      it should ignore InterfaceNumber, regardless of the value, and simply
      return the descriptor.
    
      Low Byte = 0.  PageNumber is used to retrieve descriptors that are larger
      than 64 KB.  The header section is 16 bytes, so PageNumber is set to 0 for
      this request.
    
    We currently do not support >64KB compat ID descriptors, so verify that the
    low byte is 0.
    
    OS_Desc_Ext_Prop.doc (w_index = 0x5):
    
    - wValue:
    
      High byte = InterfaceNumber.  The high byte of wValue is set to the number
      of the interface or function that is associated with the descriptor.
    
      Low byte = PageNumber.  The low byte of wValue is used to retrieve
      descriptors that are larger than 64 KB.  The header section is 10 bytes, so
      PageNumber is set to 0 for this request.
    
    We also don't support >64KB extended properties, so verify that the low byte
    is 0 and use the high byte for the interface number.
    
    Fixes: 37a3a533429e ("usb: gadget: OS Feature Descriptors support")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
    Link: https://lore.kernel.org/r/20240404100635.3215340-1-peter@korsgaard.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: f_fs: Fix a race condition when processing setup packets. [+ + +]
Author: Chris Wulff <Chris.Wulff@biamp.com>
Date:   Tue Apr 23 18:02:15 2024 +0000

    usb: gadget: f_fs: Fix a race condition when processing setup packets.
    
    commit 0aea736ddb877b93f6d2dd8cf439840d6b4970a9 upstream.
    
    If the USB driver passes a pointer into the TRB buffer for creq, this
    buffer can be overwritten with the status response as soon as the event
    is queued. This can make the final check return USB_GADGET_DELAYED_STATUS
    when it shouldn't. Instead use the stored wLength.
    
    Fixes: 4d644abf2569 ("usb: gadget: f_fs: Only return delayed status when len is 0")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Chris Wulff <chris.wulff@biamp.com>
    Link: https://lore.kernel.org/r/CO1PR17MB5419BD664264A558B2395E28E1112@CO1PR17MB5419.namprd17.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: ohci: Prevent missed ohci interrupts [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Mon Apr 29 08:40:10 2024 -0700

    usb: ohci: Prevent missed ohci interrupts
    
    commit fe81f354841641c7f71163b84912b25c169ed8ec upstream.
    
    Testing ohci functionality with qemu's pci-ohci emulation often results
    in ohci interface stalls, resulting in hung task timeouts.
    
    The problem is caused by lost interrupts between the emulation and the
    Linux kernel code. Additional interrupts raised while the ohci interrupt
    handler in Linux is running and before the handler clears the interrupt
    status are not handled. The fix for a similar problem in ehci suggests
    that the problem is likely caused by edge-triggered MSI interrupts. See
    commit 0b60557230ad ("usb: ehci: Prevent missed ehci interrupts with
    edge-triggered MSI") for details.
    
    Ensure that the ohci interrupt code handles all pending interrupts before
    returning to solve the problem.
    
    Cc: Gerd Hoffmann <kraxel@redhat.com>
    Cc: David Laight <David.Laight@aculab.com>
    Cc: stable@vger.kernel.org
    Fixes: 306c54d0edb6 ("usb: hcd: Try MSI interrupts on PCI devices")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
    Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
    Link: https://lore.kernel.org/r/20240429154010.1507366-1-linux@roeck-us.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: ucsi: Check for notifications after init [+ + +]
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Wed Mar 20 08:39:23 2024 +0100

    usb: typec: ucsi: Check for notifications after init
    
    commit 808a8b9e0b87bbc72bcc1f7ddfe5d04746e7ce56 upstream.
    
    The completion notification for the final SET_NOTIFICATION_ENABLE
    command during initialization can include a connector change
    notification.  However, at the time this completion notification is
    processed, the ucsi struct is not ready to handle this notification.
    As a result the notification is ignored and the controller
    never sends an interrupt again.
    
    Re-check CCI for a pending connector state change after
    initialization is complete. Adjust the corresponding debug
    message accordingly.
    
    Fixes: 71a1fa0df2a3 ("usb: typec: ucsi: Store the notification mask")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
    Link: https://lore.kernel.org/r/20240320073927.1641788-3-lk@c--e.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: ucsi: Fix connector check on init [+ + +]
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Mon Apr 1 23:05:15 2024 +0200

    usb: typec: ucsi: Fix connector check on init
    
    commit ce4c8d21054ae9396cd759fe6e8157b525616dc4 upstream.
    
    Fix issues when initially checking for a connector change:
    - Use the correct connector number not the entire CCI.
    - Call ->read under the PPM lock.
    - Remove a bogus READ_ONCE.
    
    Fixes: 808a8b9e0b87 ("usb: typec: ucsi: Check for notifications after init")
    Cc: stable@kernel.org
    Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240401210515.1902048-1-lk@c--e.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: xhci-plat: Don't include xhci.h [+ + +]
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Wed Apr 17 23:14:30 2024 +0000

    usb: xhci-plat: Don't include xhci.h
    
    commit 4a237d55446ff67655dc3eed2d4a41997536fc4c upstream.
    
    The xhci_plat.h should not need to include the entire xhci.h header.
    This can cause redefinition in dwc3 if it selectively includes some xHCI
    definitions. This is a prerequisite change for a fix to disable suspend
    during initialization for dwc3.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/310acfa01c957a10d9feaca3f7206269866ba2eb.1713394973.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: cfg80211: fix rdev_dump_mpp() arguments order [+ + +]
Author: Igor Artemiev <Igor.A.Artemiev@mcst.ru>
Date:   Mon Mar 11 19:45:19 2024 +0300

    wifi: cfg80211: fix rdev_dump_mpp() arguments order
    
    [ Upstream commit ec50f3114e55406a1aad24b7dfaa1c3f4336d8eb ]
    
    Fix the order of arguments in the TP_ARGS macro
    for the rdev_dump_mpp tracepoint event.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Signed-off-by: Igor Artemiev <Igor.A.Artemiev@mcst.ru>
    Link: https://msgid.link/20240311164519.118398-1-Igor.A.Artemiev@mcst.ru
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: fix ieee80211_bss_*_flags kernel-doc [+ + +]
Author: Jeff Johnson <quic_jjohnson@quicinc.com>
Date:   Thu Mar 14 14:23:00 2024 -0700

    wifi: mac80211: fix ieee80211_bss_*_flags kernel-doc
    
    [ Upstream commit 774f8841f55d7ac4044c79812691649da203584a ]
    
    Running kernel-doc on ieee80211_i.h flagged the following:
    net/mac80211/ieee80211_i.h:145: warning: expecting prototype for enum ieee80211_corrupt_data_flags. Prototype was for enum ieee80211_bss_corrupt_data_flags instead
    net/mac80211/ieee80211_i.h:162: warning: expecting prototype for enum ieee80211_valid_data_flags. Prototype was for enum ieee80211_bss_valid_data_flags instead
    
    Fix these warnings.
    
    Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://msgid.link/20240314-kdoc-ieee80211_i-v1-1-72b91b55b257@quicinc.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: nl80211: don't free NULL coalescing rule [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Apr 18 10:52:23 2024 +0200

    wifi: nl80211: don't free NULL coalescing rule
    
    [ Upstream commit 801ea33ae82d6a9d954074fbcf8ea9d18f1543a7 ]
    
    If the parsing fails, we can dereference a NULL pointer here.
    
    Cc: stable@vger.kernel.org
    Fixes: be29b99a9b51 ("cfg80211/nl80211: Add packet coalesce support")
    Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240418105220.b328f80406e7.Id75d961050deb05b3e4e354e024866f350c68103@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xdp: Add xdp_do_redirect_frame() for pre-computed xdp_frames [+ + +]
Author: Toke H├Şiland-J├Şrgensen <toke@redhat.com>
Date:   Mon Jan 3 16:08:10 2022 +0100

    xdp: Add xdp_do_redirect_frame() for pre-computed xdp_frames
    
    [ Upstream commit 1372d34ccf6dd480332b2bcb2fd59a2b9a0df415 ]
    
    Add an xdp_do_redirect_frame() variant which supports pre-computed
    xdp_frame structures. This will be used in bpf_prog_run() to avoid having
    to write to the xdp_frame structure when the XDP program doesn't modify the
    frame boundaries.
    
    Signed-off-by: Toke H├Şiland-J├Şrgensen <toke@redhat.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20220103150812.87914-6-toke@redhat.com
    Stable-dep-of: 5bcf0dcbf906 ("xdp: use flags field to disambiguate broadcast redirect")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xdp: Move conversion to xdp_frame out of map functions [+ + +]
Author: Toke H├Şiland-J├Şrgensen <toke@redhat.com>
Date:   Mon Jan 3 16:08:09 2022 +0100

    xdp: Move conversion to xdp_frame out of map functions
    
    [ Upstream commit d53ad5d8b218a885e95080d4d3d556b16b91b1b9 ]
    
    All map redirect functions except XSK maps convert xdp_buff to xdp_frame
    before enqueueing it. So move this conversion of out the map functions
    and into xdp_do_redirect(). This removes a bit of duplicated code, but more
    importantly it makes it possible to support caller-allocated xdp_frame
    structures, which will be added in a subsequent commit.
    
    Signed-off-by: Toke H├Şiland-J├Şrgensen <toke@redhat.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20220103150812.87914-5-toke@redhat.com
    Stable-dep-of: 5bcf0dcbf906 ("xdp: use flags field to disambiguate broadcast redirect")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xdp: use flags field to disambiguate broadcast redirect [+ + +]
Author: Toke H├Şiland-J├Şrgensen <toke@redhat.com>
Date:   Thu Apr 18 09:18:39 2024 +0200

    xdp: use flags field to disambiguate broadcast redirect
    
    [ Upstream commit 5bcf0dcbf9066348058b88a510c57f70f384c92c ]
    
    When redirecting a packet using XDP, the bpf_redirect_map() helper will set
    up the redirect destination information in struct bpf_redirect_info (using
    the __bpf_xdp_redirect_map() helper function), and the xdp_do_redirect()
    function will read this information after the XDP program returns and pass
    the frame on to the right redirect destination.
    
    When using the BPF_F_BROADCAST flag to do multicast redirect to a whole
    map, __bpf_xdp_redirect_map() sets the 'map' pointer in struct
    bpf_redirect_info to point to the destination map to be broadcast. And
    xdp_do_redirect() reacts to the value of this map pointer to decide whether
    it's dealing with a broadcast or a single-value redirect. However, if the
    destination map is being destroyed before xdp_do_redirect() is called, the
    map pointer will be cleared out (by bpf_clear_redirect_map()) without
    waiting for any XDP programs to stop running. This causes xdp_do_redirect()
    to think that the redirect was to a single target, but the target pointer
    is also NULL (since broadcast redirects don't have a single target), so
    this causes a crash when a NULL pointer is passed to dev_map_enqueue().
    
    To fix this, change xdp_do_redirect() to react directly to the presence of
    the BPF_F_BROADCAST flag in the 'flags' value in struct bpf_redirect_info
    to disambiguate between a single-target and a broadcast redirect. And only
    read the 'map' pointer if the broadcast flag is set, aborting if that has
    been cleared out in the meantime. This prevents the crash, while keeping
    the atomic (cmpxchg-based) clearing of the map pointer itself, and without
    adding any more checks in the non-broadcast fast path.
    
    Fixes: e624d4ed4aa8 ("xdp: Extend xdp_redirect_map with broadcast support")
    Reported-and-tested-by: syzbot+af9492708df9797198d6@syzkaller.appspotmail.com
    Signed-off-by: Toke H├Şiland-J├Şrgensen <toke@redhat.com>
    Acked-by: Stanislav Fomichev <sdf@google.com>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>
    Link: https://lore.kernel.org/r/20240418071840.156411-1-toke@redhat.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xfrm: Preserve vlan tags for transport mode software GRO [+ + +]
Author: Paul Davey <paul.davey@alliedtelesis.co.nz>
Date:   Tue Apr 23 18:00:24 2024 +1200

    xfrm: Preserve vlan tags for transport mode software GRO
    
    [ Upstream commit 58fbfecab965014b6e3cc956a76b4a96265a1add ]
    
    The software GRO path for esp transport mode uses skb_mac_header_rebuild
    prior to re-injecting the packet via the xfrm_napi_dev.  This only
    copies skb->mac_len bytes of header which may not be sufficient if the
    packet contains 802.1Q tags or other VLAN tags.  Worse copying only the
    initial header will leave a packet marked as being VLAN tagged but
    without the corresponding tag leading to mangling when it is later
    untagged.
    
    The VLAN tags are important when receiving the decrypted esp transport
    mode packet after GRO processing to ensure it is received on the correct
    interface.
    
    Therefore record the full mac header length in xfrm*_transport_input for
    later use in corresponding xfrm*_transport_finish to copy the entire mac
    header when rebuilding the mac header for GRO.  The skb->data pointer is
    left pointing skb->mac_header bytes after the start of the mac header as
    is expected by the network stack and network and transport header
    offsets reset to this location.
    
    Fixes: 7785bba299a8 ("esp: Add a software GRO codepath")
    Signed-off-by: Paul Davey <paul.davey@alliedtelesis.co.nz>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>