Commit graph

1,485,420 commits

Author SHA1 Message Date
Karl Mehltretter
2725ab3f5a keys: fix lost wakeup when reaping a dead key type
clear_bit() is atomic with respect to the word it modifies, but it is
an unordered operation: it implies no memory barrier on either side
(Documentation/atomic_bitops.txt).

key_garbage_collector() clears KEY_GC_REAPING_KEYTYPE with clear_bit()
and calls wake_up_bit() after reaping a dead key type. wake_up_bit()
uses a lockless waitqueue check and requires a full barrier after the
clear.

The existing smp_mb() is before clear_bit(), so nothing orders the clear
against that check. The GC can see an empty waitqueue while
unregister_key_type() still sees the bit set. The final wakeup is then
lost, leaving module unload stuck in wait_on_bit().

Use clear_and_wake_up_bit(). Its clear_bit_unlock() has RELEASE
semantics, so the completed GC work stays ordered before the clear, and
its smp_mb__after_atomic() orders the clear before the waitqueue check.

Fixes: 0c061b5707 ("KEYS: Correctly destroy key payloads when their keytype is removed")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://lore.kernel.org/r/20260821025327.61488-1-kmehltretter@gmail.com
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2026-09-12 00:43:45 +03:00
Mikhail Gavrilov
77be3641f3 debugfs: don't warn about uninitialized debugfs for an error parent
Since commit c3a280ff72
("debugfs: warn if file creation failed due to uninitialized debugfs")
every boot with CONFIG_REF_TRACKER=y and CONFIG_DEBUG_FS=y prints two
errors before the root filesystem is mounted:

  debugfs: Unable to create file 'net_refcnt@(____ptrval____)',
    debugfs is not initialized yet
  debugfs: Unable to create file 'net_notrefcnt@(____ptrval____)',
    debugfs is not initialized yet

Nothing is actually wrong.  Both files show up under
/sys/kernel/debug/ref_tracker/ once the system is up.  The kernel is
reporting an error for a condition the caller has already accounted for.

net_ns_init() runs directly from start_kernel(), before any initcall, and
calls ref_tracker_dir_init() for init_net's two trackers.  debugfs_init()
is a core_initcall, so debugfs cannot possibly be up at that point.  That
is by design: ref_tracker_dir_debugfs() is documented as safe to call
again later, and net/core/net_namespace.c has a late_initcall() that
re-registers both directories once debugfs exists.

ref_tracker also states that intent to debugfs.  ref_tracker_debug_dir is
initialised to ERR_PTR(-ENOENT) and only gets a real dentry in a
late_initcall, so the early call hands debugfs_create_file() a parent that
is already an error.  debugfs_start_creating() honours that and returns
the parent error, but only after the new pr_err() has fired.

Move the IS_ERR(parent) check above the debugfs_initialized() test.  A
caller passing an error parent is propagating an earlier failure, which is
the pattern debugfs documents and which the warning is not aimed at.  A
caller passing a valid or NULL parent too early - the case the warning was
added for - still gets it.

One behaviour change: an early caller with an error parent now gets
PTR_ERR(parent) back instead of -ENOENT.  All callers of these interfaces
are documented to ignore the return value.

Fixes: c3a280ff72 ("debugfs: warn if file creation failed due to uninitialized debugfs")
Link: https://lore.kernel.org/all/6d1dc775f7d5e754d734907514534054f682bac5.1781171918.git.yk@y-koj.net/
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Tested-by: Yohei Kojima <yk@y-koj.net>
Link: https://patch.msgid.link/20260903115135.63210-1-mikhail.v.gavrilov@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-11 23:13:07 +02:00
Linus Torvalds
525f0f99a4 drm fixes for 7.3-rc3
drm_exec:
 - fix 0 object handling
 
 sched:
 - null ptr deref fix in kunit tests
 
 amdgpu:
 - Freesync fix
 - GPUVM fix
 - Debugfs fixes
 - HDMI fixes
 - IPS fix
 - GPU reset fix
 - RGB quantization fixes
 - SMU 13.0.x fixes
 
 xe:
 - runtime PM guard fix
 - cache flushing fix
 
 i915:
 - Fix a memleak on perf config query error path
 - Fix UHBR SST SDP splitting when sink doesn't support it
 
 bridge:
 - fix ti-sn65dsi83 error handling
 - tc358768: Enforce input bus flags via atomic_check
 
 ast:
 - fix blend mode property on cursor plane
 
 qxl:
 - fix blend mode property on primary/cursor planes
 
 virtio:
 - fix blend mode property on cursor plane
 
 vboxvideo:
 - fix blend mode property on planes
 
 rockchip:
 - fix endpoint name length
 - fix Kconfig issues
 
 ivpu:
 - limit firmware log prints to field size
 - validate buffer range in ivpu address translation
 - validate fw log buffers
 
 ethosu:
 - ensure SRAM sizing
 - ensure cmd stream formatting
 - drop IRQF_SHARED
 - fix open return value
 
 adp:
 - fix Kconfig
 
 logicvc:
 - fix Kconfig
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmqkZ3gACgkQDHTzWXnE
 hr73LQ//YciKV7q62r31apitbxB/pffXWbQsKZU3FtBBUwyPvuO0R1iyQiaxN71O
 DqVqSBpnRf2SjAyyF0YAon1hmOcbkiDli1oZ3X8I20C1llGcTCzT8mYjnFejFBoX
 ScqBO3iwdKEI6vrSBy9SJjnL6h2OBhPaE8EH3tZVko5OalpLwnUyLP4UffX25sIF
 2kN904rA5yaBSdnMGry2I819m85K9I+kx321u08LaUlXUzJa28uPWm2rPsSSWRj5
 HB83FIIYe5z2DH2GyBQJa6XP/oP3ysbra68wfB34mHrfjgGxQVgoe1oY1ERcqlo1
 V4a/N0lJCvjEPAfTQ+jO28wj1H4my7YPDekv+iA9mBETM0sUKTb63KTt95L44Ap+
 I6OyommsHZAcMDWvvRW5Q1DlQ5DRCYUSUhvSan6WzxtFueobwhl+SpJ3EHLevDIy
 xmlnoG6qV5YHYiw9CG+95+Y69N8kj9FffNvAdE/Db/5JyMTlhC2sagLAAJC4z54X
 BlGS96yRzJm9spmGctzCTMFCfgDDR7TqSSi6pPMazFB4vLpmkfr7xZ7C54Gerrjp
 Q4lWW/MoS+wSpzZuGa7EZq8e65dTRdDo5TgpOMI6qS8uYfaidNsU9lG6x8/xRDKD
 elniWmhe2b49RwoAUXQz7IIDFR3gzbo8MxI1ikCtyOfE7fIKCBI=
 =WQ9l
 -----END PGP SIGNATURE-----

Merge tag 'drm-fixes-2026-09-12' of https://gitlab.freedesktop.org/drm/kernel

Pull drm fixes from Dave Airlie:
 "Weekly fixes pull, this seems relatively quiet for the new world,
  scattered fixes, mostly amdgpu leading the way, but lots of minor
  fixes in other drivers.

  drm_exec:
   - fix 0 object handling

  sched:
   - null ptr deref fix in kunit tests

  amdgpu:
   - Freesync fix
   - GPUVM fix
   - Debugfs fixes
   - HDMI fixes
   - IPS fix
   - GPU reset fix
   - RGB quantization fixes
   - SMU 13.0.x fixes

  xe:
   - runtime PM guard fix
   - cache flushing fix

  i915:
   - Fix a memleak on perf config query error path
   - Fix UHBR SST SDP splitting when sink doesn't support it

  bridge:
   - fix ti-sn65dsi83 error handling
   - tc358768: Enforce input bus flags via atomic_check

  ast:
   - fix blend mode property on cursor plane

  qxl:
   - fix blend mode property on primary/cursor planes

  virtio:
   - fix blend mode property on cursor plane

  vboxvideo:
   - fix blend mode property on planes

  rockchip:
   - fix endpoint name length
   - fix Kconfig issues

  ivpu:
   - limit firmware log prints to field size
   - validate buffer range in ivpu address translation
   - validate fw log buffers

  ethosu:
   - ensure SRAM sizing
   - ensure cmd stream formatting
   - drop IRQF_SHARED
   - fix open return value

  adp:
   - fix Kconfig

  logicvc:
   - fix Kconfig"

* tag 'drm-fixes-2026-09-12' of https://gitlab.freedesktop.org/drm/kernel: (38 commits)
  drm/amd/pm: report energy accumulator for smu 13.0.0
  drm/amd/pm: fix gpu metrics energy accumulator for smu 13.0.0/13.0.7
  drm/amd/display: Rebuild InfoFrames on output color space changes
  drm/amd/display: Honor Broadcast RGB for BT.2020 RGB output
  drm/amd/display: Propagate HDMI RGB quantization selectability
  Revert "drm/amdgpu: debugfs: avoid extra EOLs in amdgpu_gem_info"
  drm/amdgpu: skip gfx switch_power_profile during GPU reset
  drm/amd/display: Fix HF-VSDB DSC bpc detection to be cumulative
  drm/amd/display: Exit IPS before connector detection on resume
  drm/amd/display: Shorten hdmi_frl_status_polling_workqueue
  dm/amdgpu: fix malformed link_settings debugfs output
  drm/amdgpu: skip the VMID 0 flush for VRAM
  drm/amd/display: Consult MCCS FreeSync cap only if requested & supported
  drm/i915: Fix memory leak in query_perf_config_list()
  drm/i915/dp: Gate UHBR SST SDP splitting on sink capability
  drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches
  drm/xe: Guard page-fault worker with runtime PM check
  drm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work()
  drm/bridge: tc358768: Enforce input bus flags via atomic_check
  drm/drm_exec: fix up contended obj when num_objects is 0
  ...
2026-09-11 13:50:47 -07:00
Linus Torvalds
827751b699 RISC-V updates for v7.3-rc3
- Revert a bad fix, likely LLM-generated, in the pointer masking code
   that confused the RISC-V hardware pointer masking implementation
   with the Linux kernel tagged address feature
 
 - Fix unexpected faults caused by kprobe instruction slot writes when
   !CONFIG_STRICT_MODULE_RWX
 
 - Fix unexpected faults on minimal configurations during runtime code
   patching on !CONFIG_STRICT_MODULE_RWX systems
 
 - Fix a misplaced variable clear causing incorrect reuse of previous
   values in the RISC-V hardware feature probing code
 
 - Fix two bugs in the PMU SBI perf code on rv32: use BIT_ULL rather
   than BIT on 64-bit masks; and use a bitmap rather than an unsigned
   long on a quantity that can exceed 32 bits
 
 And a few miscellaneous cleanups:
 
 - Avoid a potential dereference-before-NULL-pointer-check bug in the
   PMU SBI perf driver
 
 - Simplify the rv32 bug table code by using
   CONFIG_GENERIC_BUG_RELATIVE_POINTERS (following x86 and PPC)
 
 - Report the RISC-V standard ISA extensions Z[v]fhmin when support is
   claimed for the superset RISC-V standard ISA extensions Z[v]fh; and
   simplify our FPU test code to only check for the presence of the D
   extension
 
 - Use an existing kernel string helper in place of some open-coded
   code in kernel/usercfi.c
 
 - Fix some yamllint issues in the RISC-V DT bindings for CPUs
 
 - Convert one use of __ASSEMBLY__ to __ASSEMBLER__ that snuck into the
   RISC-V CFI selftest code
 
 - Update the translation for the simplified Chinese translation of the
   RISC-V kernel patch acceptance policy
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEElRDoIDdEz9/svf2Kx4+xDQu9KksFAmqghcoACgkQx4+xDQu9
 KkvmEQ/7BVmPFuoR6OLNk2Eu8Exqen6a41KxdM/B91NJBEbBM60GAyejjWDXWmm0
 K21yhRu58RGbfg2kKUJMvawzwIfuDswxCS31VtpDKnTrmP4HQz1Yvnh2M7jH9D2d
 /wJCIYcJ0hJx0yDIZOUhU24aoy63ZXRygp8nTOgjkAxhkF31w+MJxTPDD0Ir7Eai
 y4sRMTCabMonmyA0qozfnMoXaO3FkPv9l7pw/LHfqUYjaLNQyMHiiDPrRj1oNZPD
 GQFUWykRgMccMW6kIgTJrjmzn7+vEJ7UZ/fvOD97+rGeaoyE19vcW8owUQWp6Hgb
 Jq3WyS9HImrpCBTr079ht5lhu3ZucpAEP6sK5v/m4GOlBv1HdYHUS6JH0qo4DnXZ
 aFrxg7WXxaFZ8dD3P8ErZkXy5Vid3+ZlpK//AOfWAqxX7q6c4K1w3lJm4bPKyNBX
 vh3ASQr5oEj3KpGbihsrX2lVB/5LVP3pWTcH5f6rBBYiVFMMhWKLJXA3pjiRFN7v
 ZXClKh5MznvS6ycMp5pXVYpVn2Kk+Y/mywsDqNRUigHwppkxI9MTJBq8+qcOiM9I
 a7mHna4XHVVu0+B4/JMhkWgnGYRjFD6bsGzxPZODLFcmBUxmsoa5+HOENLAGdQ1w
 s/Z2HmDO8yL37DxLq5O2aF3KNPSkXNBl+upQwj5lTTzR/bmghjc=
 =oMU+
 -----END PGP SIGNATURE-----

Merge tag 'riscv-for-linus-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux

Pull RISC-V fixes from Paul Walmsley:
 "From a RISC-V point of view, there's one notable fix here, reverting
  an earlier bogus fix to the pointer masking code. Fortunately the
  practical impact appears to be small.

   - Revert a bad fix, likely LLM-generated, in the pointer masking code
     that confused the RISC-V hardware pointer masking implementation
     with the Linux kernel tagged address feature

   - Fix unexpected faults caused by kprobe instruction slot writes when
     !CONFIG_STRICT_MODULE_RWX

   - Fix unexpected faults on minimal configurations during runtime code
     patching on !CONFIG_STRICT_MODULE_RWX systems

   - Fix a misplaced variable clear causing incorrect reuse of previous
     values in the RISC-V hardware feature probing code

   - Fix two bugs in the PMU SBI perf code on rv32: use BIT_ULL rather
     than BIT on 64-bit masks; and use a bitmap rather than an unsigned
     long on a quantity that can exceed 32 bits

  And a few miscellaneous cleanups:

   - Avoid a potential dereference-before-NULL-pointer-check bug in the
     PMU SBI perf driver

   - Use CONFIG_GENERIC_BUG_RELATIVE_POINTERS to simplify the rv32 bug
     table code (like x86 and PPC)

   - Report the RISC-V standard ISA extensions Z[v]fhmin when support is
     claimed for the superset RISC-V standard ISA extensions Z[v]fh; and
     simplify our FPU test code to only check for the presence of the D
     extension

   - Use an existing kernel string helper in place of some open-coded
     code in kernel/usercfi.c

   - Fix some yamllint issues in the RISC-V DT bindings for CPUs

   - Convert one use of __ASSEMBLY__ to __ASSEMBLER__ that snuck into
     the RISC-V CFI selftest code

   - Update the translation for the simplified Chinese translation of
     the RISC-V kernel patch acceptance policy"

* tag 'riscv-for-linus-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: skip software algning code for HAVE_EFFICIENT_UNALIGNED_ACCESS
  kselftest/riscv: Replace __ASSEMBLY__ with __ASSEMBLER__
  docs/zh_CN: Update arch/riscv/patch-acceptance.rst translation
  dt-bindings: riscv: cpus: Fix yamllint style issues
  riscv: hwprobe: simplify has_fpu() to check D extension only
  perf: RISC-V: check cpu_hw_evt before dereference in overflow IRQ
  riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present
  perf: RISC-V: store available counter mask as bitmap
  perf: RISC-V: use BIT_ULL for u64 overflow masks
  riscv: bug: Make RV32 use GENERIC_BUG_RELATIVE_POINTERS
  riscv: hwprobe: initialize pair->value in hwprobe_one_pair()
  riscv: use string helper in setup_global_riscv_enable()
  Revert "riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set"
  riscv: patch: skip fixmap mapping when kernel text is already writable
  riscv: mm: make EXECMEM_KPROBES writable without CONFIG_STRICT_MODULE_RWX
2026-09-11 13:15:13 -07:00
Linus Torvalds
1235ff3299 platform-drivers-x86 for v7.3-2
Fixes
 
 - amd/pmf: Fix build on !CONFIG_AMD_PMF_DEBUG
 
 - asus-laptop: Fix ACPI event handling
 
 - hp-wmi: Fix board_params typo for 8DD6 board
 
 - x86-android-tablets: Fix Arizona and Crystal Cove GPIO lookups
 
 The following is an automated shortlog grouped by driver:
 
 amd/pmf:
  -  fix build on !CONFIG_AMD_PMF_DEBUG
 
 asus-laptop:
  -  Fix ACPI event handling
 
 hp-wmi:
  -  Fix board_params typo for 8DD6 board
 
 MAINTAINERS:
  -  fix sysfs-platform-ayaneo-ec documentation path
 
 x86-android-tablets:
  -  add Crystal Cove GPIO swnode support
  -  drop redundant swnode group on YT3
  -  fix Arizona GPIO swnode references
  -  fix gpio_secondary_fwnode_init() not working
  -  hold device reference for secondary fwnode teardown
  -  pass node group to gpio_secondary_fwnode_init()
  -  use shared battery swnode group on Yoga Tab 2
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYKAB0WIQSCSUwRdwTNL2MhaBlZrE9hU+XOMQUCaqPXbQAKCRBZrE9hU+XO
 MQPMAP93XM4XaHUIoX2+xhCKXQxE0+3XlhrE1n737BweWFz1qgEApBFBXipytFFU
 85WexocupoYbJtlOoQ4gI8nt86XhcQk=
 =NAG2
 -----END PGP SIGNATURE-----

Merge tag 'platform-drivers-x86-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

Pull x86 platform driver fixes from Ilpo Järvinen:

 - amd/pmf: Fix build on !CONFIG_AMD_PMF_DEBUG

 - asus-laptop: Fix ACPI event handling

 - hp-wmi: Fix board_params typo for 8DD6 board

 - x86-android-tablets: Fix Arizona and Crystal Cove GPIO lookups

* tag 'platform-drivers-x86-v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
  MAINTAINERS: fix sysfs-platform-ayaneo-ec documentation path
  platform/x86: x86-android-tablets: fix gpio_secondary_fwnode_init() not working
  platform/x86: x86-android-tablets: use shared battery swnode group on Yoga Tab 2
  platform/x86: x86-android-tablets: drop redundant swnode group on YT3
  platform/x86: x86-android-tablets: add Crystal Cove GPIO swnode support
  platform/x86: x86-android-tablets: pass node group to gpio_secondary_fwnode_init()
  platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown
  platform/x86: x86-android-tablets: fix Arizona GPIO swnode references
  platform/x86/amd/pmf: fix build on !CONFIG_AMD_PMF_DEBUG
  platform/x86: asus-laptop: Fix ACPI event handling
  platform/x86: hp-wmi: Fix board_params typo for 8DD6 board
2026-09-11 12:52:48 -07:00
Linus Torvalds
707662b40a ata fix for 7.3-rc3
- Drop documentation for no longer existing pata_legacy kernel
    parameters (Ethan)
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYKAB0WIQRN+ES/c4tHlMch3DzJZDGjmcZNcgUCaqRQ0QAKCRDJZDGjmcZN
 ct1FAP96qnI8tDPHzWU+1znXhDEBXl3aVw8lvSBokR4yvqyDVQEAs3Jeaq38mZTQ
 C3jV+RbN4YUC/St8AFt7t73soEOb8wc=
 =zZKx
 -----END PGP SIGNATURE-----

Merge tag 'ata-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux

Pull ata fix from Niklas Cassel:

 - Drop documentation for no longer existing pata_legacy kernel
   parameters (Ethan)

* tag 'ata-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
  ata: pata_legacy: remove documentation for removed module parameters
2026-09-11 12:44:11 -07:00
Linus Torvalds
35ef102063 block-7.3-20260911
-----BEGIN PGP SIGNATURE-----
 
 iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmqj5hAQHGF4Ym9lQGtl
 cm5lbC5kawAKCRD301j7KXHgphqIEADE/9nkItU8nufHLICBr8FI+IncrvHJQpag
 1iLerBftMLxNJDS+CAQEF5oOcorL/6bUga6nHmMAds7pILdDzafWkvnuCbrGIC1q
 j0V7a0Rkalv87ObbYZcoKWTTjv0IdCmNEC93fitwTujqYclI7Hwvr/t+0nkprcxU
 jjbHq9tzkVHVX771usCIKOVRdI+xc5TSDbOfm13tE5ESH2GzZaPqu4Aqq3nvVSOO
 xmLYzDlz8NRApmCl6a3KzCxHi8fROMnjlaeQrAmh6+Zov/iB5Bzqo98NBeWXgbh6
 WvFxLm/zR5+WFppp+GblAZ5FtkOv5ICAYeM9fQkuiCo6o8/t+cxnTUgyex9qtMBr
 Uhoct1jM+eNCEWEgA1ZBRVWLsyr0FbNDrowsP4YvvqW3WdQeq8ABRz44lcRqhQJy
 BQYydnk7PpANdDhaAOO2JpoYbkokvPfT/8TwDFMmJlp+gwydXfE64IjE5ljaf6xr
 DRMxeZzFkwYrF++1KiN3Kozqe0jFINDuB9ysPrGlDHlPFK/tbx8nZn8aKOIHccBj
 mGNJ+fNWkFJczeuGiIbWEtNci0ZL+8eaDqF+uOp5odQ7vo8rYPv2TRff436dcI0c
 0EnQrC9orScabgRAIklnnEWjw9XoHmpoCTQE/LhlA1rf+zDNQ2cvNopBePDuxaku
 IChLh+u+0g==
 =JeEt
 -----END PGP SIGNATURE-----

Merge tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux

Pull block fixes from Jens Axboe:

 - Fix the start and length check added to iov_iter_extract_bvecs(),
   which used iter_iov_addr()/iter_iov_len() helpers that aren't safe
   for the ITER_BVEC/FOLIOQ/etc iterator types passed

 - sunvdc fixes for an -EIO issue from lack of retries, and unmapping
   LDC cookies when the descriptor send fails

 - Clear force_abort in ublk_queue_reset_io_flags()

 - ublk selftest install fix

* tag 'block-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
  selftests: ublk: add batch IO cases to recover_03
  ublk: clear force_abort in ublk_queue_reset_io_flags()
  sunvdc: fix -EIO issue due to lack of retries
  sunvdc: unmap LDC cookies when the descriptor send fails
  block: Fix start and length check added to iov_iter_extract_bvecs()
  selftests: ublk: install test_common.sh and trace/ scripts
2026-09-11 12:38:44 -07:00
Linus Torvalds
42f961c42b io_uring-7.3-20260911
-----BEGIN PGP SIGNATURE-----
 
 iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmqj5fsQHGF4Ym9lQGtl
 cm5lbC5kawAKCRD301j7KXHgpmGsD/0W7eNXJd/tFNPOdDwTr1/3yciqYXw5QO5Q
 eb2SLyr34sAODOItTYoBrIZ5b1Mbgm0yhT1wJ3YrVKLNLVSvbDPNtx5qtnAGcKvm
 09XsPmvlDcW8JLRsjd5dcsP+EDmgTNLuNGSeVycuTG91f5VD63vPHTKUhgKDabtC
 InM1LbIs2rz0tojdV6n4MOOF2AwZAOHqFtac+cQUCwuJhNtwUFClSUHxqYoP+JzE
 97ores3f+ArAtmOoVeH2wSCZTmwdB7MxOB8jmt8fdNSprW8nxTO3oT/eQzYXvlM9
 7LRJV/6SGVsWjuoEHAfW8G0p+JOzGGFvFIXGWEBenjtNmlyXJqfxYhkcLMw826ob
 pct3Rc5nheZbxKdCkHnY1AmEibS/c1kTZbDvSBXk9GLBKyQuI7B3yo163zMs3JjO
 YSAlLllDjdzOR6gCPg5HHZlywBWtXveC/xVBzDq7b1q07ysHFNO1yQplMM3U8sC0
 Eic4RcFU4ld+/L2GmbdgRZ9ataZsju+RFojSogA0NzR18HqVNQuZiVbY764GSop9
 HVW28lzoYamgvg5fLWJPrzJmdFrj/p8pi+cw1dK8uMk9VnFwdA740Nfhz1NWFS0Y
 TpvJtxc0f2ofrI1ilaa95vHC+wMyds1zxq9Bf4i9cgIhT17WqvE4SD0JMXmvza4k
 Yi72jzTTfQ==
 =zpCb
 -----END PGP SIGNATURE-----

Merge tag 'io_uring-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux

Pull io_uring fixes from Jens Axboe:

 - Fix a deadlock in the write path with superblock freezing

 - Fix an issue where a provided buffer ring would overconsume when
   using MSG_TRUNC

 - Keep the CQE flags on iopoll requests when adding kbuf flags

* tag 'io_uring-7.3-20260911' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
  io_uring/rw: keep CQE flags on iopoll requests when adding kbuf flags
  io_uring/net: don't overconsume buffers when using MSG_TRUNC
  io_uring/net: let io_recv_buf_select return the length of the buffer region
  io_uring/rw: end write accounting from ->ki_complete
2026-09-11 12:36:13 -07:00
April Cardenas
ebc5660132 smb/client: send lease break ACKs thru correct session for multiuser mounts
Currently, when cifs_oplock_break handles a break request from the server
it searches for the appropriate tlink to handle the request
but incorrectly uses the current fsuid as the search key, eventually
causing read errors for users with multiuser mounts on NetApp.
Fix this by using the tlink from the cfile struct instead to respond
through the correct session.

As breaks are handled in a worker thread, the current fsuid
isn't guaranteed to match the session that the break is intended for.
This means that cifs_sb_tlink may search the rbtree using the wrong fsuid,
and return a tlink with an incorrect session than
the lease break was intended for. As a result, the breaks
may be ACKed through an incorrect session.

While it seems that Samba/Windows Servers 2016-2025 ignore this as long as
the lease key is correct, we ran into a case where if you're using
NetApp ONTAP or Azure NetApp Files they will reject the ACK
and return `STATUS_LOCK_NOT_GRANTED` errors on any future read requests
a user may initiate through their still held open file handle,
and the server will eventually close the file.

In the dmesg logs, the user may see errors like these:

CIFS: Status code returned 0xc0000128 STATUS_FILE_CLOSED
CIFS: VFS: Send error in read = -9

With a multiuser mount using NetApp, this issue is really easy
for users to hit on a wide variety of kernel versions
by attempting to copy a file from the share
to the local machine through GNOME Files/Nautilus.
This copy will always result in Nautilus throwing
a `Bad File Descriptor` error to the user and fail.
With this fix, you can copy files through Nautilus without issue.

>From looking at the traces, it seems that glib will
open the file first, and call listxattr before actually attempting
to copy the file data. The listxattr call always triggers a break,
causing the copy to fail.

The proposed fix returns to the way the client grabbed the tlink before
commit e8f5f849ff ("cifs: fix potential oops in cifs_oplock_break").

The bulk of that commit (checking for list empty) remains untouched, and
I think the change to using cifs_sb_tlink was intended to avoid a
NULL/ERR deference on the tlink as well as update the reference count.

I believe this fix should preserve those safety properties, but of course
I'd appreciate any corrections here.

Fixes: e8f5f849ff ("cifs: fix potential oops in cifs_oplock_break")
Cc: stable@vger.kernel.org
Signed-off-by: April Cardenas <april.cardenas@canonical.com>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Reviewed-by: Bharath S M <bharathsm@microsoft.com>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
2026-09-11 16:24:15 -03:00
Sean Christopherson
8cd280282d KVM: Never clear KVM_REQ_VM_DEAD from a vCPU's requests
Use kvm_test_request() instead of kvm_check_request() when querying
KVM_REQ_VM_DEAD, i.e. don't clear KVM_REQ_VM_DEAD, as the entire purpose
of KVM_REQ_VM_DEAD is to prevent the vCPU from enterring the guest ever
again, even if userspace insists on redoing KVM_RUN.

Ensuring KVM_REQ_VM_DEAD is never cleared will allow relaxing KVM's rule
that ioctls can't be invoked on dead VMs, to only disallow ioctls if the
VM is bugged, i.e. if KVM hit a KVM_BUG_ON().

Opportunistically add compile-time assertions to guard against clearing
KVM_REQ_VM_DEAD through the standard APIs.

Reviewed-by: Kai Huang <kai.huang@intel.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260806214618.82180-1-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11 12:06:05 -07:00
Sean Christopherson
f13368e0ac KVM: selftests: Use __GLIBC__, not _GNU_SOURCE, to detect actual glibc
Use __GLIBC__ in the hardware disable test to detect when selftests are
being built/linked against glibc and thus pthread_attr_setaffinity_np() is
(hopefully) available.  As pointed out by Sashiko and Hisam, _GNU_SOURCE is
effectively a "request" macro to enable functionality, whereas __GLIBC__ is
an announcement of support and selftests' idiomatic way of guarding code
that's specific to glibc.

Fixes: 496779b549 ("KVM: selftests: Pre-set threads affinity in hardware disable test when possible")
Reported-by: Sashiko Bot <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260731201140.5AF0C1F00AC4@smtp.kernel.org
Suggested-by: Hisam Mehboob <hisamshar@gmail.com>
Link: https://patch.msgid.link/20260826161430.714316-1-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11 12:04:36 -07:00
Jim Mattson
79a71cc256 KVM: x86/pmu: Move Intel PMU global MSRs to intel_is_valid_msr()
Commit c85cdc1cc1 ("KVM: x86/pmu: Move handling PERF_GLOBAL_CTRL and
friends to common x86") moved the existence check for the following Intel
PMU MSRs to kvm_pmu_is_valid_msr():
 - MSR_CORE_PERF_GLOBAL_STATUS
 - MSR_CORE_PERF_GLOBAL_CTRL
 - MSR_CORE_PERF_GLOBAL_OVF_CTRL

That commit deemed these MSRs valid whenever pmu->version > 1. It intended
to share the check with AMD PerfMonV2 because both vendor implementations
require version 2 or greater for global PMU controls.  However, as noted in
the commit message, AMD uses different MSR indices for its global PMU
registers.

Commit 4a2771895c ("KVM: x86/svm/pmu: Add AMD PerfMonV2 support")
subsequently added AMD PerfMonV2 support and set pmu->version = 2.  Because
kvm_pmu_is_valid_msr() validated the Intel MSRs whenever pmu->version > 1,
KVM incorrectly permitted AMD guests with PerfMonV2 to access these Intel
MSRs without a #GP.

Move the validation of these Intel MSRs to intel_is_valid_msr() and remove
the common switch statement from kvm_pmu_is_valid_msr(). AMD already
validates its own global PMU MSRs in amd_is_valid_msr().

Fixes: 4a2771895c ("KVM: x86/svm/pmu: Add AMD PerfMonV2 support")
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Like Xu <likexu@tencent.com>
Reviewed-by: Sandipan Das <sandipan.das@amd.com>
Link: https://patch.msgid.link/20260902184711.138538-1-jmattson@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-11 12:02:07 -07:00
Linus Torvalds
3026c6e4f2 slab fixes for 7.3-rc2
-----BEGIN PGP SIGNATURE-----
 
 iQFPBAABCAA5FiEEe7vIQRWZI0iWSE3xu+CwddJFiJoFAmqjuAUbFIAAAAAABAAO
 bWFudTIsMi41KzEuMTIsMiwyAAoJELvgsHXSRYia070H/RpgbPlRT+YF5EceAqlz
 gbCHYJa7ep52uCIZSgHd0DpMiE3jF8tRtLlpaF2l961hYXIr+NhEC9HKerJcD5tc
 4LUpGu6Cs5/ruYz7fbAltYrAZ2YOAhaJwBBy0Buc2Xl37OpONR8hUWMYlqqXBSWM
 bApp9mrRYzLmQBpYn5N1KyZU9gBespiouCnStEUzD2s06VjnHSUJ5tBplbXXPC0v
 My/kjaUim9z0P91FHPFooFQtzhlLQI96obROsbKR18euePml+C+XPhhmDwAY0NVT
 VtAPm2ov7oTvy0FvjDAVzAdrYGIIXVluonJqhgLFi6+Um1L3iBE39Q2OEMiQ/Lq3
 044=
 =B/eP
 -----END PGP SIGNATURE-----

Merge tag 'slab-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/slab

Pull slab fixes from Vlastimil Babka:

 - Stable fix for an ABA issue causing slab list corruption introduced
   in 7.2 (Harry Yoo, with big thanks to Hyunwoo Kim for the thorough
   report and initial version of the fix)

 - Fix for 7.3 regression of kvfree_rcu() on PREEMPT_RT which can cause
   a deadlock from the set_cpus_allowed_force() caller (Vlastimil Babka)

* tag 'slab-for-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/slab:
  mm/slab: take n->list_lock in __slab_try_return_freelist() to avoid race
  mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again
2026-09-11 11:56:33 -07:00
Stefano Radaelli
7ba5290db6 arm64: dts: imx8mp-var-dart-sonata: Fix Sonata SD I/O supply
LDO5 powers the USDHC2 I/O rail on DART-MX8M-PLUS.
Without a regulator consumer, the kernel disables LDO5 during late init,
which removes the SD card and causes filesystem I/O errors.

Reference LDO5 as the Sonata USDHC2 VQMMC supply, so the regulator
remains enabled while the SD interface is active.

Fixes: 41cd3d91ca ("arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board")
Co-developed-by: Luan Rafael Carneiro <luan.r@variscite.com>
Signed-off-by: Luan Rafael Carneiro <luan.r@variscite.com>
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-09-11 14:50:09 -04:00
Neil Armstrong
a2b6583798 drm/msm/a6xx: Use CX AO Counter register for timestamp on a750 GPUs
The a750 uses the GMU CX AO Counters instead of the GMU_ALWAYS_ON_COUNTER
register on A6xx and other A7xx GPUs, use it when running a A750 GPU.

The GMU_ALWAYS_ON_COUNTER at offset 0x1f888 doesn't seem to exist
on the SM8650 A750 GMU and returns 0, but the CX AO counter at offset
0x1f880 returns some proper timestamp data.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/752235/
Message-ID: <20260909-topic-sm8650-gmu-a750-timestamp-reg-v2-2-091d74958951@linaro.org>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-09-11 11:36:41 -07:00
Neil Armstrong
ed9ad3d418 drm/msm/a6xx: Add CX AO Counter registers used for a750 GPUs
The a750 uses the CX AO Counters instead of the GMU_ALWAYS_ON_COUNTER
register on A6xx and other A7xx GPUs.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/752234/
Message-ID: <20260909-topic-sm8650-gmu-a750-timestamp-reg-v2-1-091d74958951@linaro.org>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-09-11 11:36:41 -07:00
George Emmanuel Thomas
3163cd7253 drm/msm: remove stale perf counter XML TODO
The adreno_perfcntrs macro already takes the XML file stem as its second
argument, allowing each perf counter JSON file to select the appropriate
register XML. The a2xx and a5xx entries already pass their respective
XML file stems.

Remove the stale TODO comment.

Signed-off-by: George Emmanuel Thomas <georgeemmanuelthomas@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/746745/
Message-ID: <20260815164335.158958-1-georgeemmanuelthomas@gmail.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-09-11 11:33:27 -07:00
Hao Zhang
327c428ba7 blk-cgroup: save IRQ state in blkg_tryget_closest()
bio_set_dev() associates the bio with a blkg through bio_associate_blkg().
If the blkg lookup misses, blkg_tryget_closest() takes q->queue_lock with
spin_lock_irq() and releases it with spin_unlock_irq(), which
unconditionally enables local interrupts.

Callers may call bio_set_dev() with interrupts already disabled, e.g.
dm-thin's pool_map() does so while holding pool->lock taken with
spin_lock_irq().  The nested spin_unlock_irq() then enables interrupts
while pool->lock is still held, so an I/O completion softirq can run on
the same CPU, re-acquire pool->lock (thin_endio(), or overwrite_endio()
-> complete_mapping_preparation()) and deadlock.  lockdep reports this
as inconsistent SOFTIRQ-ON-W to IN-SOFTIRQ-W usage.

Commit 3a762de55b ("block: save irq state in blkg_lookup_create()")
fixed the same problem while the lock lived in blkg_lookup_create(), but
commit 9327a865e3 ("blk-cgroup: don't nest queue_lock under rcu in
blkg_lookup_create()") moved the locking into blkg_tryget_closest() and
reverted it to spin_lock_irq().

Save and restore the caller's IRQ state instead.

Fixes: 9327a865e3 ("blk-cgroup: don't nest queue_lock under rcu in blkg_lookup_create()")
Cc: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Hao Zhang <zhanghao1@kylinos.cn>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://patch.msgid.link/aqQmqb1k57PXj8Ef@192.168.1.215
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-11 12:32:40 -06:00
Sebastian Andrzej Siewior
815e07c8fe ring-buffer: Acquire the lock with irqsave in rb_wake_up_waiters()
rb_wake_up_waiters() is a irq_work callback which is initialized with
init_irq_work(). As such it will be invoked in thread context on
PREEMPT_RT. Invoking the callback in IRQ context on PREEMPT_RT is not an
option due its usage of wake_up_all().  Since this callback may run in
thread context, it needs to acquire ring_buffer_per_cpu::reader_lock with
disabling interrupts and may not assume that they are disabled.

Use raw_spinlock_irqsave() to acquire ring_buffer_per_cpu::reader_lock.

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260911102152.YEtwkBj9@linutronix.de
Fixes: 68282dd930 ("ring-buffer: Fix resetting of shortest_full")
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 14:09:42 -04:00
Jérémy Jean
23c240d950 smb: client: validate absolute native symlink targets before NT fixups
With symlinkroot unset, an absolute target is copied without conversion
to an NT drive path. Later code still assumes an NT prefix is present
when modifying the target and calculating the print name length.

For "/ab", this causes two failures: sym[5] and path[5] are written
past their allocations, and plen -= 2 * poff subtracts an assumed
8-byte prefix from a 6-byte UTF-16 target, wrapping u16 plen to 65534.
That underflow causes another overflow: memcpy() copies 65534 bytes
into a 24-byte buffer. A user with write access to a mounted share
can trigger these bugs with default settings.

Validate the NT drive prefix, including an ASCII drive letter, before
accessing fixed offsets or subtracting the prefix length.

Fixes: 3363da82e0 ("smb: client: fix native SMB symlink traversal")
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
2026-09-11 15:06:01 -03:00
Steven Rostedt
ed0aff60f8 tracing: Take trace_array reference when opening a tracer options file
When a tracer option file is opened, it is passed a descriptor that points
to an element on the trace_array's topts array. This element has
information to find the trace array and other information. It uses this
element to take a reference of the trace_array so that the trace_array
does not get removed while this file is opened.

Unfortunately, there's a race condition where the element itself could be
freed by the removal of the instance the trace_array represents causing a
use-after-free as this element that is used to find the trace_array to
increment its reference counter is also freed when the instance is
removed.

To solve this, add a trace_array_tracer_options_get() helper function that
will take the address of the element that is passed to the open function
by the inode->i_private pointer and search all the trace_arrays under a
lock to find the one that the element's address is in the range of the
trace_arrays topts array elements. When a match happens, that trace_array's
reference would be increased.

Note, there's a race where if an admin was deleting and creating trace
instances at the same time and the memory of the old trace_array's array
matched the memory of the new trace_array that it could in theory open the
option from the wrong trace array. But we do not care because it would be
stupid to perform that kind of action. As long as the only thing that can
happen is that the option from the wrong trace array is used and doesn't
crash the kernel it will only make the user confused. But if they are
doing something stupid like this, they are already confused, so no harm
done.

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260910221209.62dad8d3@robin
Fixes: 7e2cfbd2d3 ("tracing: Have option files inc the trace array ref count")
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/linux-trace-kernel/20260902121918.5a9e9d1b@gandalf.local.home/
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 14:04:14 -04:00
Karl Mehltretter
7e645147df tracing: Fix ring_buffer_read_page_size() kernel-doc
ring_buffer_read_page_size() takes a parameter named rpage, but its
kernel-doc describes page. As a result, kernel-doc reports rpage as
undescribed and page as an excess parameter description.

Rename the documentation entry to match the function.

Link: https://patch.msgid.link/20260909062917.89482-1-kmehltretter@gmail.com
Fixes: dae8dda341 ("tracing: Fix subbuf resize races with trace_pipe_raw readers")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 14:04:05 -04:00
Thomas Weißschuh
911002e99e tracing: Restore :mod: trailer after parsing in ftrace_set_clr_event()
While ftrace_set_clr_event() modifies its input buffer during parsing,
before returning to the caller the buffer is supposed to be restored
to its original state.

This works correctly for the colon between the subsystem and event
but not the colon at the beginning of :mod:.

Restore the colon, so the :mod: trailer is not stripped after
ftrace_set_clr_event().

Cc: stable@vger.kernel.org
Fixes: 4c86bc531e ("tracing: Add :mod: command to enabled module events")
Link: https://patch.msgid.link/20260908-tracing-cli-event-filter-v2-1-05396a3fb663@linutronix.de
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 14:01:46 -04:00
Donggeun Yoo
7f711e6235 tracing: Fix memory corruption from a "STACKTRACE" histogram key
"cpu", "CPU", "stacktrace" and "STACKTRACE" are generic fields, defined
with an offset and a size of zero so that the filter code can match them
by name. parse_field() maps them onto their common_* equivalents for
backward compatibility, but unlike the common_* names it hands the
placeholder back to the caller instead of NULL.

create_hist_field() takes a non-NULL field as a promise that the record
carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc
word is read from offset 0, that is from common_type, and its low 16
bits are followed as an offset into the record. What is found there
becomes the length of an unbounded memcpy. Pick an event whose id is
small enough that the offset stays inside its own record and the length
is a kernel text address:

  # cd /sys/kernel/tracing
  # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger
  # echo hello > trace_marker

  Oops: general protection fault, probably for non-canonical address
  RIP: 0010:rb_next+0x23/0x60
   </IRQ>
  RIP: 0010:memcpy+0xc/0x30
   event_hist_trigger+0x2e7/0x12c0
  Kernel panic - not syncing: Fatal exception in interrupt

Leave the field NULL, which is what the comment above the branch says
the code does and what common_stacktrace already does. FILTER_CPU and
FILTER_COMM are left alone, their create_hist_field() branches never
look at the field.

Cc: stable@vger.kernel.org
Fixes: 4b512860bd ("tracing: Rename stacktrace field to common_stacktrace")
Link: https://patch.msgid.link/20260907155045.692664-3-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 14:01:36 -04:00
Donggeun Yoo
a5e70ba87c tracing: Fix memory corruption from the histogram stacktrace modifier
parse_field() sets HIST_FIELD_FL_STACKTRACE from the ".stacktrace"
modifier before it looks the field name up, and nothing afterwards
checks that the name resolved to a field which holds a stacktrace.
create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the
field pointer alone, which reads a __data_loc word from the record and
follows its low 16 bits as an offset into the same record.
event_hist_trigger() takes the first word there as an entry count and
copies that many longs into a 31 entry array:

	n_entries = *stack;
	memcpy(entries, ++stack, n_entries * sizeof(unsigned long));

Neither end of that copy is bounded, and the count is whatever the event
holds at the offset, so any field will do:

  # cd /sys/kernel/tracing/events/sched/sched_process_fork
  # echo 'hist:keys=parent_pid.stacktrace' > trigger
  # (true)

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  RIP: 0010:rb_insert_color+0x18/0x130
   timerqueue_linked_add+0x7e/0xd0
   enqueue_hrtimer+0x39/0xb0
   __hrtimer_run_queues+0x10f/0x1f0
   </IRQ>
  RIP: 0010:memcpy+0xc/0x30
   event_hist_trigger+0x165/0x690

The timer interrupt landed on the rbtree the copy had already run over.
No debug options are needed for this; KASAN reports the same write as an
out-of-bounds read of 13835058055416381440 bytes.

Documentation/trace/histogram.rst already states the rule, "must be a
long[] type", so enforce it once the name has been resolved. Names which
resolve to no field at all, "hitcount.stacktrace" and the common_*
pseudo-fields, are refused for the same reason: they hold no stacktrace
to read.

Cc: stable@vger.kernel.org
Fixes: cc5fc8bfc9 ("tracing/histogram: Add stacktrace type")
Link: https://patch.msgid.link/20260907155045.692664-2-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 14:01:16 -04:00
Donggeun Yoo
92383cef66 tracing: Undo the registration when enabling the histogram trigger fails
Commit 6f86bdeab6 ("tracing: Fix bad hist from corrupting named_triggers
list") described how a trigger that is registered but not on file->triggers
ends up freed while still on the global named_triggers list, and moved the
registration down so that hist_trigger_enable() follows it immediately. One
path still gets there. hist_trigger_enable() adds the trigger and takes it
straight back out when the event cannot be enabled:

	list_add_tail_rcu(&data->list, &file->triggers);

	update_cond_flag(file);

	if (trace_event_trigger_enable_disable(file, 1) < 0) {
		list_del_rcu(&data->list);
		update_cond_flag(file);
		ret--;
	}

so the list walk in hist_unregister_trigger() matches nothing, test stays
NULL, and the ->free() that would call del_named_trigger() is skipped.
out_unreg falls through to out_free, which frees the trigger anyway:

 BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
 Read of size 8 at addr ffff8880091d3160 by task init/1
  find_named_trigger+0xac/0xc0
  hist_register_trigger+0xc1/0xa00
  event_hist_trigger_parse+0x3146/0x6af0
  event_trigger_write+0xce/0x160
 Freed by task 69:
  kfree+0x154/0x420
  trigger_kthread_fn+0xfd/0x160

Leave the trigger where hist_unregister_trigger() can find it and let that
undo the registration, which is the only code that knows all of what
cmd_ops->init() took: the named list entry, the hist_pad reference, the
reference on the trigger a named histogram is shared with, and the copied
cmd_ops. It also pairs the failed trace_event_trigger_enable_disable(),
whose sm_ref and buffered event reference are otherwise left behind.

Since ->free() releases trigger_data and, for a trigger that does not share
its histogram, hist_data with it, out_unreg can no longer fall through to
out_free. For a trigger that does share, hist_register_trigger() has
already destroyed the caller's hist_data, so the fall-through was reading
freed memory there as well.

Move the enable_timestamps check in hist_unregister_trigger() above the
->free() call for the same reason: hist_data does not outlive it once the
trigger being removed is the one that owns it.

Cc: stable@vger.kernel.org
Fixes: 067fe038e7 ("tracing: Add variable reference handling to hist triggers")
Reported-by: Sashiko AI <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/
Link: https://patch.msgid.link/20260907124420.607097-3-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 14:00:41 -04:00
Donggeun Yoo
0fe23b8eab tracing: Take the reference before publishing the named histogram trigger
event_hist_trigger_named_init() puts the trigger on the global
named_triggers list and only then takes the reference on the trigger it
shares its histogram with:

	data->ref++;

	save_named_trigger(data->named_data->name, data);

	ret = event_hist_trigger_init(data->named_data);
	if (ret < 0) {
		kfree(data->cmd_ops);
		data->cmd_ops = &trigger_hist_cmd;
	}

	return ret;

event_hist_trigger_init() fails when alloc_hist_pad() cannot allocate, and
nothing takes the trigger back off the list on the way out.
event_hist_trigger_parse() frees it, and the next lookup by name reads the
freed object:

 BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
 Read of size 8 at addr ffff888009346860 by task init/1
  find_named_trigger+0xac/0xc0
  hist_register_trigger+0xc1/0xa00
  event_hist_trigger_parse+0x3146/0x6af0
  event_trigger_write+0xce/0x160
 Freed by task 67:
  kfree+0x154/0x420
  trigger_kthread_fn+0xfd/0x160

Do the reference first and publish once it has succeeded, so that nothing
which can fail runs after the trigger becomes findable.

Cc: stable@vger.kernel.org
Fixes: 7ab0fc61ce ("tracing: Move histogram trigger variables from stack to per CPU structure")
Reported-by: Sashiko AI <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-trace-kernel/20260907092944.3950E1F00A3D@smtp.kernel.org/
Link: https://patch.msgid.link/20260907124420.607097-2-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Acked-by: Tom Zanussi <zanussi@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 14:00:32 -04:00
Donggeun Yoo
6ede78d056 tracing: Set the trace clock before registering the histogram trigger
hist_register_trigger() puts the trigger on the global named_triggers
list in cmd_ops->init(), and only then sets the trace clock:

	if (data->cmd_ops->init) {
		ret = data->cmd_ops->init(data);
		if (ret < 0)
			goto out;
	}

	if (hist_data->enable_timestamps) {
		ret = tracing_set_clock(file->tr, hist_data->attrs->clock);
		if (ret) {
			hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock));
			goto out;
		}

The clock string is not checked anywhere before that call, so a named
trigger using common_timestamp with an unknown clock fails after it has
already become findable. event_hist_trigger_parse() then frees it
without taking it off the list, and the next lookup by name reads the
freed object:

 ~# cd /sys/kernel/tracing/events/sched/sched_switch
 ~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger
 bash: echo: write error: Invalid argument
 ~# echo 'hist:name=foo:keys=common_pid' > trigger

  BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
  Read of size 8 at addr ffff88800915d760 by task init/1
   find_named_trigger+0xac/0xc0
   hist_register_trigger+0xc1/0x900
   event_hist_trigger_parse+0x3146/0x6af0
   event_trigger_write+0xce/0x160
  Freed by task 63:
   kfree+0x154/0x420
   trigger_kthread_fn+0xfd/0x160

Set the clock before the trigger is registered, so that nothing which
can fail runs after it is published, the way commit 6f86bdeab6
("tracing: Fix bad hist from corrupting named_triggers list") moved the
registration below the rest of the setup.

tracing_set_filter_buffering() is reference counted, so the init failure
path has to drop the reference that the clock block now takes first.

Cc: stable@vger.kernel.org
Fixes: a4072fe85b ("tracing: Add a clock attribute for hist triggers")
Link: https://patch.msgid.link/20260907091415.554535-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 13:54:36 -04:00
Hemanth Selam
0999d3e16d tracing: Fix typo "preceeded" in comment
Correct "preceeded" to "Preceded", reported by scripts/checkpatch.pl using
the misspelling list in scripts/spelling.txt.  Only touches comments, no
code changes.

Link: https://patch.msgid.link/20260907065607.36615-1-hemanth.selam@gmail.com
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 13:54:32 -04:00
Hemanth Selam
89b000ba07 tracing: Fix typo "availabe" in comment
Correct "availabe" to "available", reported by scripts/checkpatch.pl using
the misspelling list in scripts/spelling.txt.  Only touches comments, no
code changes.

Link: https://patch.msgid.link/20260907062608.13924-1-hemanth.selam@gmail.com
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 13:54:14 -04:00
Donggeun Yoo
3d617bfd79 tracing: Let histogram values keep the percent and graph modifiers
The .percent and .graph modifiers exist only for histogram values, but a
value carrying either of them has been rejected since v6.3. The example
in Documentation/trace/histogram.rst,

  # echo 'hist:keys=prev_comm:vals=hitcount.percent:nohitcount' > \
	 events/sched/sched_switch/trigger

returns -EINVAL.

parse_field() sets the two flags only when the field is neither a key nor
a variable, that is, only on a value:

	} else if (strncmp(modifier, "percent", 7) == 0) {
		if (*flags & (HIST_FIELD_FL_VAR | HIST_FIELD_FL_KEY))
			goto error;
		*flags |= HIST_FIELD_FL_PERCENT;

__create_val_field() then rejects a value for carrying them, so no field
can reach hist_trigger_print_val(), where both are implemented.

commit e0213434fe ("tracing: Do not let histogram values have some
modifiers") added the check after a value with .buckets oopsed in
hist_field_name(). That happens because .buckets and .log2 make
create_hist_field() build a nested field in operands[0] which
hist_field_name() then walks into. The percent and graph flags do not
create an operand and are not read by hist_field_name(); they are only
used when printing a value.

Stop rejecting the two flags on a value. The check for variables is left
alone, where they are unreachable anyway because parse_field() rejects a
variable carrying them first.

With the two flags removed, the trigger above installs and prints as
documented:

  { prev_comm: rcu_preempt  }  hitcount (%):   0.00
  { prev_comm: init         }  hitcount (%):  99.98
  Totals:
      Hits: 237896

Cc: stable@vger.kernel.org
Fixes: e0213434fe ("tracing: Do not let histogram values have some modifiers")
Link: https://patch.msgid.link/20260907052113.430818-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 13:48:32 -04:00
Donggeun Yoo
06f5634ec5 tracing: Keep the entry count when the histogram stats allocation fails
print_entries() uses n_entries both as the number of sort entries and as
its own return value, so the -ENOMEM it stores when the stats allocation
fails overwrites the count that the cleanup still needs:

	n_entries = tracing_map_sort_entries(map, ...);
	if (n_entries < 0)
		return n_entries;
	...
			if (!stats) {
				n_entries = -ENOMEM;
				goto out;
			}
	...
 out:
	tracing_map_destroy_sort_entries(sort_entries, n_entries);

tracing_map_destroy_sort_entries() takes an unsigned int and loops up to
it, so -ENOMEM arrives as 4294967284. It walks an array of at most
map->max_elts pointers and calls destroy_sort_entry(), which dereferences
and frees, on whatever lies past the end.

Reading the hist file of a trigger with a .percent value, with that
allocation forced to fail:

  BUG: KASAN: vmalloc-out-of-bounds in tracing_map_destroy_sort_entries+0xa0/0xb0
  Read of size 8 at addr ffffc90000045000 by task init/1
   tracing_map_destroy_sort_entries+0xa0/0xb0
   hist_show+0x6f7/0x1df0
   seq_read_iter+0x2b8/0x1190
   vfs_read+0x176/0xa40
  The buggy address belongs to a 4-page vmalloc region starting at
  ffffc90000041000 allocated at tracing_map_sort_entries+0x5c/0xd50

A few pages further the fault is fatal. The registers at the oops confirm
the bound: the loop's end pointer less the array start, over the pointer
size, is 4294967284.

Return the error in a separate variable and leave n_entries holding the
count, the way tracing_map_sort_entries() does on its own error path.

The stats block is only entered for a value carrying .percent or .graph,
which __create_val_field() has rejected since v6.3, so this cannot be
reached in mainline as it stands. It becomes reachable again with
"tracing: hist: let values keep the percent and graph modifiers", so it
should be applied first.

Cc: stable@vger.kernel.org
Fixes: abaa5258ce ("tracing: Add .percent suffix option to histogram values")
Link: https://patch.msgid.link/20260907060323.480728-1-donggeunyoo.kernel@gmail.com
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/all/20260907053113.1CED91F00A3A@smtp.kernel.org/
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 13:47:42 -04:00
Donggeun Yoo
230234d12c tracing: Free histogram the field rejected for a bad modifier
Writing a hist trigger whose value or variable carries a modifier that is
not allowed there leaks the fields that were built for it.

__create_val_field() takes the field from parse_expr() and stores it in
hist_data->fields[] only after the modifier checks have run:

	hist_field = parse_expr(hist_data, file, field_str, flags, var_name,
				&n_subexprs);
	...
	if (hist_field->flags & HIST_FIELD_FL_VAR) {
		if (hist_field->flags & (...))
			goto err;
	} else {
		if (hist_field->flags & (...))
			goto err;
	}

	hist_data->fields[val_idx] = hist_field;

Both checks jump past that store, and the err label returns without
freeing anything. The error unwinds to create_hist_data(), which calls
destroy_hist_data() -> destroy_hist_fields(), and that reaches a field
only by walking fields[]. A field that never got there is unreachable.

commit e0213434fe ("tracing: Do not let histogram values have some
modifiers") set ret to -EINVAL and fell through to the store, which left
the field owned by fields[] and freed along with the rest of hist_data.
Splitting the check into a value case and a variable case replaced that
fall-through with a goto that skips it.

With CONFIG_DEBUG_KMEMLEAK, 200 writes of

  # echo 'hist:keys=prev_pid:vals=next_pid.log2' > \
	 events/sched/sched_switch/trigger

each correctly rejected with -EINVAL, leave 332 unreferenced objects
(63744 bytes) reported at create_hist_field(); 200 install and remove
cycles of a valid trigger leave none. A '.log2' field is two
allocations, since create_hist_field() puts the plain field in
operands[0] of the log2 field, and both are reported.

Use destroy_hist_field() rather than __destroy_hist_field() so that
operands[0] is freed as well. It returns early for HIST_FIELD_FL_VAR_REF,
which is what an operand owned by hist_data->var_refs[] needs; the
rejected field itself is never a var ref, because a var ref never carries
a modifier flag.

Cc: stable@vger.kernel.org
Fixes: e30fbc618e ("tracing/histograms: Allow variables to have some modifiers")
Link: https://patch.msgid.link/20260907034948.240387-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 13:46:40 -04:00
Donggeun Yoo
516001d53e tracing: Free histogram the var ref when its initialization fails
create_var_ref() allocates a VAR_REF hist_field and then calls
init_var_ref() to fill it in. When that fails the field is leaked.

commit 656fe2ba85 ("tracing: Use hist trigger's var_ref array to destroy
var_refs") made destroy_hist_field() return early for
HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's
var_refs[] array instead. create_var_ref() adds the field to that array
only after init_var_ref() has succeeded, so on this path the field is in
neither place and nothing frees it. The call was correct when it was
written, before var refs were taken out of destroy_hist_field().

init_var_ref() cannot free it either. The caller owns the field, so
init_var_ref() undoes only its own string allocations and leaves the
field alone. Freeing it there would leave create_var_ref() passing freed
memory to destroy_hist_field(), which reads its flags.

Call __destroy_hist_field(), which frees the field without consulting
the flag.

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260906133352.3815019-1-donggeunyoo.kernel@gmail.com
Fixes: 656fe2ba85 ("tracing: Use hist trigger's var_ref array to destroy var_refs")
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 13:46:34 -04:00
Donggeun Yoo
4bddcb346a tracing: Free histogram var refs regardless of how often they are referenced
Using the same variable three or more times in one hist trigger leaks the
variable reference and its strings when the trigger is removed.

commit 656fe2ba85 ("tracing: Use hist trigger's var_ref array to destroy
var_refs") made a trigger's var_refs[] array the only owner of a var ref:
destroy_hist_field() returns early for HIST_FIELD_FL_VAR_REF, so the field
expressions never destroy one. One entry, freed once, no count needed.

commit 8bcebc77e8 ("tracing: Fix histogram code when expression has same
var as value") then made repeated references share one object and added a
count of them. Only the increment side exists, since those expressions
still return early and never drop a reference, so __destroy_hist_field()
sees how many references were created rather than how many are left. It
frees when the decremented count is 0 or 1, so two references work and
three or more leak.

Sharing kept one array entry per object, and create_var_ref() searches and
appends within a single trigger, so nothing outside it holds the object.
Removing a trigger whose variables are still referenced is already refused
by check_var_refs() with -EBUSY. Drop the count and free unconditionally.

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260906124025.3550596-1-donggeunyoo.kernel@gmail.com
Fixes: 8bcebc77e8 ("tracing: Fix histogram code when expression has same var as value")
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 13:46:03 -04:00
Donggeun Yoo
0701995aaf function_graph: Use the saved entry's size when reprinting it
When a graph entry does not fit in the trace_seq, print_graph_entry()
saves it in the iterator's fgraph_data and reprints it on the next read.
The entry has already been consumed from the ring buffer by then, so the
copy is all that is left of it.

The copy is sized with iter->ent_size, which no longer describes the
saved entry but whatever entry the iterator has moved on to. The
argument count is derived from the same field, so a 72 byte entry saved
and then reprinted ahead of a 48 byte return entry loses its arguments.

Record the size next to the failure flag, so that the two are always set
together, and restore it before reprinting.

Cc: stable@vger.kernel.org
Fixes: ff5c9c576e ("ftrace: Add support for function argument to graph tracer")
Link: https://patch.msgid.link/20260906034406.1335316-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 13:39:08 -04:00
Donggeun Yoo
b228454870 fgraph: Remove unused FGRAPH_MAX_INDEX
FGRAPH_MAX_INDEX has no user, and it expands to FGRAPH_INDEX_SIZE and
FGRAPH_RET_INDEX, neither of which is defined anywhere in the tree. It
was added in that form by commit 91c46b0aa9 ("function_graph:
Implement fgraph_reserve_data() and fgraph_retrieve_data()"), which
introduced the current data word layout under new names, so anything
referencing it would have failed to build ever since.

Remove it.

Link: https://patch.msgid.link/20260905211922.1196366-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 13:37:50 -04:00
Jérémy Jean
08cacffeef ftrace: fork: Initialize function graph state before copy_exec_state()
dup_task_struct() copies the parent's task_struct, including ret_stack.
ftrace_graph_init_task() clears the copied function graph state, but it
currently runs after copy_exec_state().

For non-CLONE_VM forks, copy_exec_state() allocates a new task_exec_state.
If that allocation fails, copy_process() reaches bad_fork_free and
free_task() calls ftrace_graph_exit_task(). Since the child still carries
the parent's ret_stack pointer, the unwind frees the parent's active
function graph return stack. The parent subsequently accesses freed memory
from function_graph_enter_regs().

KASAN reports:

[   22.190920] ==================================================================
[   22.195899] BUG: KASAN: slab-use-after-free in function_graph_enter_regs+0xa76/0xb90
[   22.200747] Write of size 8 at addr ff110000054dc0a8 by task repro/1
[   22.205134]
[   22.210770] CPU: 0 UID: 0 PID: 1 Comm: repro Not tainted 7.2.0-07732-g9328b3b03bdc-dirty #3 PREEMPT(lazy)
[   22.212576] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   22.213750] Call Trace:
[   22.215271]  <TASK>
[   22.216242]  ? ftrace_stub_direct_tramp+0x10/0x10
[   22.217774]  dump_stack_lvl+0x4e/0x70
[   22.220531]  print_report+0x157/0x4b4
[   22.223202]  ? fixup_red_left+0x9/0x30
[   22.224407]  ? complete_report_info+0x83/0x110
[   22.226679]  ? function_graph_enter_regs+0xa76/0xb90
[   22.228084]  kasan_report+0xce/0x100
[   22.230109]  ? function_graph_enter_regs+0xa76/0xb90
[   22.232860]  ? stack_trace_save+0x4/0xd0
[   22.234156]  function_graph_enter_regs+0xa76/0xb90
[   22.236090]  ? kasan_save_stack+0x30/0x50
[   22.237752]  ? __pfx_function_graph_enter_regs+0x10/0x10
[   22.238694]  ? ring_buffer_lock_reserve+0x345/0xf80
[   22.239628]  ? stack_trace_save+0x4/0xd0
[   22.242121]  ? stack_trace_save+0x4/0xd0
[   22.243588]  ftrace_graph_func+0xda/0x160
[   22.245362]  ? ftrace_stub_direct_tramp+0x10/0x10
[   22.246520]  0xffffffffa0000095
[   22.250528]  ? stack_trace_save+0x9/0xd0
[   22.251757]  ? ring_buffer_unlock_commit+0x11d/0x5c0
[   22.253152]  stack_trace_save+0x9/0xd0
[   22.254264]  kasan_save_stack+0x30/0x50
[   22.273631]  kasan_save_track+0x14/0x30
[   22.276763]  kasan_save_free_info+0x3b/0x70
[   22.278296]  __kasan_slab_free+0x43/0x70
[   22.280157]  kmem_cache_free+0xbf/0x3b0
[   22.282963]  ? ftrace_stub_direct_tramp+0x10/0x10
[   22.284001]  free_task+0xa2/0x160
[   22.285699]  ? ftrace_stub_direct_tramp+0x10/0x10
[   22.286752]  copy_process+0x2aae/0x7bc0

Initialize the child function graph state immediately after
dup_task_struct(), before the first fallible operation.

Cc: stable@vger.kernel.org
Fixes: 6b1c66c9cc ("exec_state: relocate dumpable information")
Reviewed-by: Bradley Morgan <include@grrlz.net>
Link: https://patch.msgid.link/20260822195321.962383-2-Jeremy.Jean@oss.cyber.gouv.fr
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 13:33:54 -04:00
Henry Martin
2deb753127 tracing/user_events: Don't destroy fields when event removal fails
destroy_user_event() destroys the event's fields before attempting to
remove the trace event call. If user_event_set_call_visible() fails,
e.g. because the event is still enabled and trace_remove_event_call()
returns -EBUSY, the event is left registered with an irreversibly
destroyed field list. Any subsequent interaction with the event then
operates on an empty field list while it is still fully visible in
tracefs.

Move the field destruction after the call removal, and splice the
field list back onto the event when the removal fails so the event
remains in a consistent state.

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260904115223.2976446-1-bsdhenrymartin@gmail.com
Fixes: 7f5a08c79d ("user_events: Add minimal support for trace_event into ftrace")
Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
Reviewed-by: Beau Belgrave <beaub@linux.microsoft.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-11 13:30:15 -04:00
Lyude Paul
bbb9293c9b drm/nouveau/gsp: Increase delay for magic sleep in r535_gsp_fini()
As it turns out, Turing isn't the only architecture that needs this. On
this Dell Precision 7780 with an AD103 GPU, along with pretty much every
other laptop I tested, runtime PM is still somewhat unreliable. At first
glance it seems as if it's fixed, but lowering the autosuspend delay to
500ms and then doing a stress test of suspend/resume cycles on the GPU ends
up causing everything to start timing out.

After quite a lot of digging, I eventually landed back on this magic
timeout in r535_gsp_fini(). As it turns out, increasing the timeout ends up
fixing the runtime PM issues as far as I can tell, even during intense
stress testing.

Unfortunately after spending quite a bit of time trying to dig through
OpenRM to figure out what this magic sleep is actually doing, I've also
come up short with any reasonable explanation. In lieu of that, I'm going
to include the observations I did make while trying to figure this out in
hopes someone eventually does figure this out:

* The magic sleep has to occur after fbsr is initialized. Performing it at
  any time before that doesn't appear to work.
* In situations where runtime PM starts getting flaky, some rather
  interesting visual effects end up happening on occasion before the GPU
  fully falls over. In particular, squares that look like the result of an
  incomplete blitting operation to a tiled buffer end up showing up on
  applications like vkcube. Interestingly enough, they remain in precisely
  the same place between runtime PM cycles until the GPU falls over - even
  when restarting vkcube multiple times, and even when vkcube is actively
  updating the screen. Even more interestingly, they're not limited to a
  specific framebuffer - you can see the squares changing as the cube
  rotates around.
  We cannot however, say that this is likely to be a incomplete fbsr
  operation. The magic sleep happens before fbsr is actually saved (which
  happens on the GSP unload), so it's something else.
* During a short bit of testing with a desktop that I have, the magic sleep
  seemed to make no difference to whether or not suspend/resume works. It
  seems to generally work almost always. So we can assume this is likely
  exclusive to runtime PM, not S3.

As well, here's a list of the things I tried before settling on the magic
sleep:

* Hooking up NV2080_CTRL_CMD_INTERNAL_GCX_ENTRY_PREREQUISITE and then
  blocking runtime PM until OpenRM signals that GC6/GCOFF is ready appears
  to make no difference.
* Hooking up some (maybe not all, unsure about that part) bits of comptag
  saving including:
  * Fetching static memsys information from GSP
  * Adding the size of the comptag storage to the fbsr data
  * Adding a GA103+ workaround for disabling raw compression mode during
    fbsr (it doesn't seem like it applies for any systems I tried it on
    anyhow)
  * Setting bPreserveVideoMemoryAllocations=1 in GspSystemInfo

So, until we can figure this out properly - just sleep for longer.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 53dac06238 ("drm/nouveau/gsp: add support for 570.144")
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-5-lyude@redhat.com
(cherry picked from commit 09b47186a4)
Signed-off-by: Lyude Paul <lyude@redhat.com>
2026-09-11 13:26:18 -04:00
Lyude Paul
24fbd6d4bc drm/nouveau/gsp/r570: Enable S/R Display workaround in GSP
There's two flags that we've never been setting when asking GSP to suspend
the GPU, which OpenRM does set:

  GPU_STATE_FLAGS_PRESERVING
  GPU_STATE_FLAGS_PM_TRANSITION

These flags aren't -supposed- to do much in GSP, they're mostly used by
OpenRM itself for state tracking. The only thing they do from GSP's side is
control whether or not a single display related workaround is applied
during suspend.

But as it turns out, that single workaround is actually quite crucial for
getting runtime PM working with nouveau - and without it set we end up
seeing a lot more failures with runtime PM resume. So, let's start setting
it.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 53dac06238 ("drm/nouveau/gsp: add support for 570.144")
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-4-lyude@redhat.com
(cherry picked from commit ca57629b3e)
Signed-off-by: Lyude Paul <lyude@redhat.com>
2026-09-11 13:26:03 -04:00
Lyude Paul
12f6eff11c drm/nouveau/gsp/r570: Set GcOff = 0 in fbsr
Previously, it looked as if we were able to fix suspend/resume on some
desktops by setting Gcoff based on whether or not we were entering runtime
PM. This was a mistake though - the only time suspend/resume would end up
actually working was if Gcoff = 0.

It seems like it's likely the main reason for this is the FBSR GcOff
argument actually controls GSP's behavior with regards to which buffers it
decides to save across suspend/resume. When GcOff = 1, RM reserved regions
are saved unless they are marked as LOST_ON_SUSPEND, and RM channel-context
and kernel-client buffers are also saved -including- when they are
LOST_ON_SUSPEND. This means with GcOff = 1, we end up having GSP save and
restore buffers that actually need to be reinitialized on resume - causing
the failures we're setting.

Thanks to John Hubbard from Nvidia for providing some background on what
these options do in the GSP firmware do!

Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 53dac06238 ("drm/nouveau/gsp: add support for 570.144")
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-3-lyude@redhat.com
(cherry picked from commit c7abe771e0)
Signed-off-by: Lyude Paul <lyude@redhat.com>
2026-09-11 13:25:47 -04:00
Lyude Paul
a5c41fa7f9 Revert "nouveau/gsp: fix suspend/resume regression on r570 firmware"
This reverts commit 8302d0afea.

It turns out this looked like the right fix on some systems, but it's not -
as this causes runtime PM to actually fail on many a laptop.

Fixes: 8302d0afea ("nouveau/gsp: fix suspend/resume regression on r570 firmware")
Cc: <stable@vger.kernel.org> # v6.19+
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-2-lyude@redhat.com
(cherry picked from commit 94097122bf)
Signed-off-by: Lyude Paul <lyude@redhat.com>
2026-09-11 13:25:34 -04:00
Linus Torvalds
576da3462c sound fixes for 7.3-rc3
A collection of device-specific small fixes.  At this time, the
 majority of changes are about ASoC while we have usual suspects like
 HD- and USB-audio quirks.  Some highlights below.
 
 ASoC Intel / SoundWire:
 - Fix bus and stream resource leaks at error path in avs and hda-ext
 - More fixes and refactoring in avs for constraining MSBs, async
   handling d0ix
 - Add support for TAC5xx2 SoundWire family and NVL MAX98360A RT5682
   machines
 - Fix uninitialized stream configurations in Realtek SoundWire codecs
 - Adjust latency control to fix no-sound issue on RT721-SDCA
 
 ASoC AMD:
 - Avoid binding for the acp-da7219-max98357a machine driver
 - Add quirks for Acer Nitro AN17-41 and HP 255R G10
 - Fix memory leaks in ACP6x
 
 ASoC Codecs & Platforms:
 - Fixes for cs35l56 to avoid deadlock, kexec race, and runtime PM
   imbalances
 - Split stereo streams across mono amps on tas2783-sdw
 - Fix pop noise on es8326 and enable_count underflow on es8389
 - Various fixes for fsl_micfil, sprd, sti, and publish OF module
   aliases
 - Fixes & cleanups for Ux500 (MSP/I2S) and AB8500 codecs
 
 HD-audio:
 - Fix for channel status notification changes
 - Quirks for HP laptops
 
 USB-audio:
 - Fix embedded URBs in caiaq, 6fire, hiface, and ua101 drivers
 - More hardening in usx2y and us122l drivers
 - Quirks for Behringer devices
 
 Misc:
 - Add PCI ID for RME HDSPe AIO PCI Express audio card in hdspm
 - Fix S/PDIF passthrough on CA20K2 in ctxfi
 -----BEGIN PGP SIGNATURE-----
 
 iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmqj+8AOHHRpd2FpQHN1
 c2UuZGUACgkQLtJE4w1nLE+7Uw//TSbvionNeY4KPciLwDvscEbwWUYLVIJOQ6zp
 UMKKIANtZRMay98CK29fijqM5DnVOZy3n4D62s7ZD9jRxoIYbCVGtHA1akAjxjB6
 q+xq/8V9EjGcJpCOR81Umlk54NlhclG/CTMpskyjqkgHe/hAxTaTs+AuqT99HPDe
 MmcCkMdWq/3KSHi4zpOLoBys6/G+yOkd3/CiklZDRAKMMxvd2BNfWYpus3pVw4j9
 D9Q1HryV7dwBRnodRuCf8EUWWjv63+v1arzyRH82s5HUlLkssr1LwTPqVOKtSbNt
 nNwMw2Lv9wX8i6BhlJb8piFFomqJGYVpk1fpTDcAaq4Yc4j8xRidNHTZZvuhGYl0
 R9wdYgFIAyYdMfW09TteOIHEFYPRDcXmD5i7efqc3w1h/epBNwJWlF0xGRZUDPi1
 7pNIQqUmHgzpAKBtfS/Q+HyCJ/+3xgJXM3Fl9o0mdOAvwk6SYfQh9sm+lSrxyM7R
 cdGbyJFog2QKxXxQtMuvGNNKKNVRbbZjB+NsASkky8bCzcUcTxSEWlg3lXHHT3Pl
 HKunHzAXxBpMaa1PZPtucq5TZgR/CJ2PkVPpz+8L0myK86KXBM2vqQgkvmDXzfXD
 DqDa3yhVvKRLjpmixrexKwdppHMvyrdnmwtFVUqCZn4omMCD+wGYD31lPROQt4gF
 kkf04XU=
 =ihAY
 -----END PGP SIGNATURE-----

Merge tag 'sound-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "A collection of device-specific small fixes. At this time, the
  majority of changes are about ASoC while we have usual suspects like
  HD- and USB-audio quirks. Some highlights below.

  ASoC Intel / SoundWire:
   - Fix bus and stream resource leaks at error path in avs and hda-ext
   - More fixes and refactoring in avs for constraining MSBs, async
     handling D0ix
   - Add support for TAC5xx2 SoundWire family and NVL MAX98360A RT5682
     machines
   - Fix uninitialized stream configurations in Realtek SoundWire codecs
   - Adjust latency control to fix no-sound issue on RT721-SDCA

  ASoC AMD:
   - Avoid binding for the acp-da7219-max98357a machine driver
   - Add quirks for Acer Nitro AN17-41 and HP 255R G10
   - Fix memory leaks in ACP6x

  ASoC Codecs & Platforms:
   - Fixes for cs35l56 to avoid deadlock, kexec race, and runtime PM
     imbalances
   - Split stereo streams across mono amps on tas2783-sdw
   - Fix pop noise on es8326 and enable_count underflow on es8389
   - Various fixes for fsl_micfil, sprd, sti, and publish OF module
     aliases
   - Fixes & cleanups for Ux500 (MSP/I2S) and AB8500 codecs

  HD-audio:
   - Fix for channel status notification changes
   - Quirks for HP laptops

  USB-audio:
   - Fix embedded URBs in caiaq, 6fire, hiface, and ua101 drivers
   - More hardening in usx2y and us122l drivers
   - Quirks for Behringer devices

  Misc:
   - Add PCI ID for RME HDSPe AIO PCI Express audio card in hdspm
   - Fix S/PDIF passthrough on CA20K2 in ctxfi"

* tag 'sound-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (65 commits)
  ALSA: hdspm: Add a new PCI device ID (1d18:3fc6) for RME HDSPe AIO PCI express audio
  ASoC: amd: acp-da7219-max98357a: don't bind on Raven/Picasso boards
  ALSA: hda: Report a change when only the channel status bytes move
  ALSA: us122l: Prevent write upgrades for read mappings
  ALSA: hda/realtek: Add quirk for HP Elite Dragonfly Max G2 speaker
  ASoC: cs35l56: Fix race between kexec and snd_soc_register_component()
  ASoC: amd: yc: add quirk for Acer Nitro AN17-41 internal mic
  ASoC: mt6351: Publish the OF module alias
  ASoC: Intel: SST: Publish the PCI module aliases
  ASoC: bcm: bcm63xx: Publish the OF module aliases
  ALSA: usb-audio: Add quirk flags for Behringer UV1
  ALSA: usb-audio: Add boot quirk for Behringer CM1A
  ALSA: hda/realtek: Add quirk for HP Omen 16-wd0xxx mute LED
  ALSA: usbusx2y: validate URB actual_length in interrupt callback
  ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf
  ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough
  ALSA: usb: 6fire: Avoid embedded URBs
  ALSA: usb: hiface: Avoid embedded URBs
  ALSA: usb: ua101: Avoid embedded URBs
  ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev
  ...
2026-09-11 10:00:07 -07:00
Oscar Priego Verdugo
8e2a4b458a HID: elecom: fix bus type for M-XGL20DLBK
The M-XGL20DLBK is matched as a USB device by hid-elecom, but
its entry in hid_have_special_driver[] uses HID_BLUETOOTH_DEVICE.

This prevents the special-driver quirk entry from matching the USB
device handled by hid-elecom. Use HID_USB_DEVICE there as well.

Fixes: 55633e681a ("HID: elecom: add support for EX-G M-XGL20DLBK wireless mouse")
Signed-off-by: Oscar Priego Verdugo <oscar.priegov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-09-11 18:54:41 +02:00
Linus Torvalds
d5d6c9d244 [GIT PULL for v7.3-rc3] media fixes
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEE+QmuaPwR3wnBdVwACF8+vY7k4RUFAmqjsQQACgkQCF8+vY7k
 4RWqTw//RU28fKAPnaD/ZoVy1Mz3RquqCikj/TLp6a8xLNcSrjPs9GdwdQub+zDe
 EG6H4LQ5YUvNiRnFDxmleWJcJdE1mns8Tj5hXKGeQpwsMYj7aFbQVHLo4DbwtX6b
 EdWPs47iFzcKx3K56580MRWUa4ai9Or0xk/6NhlnSBuOMQ4Ir7+FX7qaetHipHmR
 LYivhgDLhbTuRtTvDo9ZOFinA6g1Bjc+2T0TXCvhEpCOf+g21QM/nv2BAL8eQeeS
 yGJU0XxENFPSu1fDV8g+ZfWVN0LSzyYGZtP35xkRwBLJSu/7VbQT2skAA6U/yZp8
 xeiQuKfDYnpJJNSlsEX+gZzHx8etXSThUo7A7u4EmmxE1XR33FmgvauxyxYudHgv
 0Sew85Ghli4hWUo2HcsryLJzrJpiX0SWst/UWnOttydgm/DOJytZYTLfmruzOiXi
 UPjojwBewPYHdJFRnsVj1qlAW1v2rwVjvAreE1jGM7i1/XtRIuGylFyTaYRWUmaU
 LAtsjeNzjSucHnbg9rM0VMv/1uESJrAzuu6WT+zI87Z6EtXnlkHlXopsJOfLLwj2
 tJPgFuPWOMOm8k9pWLgbADB2uPbQj33+Vftki/iAEjolfpdl1KgSZy5Nx0IoHYLI
 pmTy1O4QNq434b5s9mkONt9HQVBjoISrECGC8jacRij0Ad+vdbY=
 =appY
 -----END PGP SIGNATURE-----

Merge tag 'media/v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

Pull media fixes from Mauro Carvalho Chehab:
 "Core:
   - add bounded tile-count helpers for HEVC stateless decoders
   - validate AV1 tile counts fits in array size
   - validate HEVC tile counts fits in array size
   - fix memcmp() size in B1 reference list comparison

  mediatek:
   - bound AV1 tile-start copy to fit in array size

  rockchip:
   - reject AV1 frames exceeding the tile size
   - guard VPU981 AV1 divisor and tile buffer

  hantro and rkvdec:
    - bound G2 HEVC tile loops and PPS id to the buffer size

  rppx1:
   - read the raw pattern from the PRE2 acquisition module
   - describe the MAIN_POST white balance gains block"

* tag 'media/v7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  media: mediatek: vcodec: bound AV1 tile-start copy to the array capacity
  media: verisilicon: rockchip: reject AV1 frames exceeding the tile capacity
  media: verisilicon: rockchip: guard VPU981 AV1 divisor and tile buffer
  media: verisilicon: hantro: bound G2 HEVC tile loop to the buffer capacity
  media: rkvdec: bound HEVC tile loops and PPS id to the array capacity
  media: hevc: add bounded tile-count helpers
  media: v4l2-ctrls: validate AV1 tile counts
  media: v4l2-ctrls: validate HEVC tile counts
  media: v4l2-h264: Fix memcmp() size in B1 reference list comparison
  media: rppx1: bls: read the raw pattern from the PRE2 acquisition module
  media: rppx1: describe the MAIN_POST white balance gains block
2026-09-11 09:49:40 -07:00
Berke Durak
f3c2b266b8 HID: elecom: Add support for ELECOM M-XT4DRBK (018E)
The 2025 revision of the left-handed EX-G wireless trackball
(M-XT4DRBK-G) reports USB ID 056e:018e instead of 056e:00fd. Its report
descriptor declares an 8-bit button field (Report Count 8) but only five
usages (Usage Maximum 5), so the sixth (Fn) button ends up as a
duplicate of button 5 and is unusable.

The report descriptor has the same layout as the M-XT3DRBK 018C
(button usage maximum at offset 16, button report count at 22, button
report size at 24, padding report size at 30), so reuse that fixup.

Rename the existing M_XT4DRBK define to M_XT4DRBK_00FD to match the
convention used for the other EX-G revisions.

Tested on a Raspberry Pi 5 with the same fixup in an
out-of-tree module on 6.12 (6.12.96+rpt-rpi-2712);
all six buttons are reported after the fix, and they
work (tested with xev as well).

Report descriptor as sent by the device, pre-fix (056e:018e,
215 bytes):

 05 01 09 02 A1 01 09 01 A1 00 85 01 05 09 19 01
 29 05 15 00 25 01 95 08 75 01 81 02 95 01 75 00
 81 01 05 01 09 30 09 31 16 00 80 26 FF 7F 75 10
 95 02 81 06 C0 A1 00 05 01 09 38 15 81 25 7F 75
 08 95 01 81 06 C0 A1 00 05 0C 0A 38 02 95 01 75
 08 15 81 25 7F 81 06 C0 C0 06 01 FF 09 00 A1 01
 85 02 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0
 05 0C 09 01 A1 01 85 05 15 00 26 3C 02 19 00 2A
 3C 02 75 10 95 01 81 00 C0 05 01 09 80 A1 01 85
 03 19 81 29 83 15 00 25 01 95 03 75 01 81 02 95
 01 75 05 81 01 C0 06 BC FF 09 88 A1 01 85 04 95
 01 75 08 15 00 26 FF 00 19 00 2A FF 00 81 00 C0
 06 02 FF 09 02 A1 01 85 06 09 02 15 00 26 FF 00
 75 08 95 07 B1 02 C0

Assisted-by: LLM
Signed-off-by: Berke Durak <berke.durak@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-09-11 18:30:29 +02:00
Stuart Hayhurst
1d00442cc4 HID: corsair-void: Fix firmware event packet description
The size was incorrectly stated as 4 bytes since the ID was missed out.
Add the ID in and correct the indices for the firmware versions.

Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-09-11 18:22:54 +02:00
Youth Cao
58d97b45f3 HID: i2c-hid: Add i2c-hid-quirk-bad-input-size quirk for 0911:5288 device
I have recently acquired a cheap Apollo Lake-based laptop that uses a
Hynitron CST128-A touchpad controller. While booting from a Debian LiveCD,
the kernel log is flooded with the following error (though the touchpad
works well):

  i2c_hid_acpi i2c-ALPS0001:00: i2c_hid_get_input: incomplete report (27/42405)

The CST128-A was identified via ACPI as ALPS0001:00, and the I2C HID
device ID (0911:5288) was shared with the Hantick 5288.

Add the I2C_HID_QUIRK_BAD_INPUT_SIZE quirk option to the existing Hantick
5288 quirk entry to suppress the kernel log flood.

Signed-off-by: Youth Cao <cocoh2os08@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-09-11 18:04:19 +02:00
Tristan Madani
abd24922c2 HID: hid-oxp: use cancel_delayed_work_sync() in remove
oxp_hid_remove() uses cancel_delayed_work() for all three delayed work
items.  cancel_delayed_work() only dequeues a pending work item without
waiting for a currently executing callback to finish.  If any of the
work callbacks (oxp_rgb_queue_fn, oxp_btn_queue_fn, oxp_mcu_init_fn) is
running at the time of removal, the callback continues executing
concurrently with hid_hw_close() and hid_hw_stop(), accessing the HID
device after it has been closed and stopped.

Use cancel_delayed_work_sync() instead to ensure that any in-progress
work callback completes before device teardown proceeds.

Fixes: 84910c459d ("HID: hid-oxp: Add OneXPlayer configuration driver")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>
Link: https://lore.kernel.org/r/20260804-oxp-fix-v2-1-b2d56e4c8a2c@cherr.cc
Link: https://lore.kernel.org/r/20260804-oxp-fix-v1-1-51a4fe787167@cherr.cc
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-09-11 17:45:43 +02:00