drm_pagemap_evict_to_ram() may retry eviction, but mpages retains
the count from the previous attempt. A retry can therefore continue
to the copy path even when no RAM pages were populated.
Reset mpages at the retry label so it reflects only the current
attempt.
Fixes: 99624bdff8 ("drm/gpusvm: Add support for GPU Shared Virtual Memory")
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260728090304.1264759-1-arvind.yadav@intel.com
A device-private folio migrated to system memory by a CPU fault can
remain reachable through the raw-PFN eviction path until migration
finalization drops the source reference.
If eviction selects the same device-private folio during this window,
it can attempt to migrate the folio again. The second migration can leave
an uncharged folio on an LRU list, causing folio_lruvec_lock_irqsave() to
retry indefinitely and resulting in a soft lockup and RCU stall.
Mark successfully migrated device-private folios using a low bit of
their zone_device_data before migration finalization. Make both CPU-fault
and raw-PFN migration paths skip device-private folios carrying this
flag.
Mask the flag when retrieving the drm_pagemap_zdd pointer and preserve
it when a device-private folio is split. Keeping the state on the physical
folio also avoids depending on a virtual address that may change before a
fault occurs.
v2:
- Replace the retired-PFN XArray with an embedded bitmap. (Matthew Brost)
- Mark every base page covered by a migrated folio so retirement remains
valid if the folio is later split.
v3:
- Store the migrated state in a low bit of zone_device_data instead of
adding virtual-range and bitmap tracking to the ZDD. (Matthew Brost)
- Mask the flag when retrieving the ZDD and preserve it when splitting
a folio.
- Drop the pre-existing fixes already covered by Matthew Brost's series:
https://patchwork.freedesktop.org/series/171651/
v4:
- Advance by the folio size only for migration entries marked with
MIGRATE_PFN_COMPOUND. (Sashiko)
v5:
- Simplify ZDD flag updates and folio iteration. (Matthew Brost)
- Skip retired device-private folios in the CPU-fault path. (Matthew Brost)
- Preserve flag bits while taking a new ZDD reference for split folios.
v6:
- Restore MIGRATE_PFN_COMPOUND-aware stepping so non-compound migration
entries are processed one at a time. (Sashiko)
- Drop the pre-existing fixes already covered by Matthew Brost's series:
https://patchwork.freedesktop.org/series/171651/
The lockup was observed as:
[10109.860465] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [kworker/u65:5:6557]
[10109.860524] Tainted: [S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE
[10109.860524] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023
[10109.860525] Workqueue: xe_page_fault_work_queue xe_pagefault_queue_work [xe]
[10109.860644] RIP: 0010:_raw_spin_unlock_irqrestore+0x57/0x80
[10109.860655] Call Trace:
[10109.860655] <TASK>
[10109.860657] folio_lruvec_lock_irqsave+0x216/0x220
[10109.860661] ? __pfx_lru_add+0x10/0x10
[10109.860665] folio_batch_move_lru+0xc8/0x450
[10109.860670] ? lock_acquire+0xc4/0x2d0
[10109.860674] ? __folio_batch_add_and_move+0x60/0x2e0
[10109.860677] ? folio_migrate_mapping+0xa6/0x110
[10109.860679] ? folio_migrate_flags+0x13b/0x1b0
[10109.860681] ? __pfx_lru_add+0x10/0x10
[10109.860683] __folio_batch_add_and_move+0xe7/0x2e0
[10109.860685] ? dma_iova_try_alloc+0xb0/0x140
[10109.860689] folio_add_lru+0x64/0x80
[10109.860691] __migrate_device_finalize+0x12c/0x270
[10109.860695] migrate_device_finalize+0x10/0x20
[10109.860698] drm_pagemap_evict_to_ram+0x185/0x370 [drm_gpusvm_helper]
[10109.860704] ? drm_pagemap_evict_to_ram+0x96/0x370 [drm_gpusvm_helper]
[10109.860709] xe_svm_bo_evict+0x15/0x20 [xe]
[10109.860819] ? xe_svm_bo_evict+0x15/0x20 [xe]
[10109.860921] xe_bo_move+0x107e/0x1570 [xe]
[10109.860992] ? xe_ttm_tt_create+0x168/0x340 [xe]
[10109.861059] ? __up_read+0x98/0x2b0
[10109.861061] ? lock_is_held_type+0xa3/0x130
[10109.861067] ttm_bo_handle_move_mem+0xe8/0x1e0 [ttm]
[10109.861075] ttm_bo_evict+0x141/0x1c0 [ttm]
[10109.861081] ttm_bo_evict_cb+0x9f/0x100 [ttm]
[10109.861086] ttm_lru_walk_for_evict+0x84/0x190 [ttm]
[10109.861091] ? xe_ttm_vram_mgr_new+0x258/0x3a0 [xe]
[10109.861198] ttm_bo_alloc_resource+0x219/0x750 [ttm]
[10109.861203] ? ttm_bo_alloc_resource+0xa9/0x750 [ttm]
[10109.861208] ? lock_acquire+0xc4/0x2d0
[10109.861214] ttm_bo_validate+0x94/0x1c0 [ttm]
[10109.861218] ? ww_mutex_trylock+0x19d/0x3d0
[10109.861219] ? _raw_write_unlock+0x22/0x50
[10109.861223] ttm_bo_init_reserved+0x17d/0x1f0 [ttm]
[10109.861228] xe_bo_init_locked+0x20a/0x620 [xe]
[10109.861294] ? __pfx_xe_ttm_bo_destroy+0x10/0x10 [xe]
[10109.861359] ? mark_held_locks+0x46/0x90
[10109.861361] ? __create_object+0x68/0xc0
[10109.861366] __xe_bo_create_locked+0x384/0xa20 [xe]
[10109.861432] ? lock_acquire+0xc4/0x2d0
[10109.861434] ? xe_drm_pagemap_populate_mm+0xd3/0x340 [xe]
[10109.861542] xe_bo_create_locked+0x23/0x40 [xe]
[10109.861609] xe_drm_pagemap_populate_mm+0x12e/0x340 [xe]
[10109.861707] ? __lock_acquire+0x43e/0x2930
[10109.861716] drm_pagemap_populate_mm+0x74/0xe0 [drm_gpusvm_helper]
[10109.861720] xe_svm_alloc_vram+0xb5/0x2c0 [xe]
[10109.861817] ? seqcount_lockdep_reader_access.constprop.0+0x9f/0xc0
[10109.861819] ? ktime_get+0x23/0x130
[10109.861821] ? trace_hardirqs_on+0x22/0xe0
[10109.861823] ? seqcount_lockdep_reader_access.constprop.0+0x9f/0xc0
[10109.861826] __xe_svm_handle_pagefault+0x77d/0xbf0 [xe]
[10109.861924] ? rwsem_down_write_slowpath+0x43a/0x9a0
[10109.861926] ? _raw_spin_unlock_irq+0x27/0x70
[10109.861928] ? rwsem_down_write_slowpath+0x43a/0x9a0
[10109.861929] ? trace_hardirqs_on+0x22/0xe0
[10109.861931] ? _raw_spin_unlock_irq+0x27/0x70
[10109.861933] ? rwsem_down_write_slowpath+0x459/0x9a0
[10109.861937] xe_svm_handle_pagefault+0x3d/0xb0 [xe]
[10109.862030] xe_pagefault_queue_work+0x1a9/0x520 [xe]
[10109.862122] process_one_work+0x239/0x730
[10109.862127] worker_thread+0x200/0x3f0
[10109.862130] ? __pfx_worker_thread+0x10/0x10
[10109.862132] kthread+0x10d/0x150
[10109.862133] ? __pfx_kthread+0x10/0x10
[10109.862135] ret_from_fork+0x3bd/0x470
[10109.862138] ? __pfx_kthread+0x10/0x10
[10109.862140] ret_from_fork_asm+0x1a/0x30
[10109.862146] </TASK>
Fixes: 99624bdff8 ("drm/gpusvm: Add support for GPU Shared Virtual Memory")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Assisted-by: Claude:claude-opus-4-8
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260810092845.2776097-1-arvind.yadav@intel.com
- drop Excess description of @lock from kernel-doc
- add missing function/macro short descriptions
WARNING: include/linux/dma-fence-array.h:47 Excess struct member 'lock' description in 'dma_fence_array'
WARNING: include/linux/dma-fence-chain.h:48 Excess struct member 'lock' description in 'dma_fence_chain'
Warning: include/linux/dma-fence-chain.h:82 missing initial short description on line:
* dma_fence_chain_alloc
Warning: include/linux/dma-fence-chain.h:94 missing initial short description on line:
* dma_fence_chain_free
Fixes: 5943243914 ("dma-buf: use inline lock for the dma-fence-array")
Fixes: a408c0ca0c ("dma-buf: use inline lock for the dma-fence-chain")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260831031956.3410813-1-rdunlap@infradead.org
The default programming in the driver matches the "coverage" blend mode,
so add the corresponding pixel blend mode property to let userspace know
about it.
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260826105421.1825331-1-thierry.reding@kernel.org
ethosu_ioctl_submit_job() allocates done_fence before validating buffer
handles. Errors after allocation call ethosu_job_err_cleanup(), which frees
the job but leaks the uninitialized fence.
A scheduler dependency error also lets ethosu_job_run() return before
dma_fence_init(). Normal cleanup then passes a zeroed refcount to
dma_fence_put().
Release done_fence in the common cleanup path and use
dma_fence_was_initialized() to distinguish initialized fences from raw
allocations.
Fixes: 5a5e9c0228 ("accel: Add Arm Ethos-U NPU driver")
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260716065219.931088-1-zhaoguohan@kylinos.cn?part=1
Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn>
Link: https://patch.msgid.link/20260717061145.1478139-6-zhaoguohan@kylinos.cn
[robh: also fix goto]
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Commit 1c6ceeee6e ("drm/atomic: Fix memleak on ERESTARTSYS during
non-blocking commits") fixed a very similar issue when the event was
allocated by drm_atomic_helper_setup_commit() itself.
However, if the event is allocated in prepare_signaling(), it will also be
set to NULL in complete_signaling(), which prevents drm_crtc_commit from
being put in __drm_atomic_helper_crtc_destroy_state().
Dropping the reference when the event is set to NULL at
complete_signaling() fixes the leak.
The leak can be reproduced by sending a signal to the thread using
DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic
ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both
with amdgpu and vkms.
Fixes: 24835e442f ("drm: reference count event->completion")
Cc: stable@vger.kernel.org
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Reviewed-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
Link: https://patch.msgid.link/20260727-drm_crtc_atomic_commit_leak-v1-1-23d9948a9d7c@igalia.com
Since file_priv can never be NULL at prepare_signaling() as it is only
called by drm_mode_atomic_ioctl(), remove the check.
If that was not the case, skipping the rest of the block here would cause
the drm_pending_vblank_event object to leak and fail to set up the fence in
case out_fence_ptr is set.
Since the check is unreachable, there is no possible leak.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Reviewed-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
Link: https://patch.msgid.link/20260817-drm_atomic_bogus_check-v2-1-2b9e60f32a7e@igalia.com
The `cirrus-qemu` driver relies on `CIRRUS_VRAM_SIZE` (4 MB) to validate
framebuffer sizes. However, during PCI probe, the driver mapped BAR0
without verifying that its size matches `CIRRUS_VRAM_SIZE`.
If a PCI device with a BAR0 smaller than 4 MB is bound to the driver, the
mapped VRAM will be smaller than expected. Because validation checks assume
4 MB VRAM, framebuffers larger than the mapped memory can be created.
When the display plane is updated (e.g. during release),
`cirrus_primary_plane_helper_atomic_update()` copies the framebuffer to
VRAM using `drm_fb_memcpy()`. Writing past the end of the mapped I/O memory
causes a supervisor write page fault:
BUG: unable to handle page fault for address: ffffc9000389c000
...
RIP: 0010:memcpy_toio+0x7c/0xe0 arch/x86/lib/iomem.c:110
...
Call Trace:
<TASK>
iosys_map_memcpy_to include/linux/iosys-map.h:285 [inline]
drm_fb_memcpy+0x325/0x5d0 drivers/gpu/drm/drm_format_helper.c:442
cirrus_primary_plane_helper_atomic_update+0x98a/0xb00
drivers/gpu/drm/tiny/cirrus-qemu.c:358
drm_atomic_helper_commit_planes+0x626/0xea0
drivers/gpu/drm/drm_atomic_helper.c:3038
drm_atomic_helper_commit_tail+0x60/0x510
drivers/gpu/drm/drm_atomic_helper.c:1989
commit_tail+0x2b1/0x3c0 drivers/gpu/drm/drm_atomic_helper.c:2074
drm_atomic_helper_commit+0xa77/0xb10
drivers/gpu/drm/drm_atomic_helper.c:2312
Fix this by validating in `cirrus_pci_probe()` that the PCI BAR0 resource
is not less than `CIRRUS_VRAM_SIZE`, returning `-ENODEV` if it is less.
Fixes: ab3e023b1b ("drm/cirrus: rewrite and modernize driver.")
Assisted-by: Gemini:gemini-3.6-flash Gemini:gemini-3.1-pro-preview syzbot
Reported-by: syzbot+2442951a6abb004df963@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=2442951a6abb004df963
Link: https://syzkaller.appspot.com/ai_job?id=ba262a3a-bccf-4ad8-a1b0-583c55d34fd6
Signed-off-by: Slawomir Stepien <sst@poczta.fm>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260825120729.493611-1-sst@poczta.fm
The is_avivo() function has a logic error where it compares a constant
to another constant instead of checking the device parameter:
(PCI_VENDOR_ID_ATI_R600 >= 0x9400)
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: f496834e16 ("drm/ofdrm: Add per-model device function")
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: <stable@vger.kernel.org> # v6.2+
Link: https://patch.msgid.link/20260731111729.703116-1-oushixiong1025@163.com
The framebuffer size calculation `fb_size = linebytes * height` can
overflow when both values are large (e.g., 46341 * 46341 > INT_MAX).
Since linebytes and height are both int types, the multiplication is
performed as int * int, which results in undefined behavior on overflow.
Use check_mul_overflow() to detect and prevent this overflow, consistent
with the approach used in simpledrm.c and corebootdrm.c.
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: c8a17756c4 ("drm/ofdrm: Add ofdrm for Open Firmware framebuffers")
Cc: <stable@vger.kernel.org> # v6.2+
Link: https://patch.msgid.link/20260825104134.669676-1-oushixiong1025@163.com
The GSP path programs per-head timing (vblank) interrupts the same way on
every generation. NVD5.0 (GB20x) reworked the FE interrupt frontend
around four message-based kernel vectors (high latency, low latency, PMU,
and GSP) and moved RM head-timing interrupts to the dedicated low-latency
vector:
- The enable is NV_PDISP_FE_RM_INTR_EN1_HEAD_TIMING, 0x611ef0 +
head*4 (570.144 kernel_head_0501.c, renamed kernel_head_0502.c from
575.51.02 on, and v05_01 dev_disp.h).
- The vector is reported as a separate interrupt table entry,
MC_ENGINE_IDX_DISP_LOW (intr_gb202.c, intrCacheDispIntrVectors).
- The vector must be re-armed through NV_PDISP_FE_INTR_RETRIGGER(1)
at 0x611f34 after servicing (kdispServiceInterrupt ->
kdispIntrRetrigger_v05_01).
The event latch (0x611800), per-head status (0x611c00), and dispatch
summary (0x611ec0) the interrupt handler uses are unchanged on GB20x
(kheadReadPendingVblank_v03_00 and kheadResetPendingLastData_v03_00
remain for DISPv0502+).
On GB20x the old code enables head timing onto the legacy vector, leaves
its handler there, and never re-arms the message-based vectors. Page
flips still complete (nv50 sends those events from the commit path), so
the desktop looks fine while DRM vblank waits and vblank sequence queries
are affected.
Supply GB20x vblank enables and an interrupt handler that re-arms the
vector after servicing through gb202_gsp_disp, translate the low-latency
interrupt table entry as a second NVKM_ENGINE_DISP instance, and add a
gsp.intr_low_latency flag so r535_disp_oneinit() attaches the handler to
that instance. GB20x was the last cross-file user of the TU1xx vblank
enables, so make those static and drop their head.h prototypes.
Fixes: 6cc6e08d45 ("drm/nouveau/kms: add support for GB20x")
Cc: stable@vger.kernel.org
Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260825001408.14219-9-mohamedahmedegypt2001@gmail.com
The GSP path reads armed head state and the RG scanout position through
gv100_head_state() and gv100_head_rgpos() on every generation.
gv100_head_state() reads the core channel's state mirror at a 0x400
per-head stride, which NVD5.0 (GB20x) doubled. Per NVIDIA's published
CA7D class header every HEAD_SET method sits at 0x2000 + head * 0x800,
while the mirror bases are unchanged (assembly at 0x680000, armed at
+0x8000, per OpenRM's v03_00 channel-user-base HAL which is still used on
DISPv0502).
Add gb202_head_state(), the same readback at the 0x800 stride, and a
gb202_gsp_head table to supply it.
gv100_head_rgpos() is kept. The RG registers keep their per-head 0x800
stride on NVD5.0, and OpenRM's kdispReadRgLineCountAndFrameCount_v03_00
still reads NV_PDISP_RG_DPCA on DISPv0502.
Fixes: 6cc6e08d45 ("drm/nouveau/kms: add support for GB20x")
Cc: stable@vger.kernel.org
Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260825001408.14219-8-mohamedahmedegypt2001@gmail.com
NVIDIA removed the deprecated actualPclkHz/linkClkFreqHz fields and the
whole Legacy{activeCnt, activeFrac, activePolarity, mvidWarEnabled,
MvidWarParams} block from the SST sub-struct of
NV0073_CTRL_CMD_DP_CONFIG_STREAM_PARAMS between the 535 and 570 releases
(compared in OpenRM tags 535.113.01 vs 570.144), shrinking the struct.
Everything nouveau writes sits at identical offsets in both layouts
except the trailing SST.bEnableAudioOverRightPanel (written as zero), but
the size is wrong on r570, which means r535_sor_dp_sst() and
r535_sor_dp_vcpi() are sent with an incorrect size.
Route the .sst/.vcpi IOR functions through nvkm_rm_api_disp the same way
bl_ctrl and dp.get_caps/set_indexed_link_rates already are. Keep the
existing implementation for r535 and add an r570 implementation built
against the 570.144 layout, which already exists in r570/nvrm/disp.h but
was unused until now. Also add the NV0073_CTRL_CMD_DP_CONFIG_STREAM
define that was missing from the layout.
Other DP controls sent through shared r535 code did not change layout
between the tags.
Fixes: 6cc6e08d45 ("drm/nouveau/kms: add support for GB20x")
Cc: stable@vger.kernel.org
Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260825001408.14219-7-mohamedahmedegypt2001@gmail.com
The GSP path brackets audio enablement with a General Control Packet
AVMute toggle. r535_sor_hdmi_audio() calls the gsp.hdmi_gcp hook, which
every chip so far serves with tu102_sor_hdmi_gcp() and the legacy GCP
unit at 0x6f00c0/0x6f00cc. On GB20x the SF packet units were compacted
and the old generic and VSI units are gone (ACR keeps slot 2) and the
GCP unit moved from slot 3 to slot 1 (control 0x6f0040 and subpack
0x6f004c from NVIDIA's published clc971.h. The same offsets are also
used by OpenRM's hdmiWriteGeneralCtrlPacketC871() on these chips). The
old addresses are reserved on GB20x, so the AVMute writes were silent
no-ops and mitigated only by the equivalent GCP r535_sor_hdmi_audio()
already sends through the SET_OD_PACKET RM control.
Add a GB20x GCP writer using the new offsets and hook it into
gb202_gsp_disp, keeping the direct MMIO path in sync with the hardware
as on earlier chips.
Only SB0 (the AVMute bit) is written. On NVD5.0 the subpack register also
carries SB1_CTRL (bit 24), which selects where the deep-color CD/PP
fields are generated (hardware or from the driver, with the default being
HW). hdmiWriteGeneralCtrlPacketC871() likewise writes only SB0-SB2.
Fixes: 6cc6e08d45 ("drm/nouveau/kms: add support for GB20x")
Cc: stable@vger.kernel.org
Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260825001408.14219-6-mohamedahmedegypt2001@gmail.com
The GSP path reuses the GV100 direct-MMIO infoframe writers on every
chip. On GB20x that is only half right as while the legacy SF AVI unit is
unchanged, the legacy VSI unit at 0x6f0100 was removed, so
gv100_sor_hdmi_infoframe_vsi() writes into a reserved area and no vendor
infoframe ever reaches the HW. This affects HDMI-VIC signalling which
can impact some 4K modes for legacy HDMI 1.4 sinks.
GB20x (NVDisplay 5.0+) reorganised the SF HDMI packet units. Per NVIDIA's
published C971/CA71 DISP_SF_USER class headers, only three legacy units
remain (AVI at +0x000, GCP at +0x040, ACR at +0x080), and vendor
infoframes must instead be sent through the shared generic infoframe
units at +0x130, whose 9-dword packet slots are loaded through the
shared data port at +0x3f0/+0x3f4.
Add a VSI writer using the same programming sequence OpenRM uses on
these chips (nvhdmipkt_C971.c, programAdvancedInfoframeC971()): disable
the unit and wait for it to idle, clear the SENT status, write the packet
through the data port with a zero inserted in HB3 after the three header
bytes, then enable the unit for every-frame transmission during vblank.
Generic unit 1 is used for the VSI, matching the slot assignment in
NVIDIA's nvkms (NVHDMIPKT_TYPE_SHARED_GENERIC2, unit 0 is reserved
for extended metadata packets and unit 2 for the HDR DRM infoframe,
if those are wired up later).
GB20x so far shared GA10x's display entry point. Give it its own,
gb202_disp_new(), with a gb202_gsp_disp table that supplies the VSI
writer to the GSP path and otherwise carries the same hooks as GA10x.
The following fixes fill in the rest of the GB20x differences there.
Fixes: 6cc6e08d45 ("drm/nouveau/kms: add support for GB20x")
Cc: stable@vger.kernel.org
Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260825001408.14219-5-mohamedahmedegypt2001@gmail.com
The GSP-RM display code in rm/r535/disp.c borrows a few
register-programming routines from engine/disp (the head-timing
interrupt handler, vblank enables, armed head state and scanout position
readback, the AVI/VSI infoframe writers and the GCP AVMute write) and so
far picked them by name, which means it has to know which chip it runs
on the moment a generation changes any of them.
Give nvkm_disp_func a .gsp table that each chip fills with exactly those
hooks, add tu102_gsp_disp (TU1xx) and ga102_gsp_disp (GA10x onwards)
carrying the current functions, hand them to r535_disp_new() instead of
the full hardware tables, and make rm/r535/disp.c call through the
hooks. The head hooks are a whole nvkm_head_func, so r535_head goes away
and the chip's own table is handed to nvkm_head_new_(). r535_sor_hdmi
gets infoframe forwarders, r535_sor_hdmi_audio() calls the GCP hook, and
the interrupt handler comes from the table. The tables are per chip even
though the two currently coincide, so a generation that changes a hook
only touches its own file.
rm/r535/disp.c no longer contains chip-specific register code, and a new
display generation only has to provide its own table. No functional
change.
Fixes: 6cc6e08d45 ("drm/nouveau/kms: add support for GB20x")
Cc: stable@vger.kernel.org
Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260825001408.14219-4-mohamedahmedegypt2001@gmail.com
r535_sor_hdmi_audio() pairs two RM controls (a SET_OD_PACKET carrying
the same General Control Packet, and the audio mute-stream toggle)
with a direct write of the GCP AVMute bit through the SF GCP unit.
The controls are RM and stay, but the direct write is register
programming and moves next to the other per-chip display code as
tu102_sor_hdmi_gcp(). No functional change.
Fixes: 6cc6e08d45 ("drm/nouveau/kms: add support for GB20x")
Cc: stable@vger.kernel.org
Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260825001408.14219-3-mohamedahmedegypt2001@gmail.com
The GSP-RM display code in rm/r535/disp.c owns a handful of direct MMIO
routines: the head-timing (vblank) interrupt handler and the per-head
vblank enable/disable. They program display registers, not RM, so they
belong with the rest of the per-chip register code in engine/disp/.
Move them to tu102.c (Turing is the first GSP-capable generation) as
tu102_disp_intr() and tu102_head_vblank_get()/put(), exported for
rm/r535/disp.c, which keeps calling them by name for now. No functional
change.
Fixes: 6cc6e08d45 ("drm/nouveau/kms: add support for GB20x")
Cc: stable@vger.kernel.org
Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260825001408.14219-2-mohamedahmedegypt2001@gmail.com
That's right! It looks like this never actually got finished, something
which I just noticed today when I saw this fun message spamming one of my
test machine's kernel logs when enabling display debug output for nouveau:
[drm:drm_crtc_vblank_helper_get_vblank_timestamp_internal] crtc 0 : scanoutpos query failed.
So it looks like we've been falling back to DRM's core fallback for a while
now, whoops.
So, while it seems that we do have the option of doing this through GSP -
that doesn't seem like a great idea. Mainly because reading this from GSP
would involve a lot more latency then we should have for vblank handling
due to the RPC communication. So instead of implementing that, just use
gv100_head_state and gv100_head_rgpos for implementing .state and .rgpos.
It seems to work perfectly fine!
Fixes: 9e99444490 ("drm/nouveau/disp/r535: initial support")
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Timur Tabi <ttabi@nvidia.com>
Cc: Ben Skeggs <bskeggs@nvidia.com>
Cc: James Jones <jajones@nvidia.com>
Cc: Faith Ekstrand <faith.ekstrand@collabora.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Aaron Kling <webgeek1234@gmail.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Zhang Enpei <zhang.enpei@zte.com.cn>
Cc: <stable@vger.kernel.org> # v6.7+
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260429030348.3930866-1-lyude@redhat.com
(cherry picked from commit 804cb093b2)
Signed-off-by: Lyude Paul <lyude@redhat.com>
Bits 15:14 of NPU_SET_{IFM,OFM}_PRECISION select the activation storage
mode on U85 only. On U65 the same field holds the rounding mode, and the
command stream parser has read it as a storage mode since the driver was
added.
That went unnoticed while unknown values fell through the switch, but
now that they are rejected, every U65 command stream that asks for
natural rounding (2) fails CMDSTREAM_BO_CREATE with -EINVAL. Mesa emits
it for average pooling, concatenation, split, unpack, strided slice, LUT
and argmax, which is 72 failures of the Teflon test suite on an i.MX93.
Truncating rounding (1) is misread as well: it picks the two-tile
address path and computes a bogus feature map size from tile bases the
command stream never set.
Read the field as a storage mode only on the hardware where it is one.
Fixes: 5a5e9c0228 ("accel: Add Arm Ethos-U NPU driver")
Fixes: 6b7e006629 ("accel: ethosu: Handle U85 internal chaining buffer")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://patch.msgid.link/20260824152612.751007-1-tomeu@tomeuvizoso.net
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
devm_platform_ioremap_resource() returns an error pointer when the register
resource cannot be mapped. ethosu_probe() stores it and continues until
initialization dereferences it through MMIO accessors.
Return the mapping error before initializing the device.
Fixes: 5a5e9c0228 ("accel: Add Arm Ethos-U NPU driver")
Cc: stable@vger.kernel.org
Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn>
Link: https://patch.msgid.link/20260716065219.931088-1-zhaoguohan@kylinos.cn
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
amdxdna_cmd_set_error() looks up the first BO of a command chain, which
takes a reference, and drops it at the end of the function. The mapping of
that BO is established in between, and the failure path returns without the
put, so the reference is leaked.
Ordinary use does not reach it. The chain has been submitted before any of
this runs, so aie2_cmdlist_fill_slot() has already called
amdxdna_cmd_get_op() on that BO and amdxdna_gem_vmap() has cached its
address. What makes it reachable is that the BO is resolved again by
handle here, and the handle is userspace's to recycle: closing it after
submission and importing a dma-buf whose exporter implements no vmap onto
the same id leaves amdxdna_gem_get_obj() returning an object this cannot
map, since prime_import() types every import AMDXDNA_BO_SHARE.
Fixes: d76856beb4 ("accel/amdxdna: Refactor GEM BO handling and add helper APIs for address retrieval")
Signed-off-by: Taimuraz Kaitmazov <taimuraz@kaitmazov.com>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260819230852.287751-1-taimuraz@kaitmazov.com
A chain whose command_count is zero passes the payload length check,
because struct_size(payload, data, 0) is just the header. The fill loop
then does not run, so offset stays zero and the request is submitted with
a zero-length buffer.
On firmware without AIE2_NPU_COMMAND that ends at the opcode check, since
op is still ERT_INVALID_CMD and aie2_get_chain_msg_op() answers
MSG_OP_MAX_OPCODE. aie2_get_npu_chain_msg_op() answers
MSG_OP_CHAIN_EXEC_NPU whatever it is given, so there the submission
continues to drm_clflush_virt_range(cmd_buf, 0), which reads the byte
before the buffer and faults on the vmap guard page. EXEC_CMD is
reachable by any process that can open the render node.
Reject the request instead.
Fixes: 8ed8b02396 ("accel/amdxdna: Add debug prints for command submission")
Signed-off-by: Taimuraz Kaitmazov <taimuraz@kaitmazov.com>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260818000019.369366-1-taimuraz@kaitmazov.com
struct amdxdna_cmd_chain contains a flexible array annotated with
__counted_by(command_count). Since the structure is stored in shared
AMDXDNA_BO_SHARE memory, userspace can modify command_count concurrently.
If command_count is changed to zero, the bounds check generated from
__counted_by may fail and trigger a kernel panic.
Remove __counted_by to avoid relying on the userspace-controlled
command_count for the flexible array bounds check.
Fixes: aac243092b ("accel/amdxdna: Add command execution")
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260821033543.1839719-1-lizhi.hou@amd.com
Add a test case that verifies no file descriptor is leaked when
DMA_HEAP_IOCTL_ALLOC succeeds internally but copy_to_user() fails
to deliver the fd number back to userspace.
The failure is triggered by placing the ioctl argument in a private
anonymous page and flipping it to PROT_READ (via mprotect) between
the kernel's copy_from_user() and copy_to_user() calls. With the
buggy kernel the ioctl returns -EFAULT but leaves an extra open fd
in the process's fd table; with the fixed kernel the fd count is
unchanged.
This serves as a regression test for:
"dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds"
Suggested-by: Sumit Semwal <sumit.semwal@linaro.org>
Reviewed-by: T.J. Mercier <tjmercier@google.com>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Baineng Shou <shoubaineng@gmail.com>
Link: https://lore.kernel.org/r/20260817050457.1005285-5-shoubaineng@gmail.com
Signed-off-by: Christian König <christian.koenig@amd.com>
drm_gem_prime_handle_to_fd() open-codes fd reservation and install
using get_unused_fd_flags() + fd_install() directly. This bypasses
the DMA_BUF_TRACE() call that dma_buf_fd() emits, so observability
tools relying on the trace_dma_buf_fd tracepoint silently miss all
DRM PRIME exports.
Replace the bare fd_install() with dma_buf_fd_install(), which wraps
fd_install() together with DMA_BUF_TRACE(), restoring full tracepoint
coverage. No functional change; the fd lifecycle (get_unused_fd_flags
→ work → install) is already correct.
Note: this patch depends on dma_buf_fd_install() introduced in
"dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds"
[1].
[1] https://lore.kernel.org/dri-devel/20260714114654.3885457-2-shoubaineng@gmail.com/
Suggested-by: Christian König <christian.koenig@amd.com>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Baineng Shou <shoubaineng@gmail.com>
Link: https://lore.kernel.org/r/20260817050457.1005285-4-shoubaineng@gmail.com
Signed-off-by: Christian König <christian.koenig@amd.com>
fastrpc_ioctl_alloc_dmabuf() calls dma_buf_fd() which installs the fd
into the caller's fd table before copy_to_user() copies the fd number
back to userspace. If copy_to_user() fails, the fd is already visible
to other threads in the same process but the ioctl returns -EFAULT.
The existing comment in the code even acknowledges the problem:
"The usercopy failed, but we can't do much about it, as dma_buf_fd()
already called fd_install()..."
Now that dma_buf_fd_install() is available (introduced to fix the same
issue in dma-heap), apply the same pattern here: reserve the fd with
get_unused_fd_flags(), attempt copy_to_user(), and only on success call
dma_buf_fd_install() to publish it atomically with the tracepoint. On
copy_to_user() failure, put_unused_fd() and dma_buf_put() cleanly
unwind without any user-visible side effects.
Fixes: 6cffd79504 ("misc: fastrpc: Add support for dmabuf exporter")
Cc: stable@vger.kernel.org
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Baineng Shou <shoubaineng@gmail.com>
Link: https://lore.kernel.org/r/20260817050457.1005285-3-shoubaineng@gmail.com
Signed-off-by: Christian König <christian.koenig@amd.com>
DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the
caller's fd table via dma_buf_fd() -> fd_install() before
dma_heap_ioctl() copies the result back to userspace. If the trailing
copy_to_user() fails, userspace never learns the fd number, but the
fd (and the underlying dma-buf reference) are already visible to
other threads in the same process and are leaked for the lifetime of
the process.
The obvious "close it on the failure path" fix is unsafe: once
fd_install() has run, another thread can already dup() the fd, send
it via SCM_RIGHTS, or close() it and let its number be reused, so a
subsequent close_fd() from the ioctl path can operate on an unrelated
file. This was pointed out by Christian König on v1 [1].
Restructure the allocation path so that fd_install() is the last,
unfailable step of a successful ioctl:
1. heap->ops->allocate() creates the dma_buf.
2. get_unused_fd_flags() reserves an fd number in the caller's
fd table without publishing it, so
no other thread can observe it.
3. copy_to_user() delivers the fd number to userspace;
on failure the fd is returned with
put_unused_fd() and the dma_buf
reference is dropped with
dma_buf_put(), leaving no user-
visible state behind.
4. dma_buf_fd_install() publishes the fd and emits the
trace_dma_buf_fd tracepoint -- from
here on the ioctl cannot fail.
A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap
fd_install() together with the DMA_BUF_TRACE() call, preserving the
export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate()
is refactored to return the struct dma_buf * directly (returning
ERR_PTR on failure) so the caller holds the dmabuf reference across
steps 3 and 4.
The failure at step 3 is easily reachable from userspace: pass a
struct dma_heap_allocation_data that lives in a page whose protection
is flipped to PROT_READ between copy_from_user() and copy_to_user()
(e.g. via mprotect()). Before this change each such ioctl leaks one
dmabuf fd; after it, the fd table is unchanged on failure and only
/dev/dma_heap/<name> remains open.
No UAPI or heap-driver interface change.
[1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/
Fixes: c02a81fba7 ("dma-buf: Add dma-buf heaps framework")
Cc: stable@vger.kernel.org
Reviewed-by: T.J. Mercier <tjmercier@google.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Baineng Shou <shoubaineng@gmail.com>
Link: https://lore.kernel.org/r/20260817050457.1005285-2-shoubaineng@gmail.com
Signed-off-by: Christian König <christian.koenig@amd.com>
The GUD protocol returns TV mode names as fixed-size
GUD_CONNECTOR_TV_MODE_NAME_LEN entries and requires each name to be
NUL-terminated.
gud_connector_add_tv_mode() currently passes each fixed-size entry
directly to drm_mode_create_tv_properties_legacy(), which eventually
reaches drm_property_add_enum() and strlen(). If a device returns an
entry without a terminating NUL byte, strlen() reads past the end of
the slot and can run beyond the allocated buffer, triggering an
out-of-bounds read.
Validate that each returned TV mode name contains a NUL terminator
within its fixed-size slot before passing it to the DRM property code.
If a malformed entry is found, reject the device response with -EIO.
This fixes the out-of-bounds read without changing the handling of
valid devices, and avoids silently truncating malformed protocol data.
Reported-by: syzbot+9ae8e7884e451eaed5b4@syzkaller.appspotmail.com
Fixes: 40e1a70b4a ("drm: Add GUD USB Display driver")
Signed-off-by: Tao Yu <tao1.yu@intel.com>
Reviewed-by: Ruben Wauters <rubenru09@aol.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ruben Wauters <rubenru09@aol.com>
Link: https://patch.msgid.link/20260819072835.4074130-1-tao1.yu@intel.com
nouveau_channel_del() tears the fence context down first and only drops
the channel-kill subscription later, in the middle of the nvif object
teardown:
if (chan->fence)
nouveau_fence(chan->cli->drm)->context_del(chan);
...
nvif_object_dtor(&chan->vram);
nvif_event_dtor(&chan->kill);
The subscribed handler is nouveau_channel_killed(), which calls
nouveau_channel_kill() and from there nouveau_fence_context_kill() on
chan->fence. A kill event delivered in that window takes fctx->lock and
walks fctx->pending on a fence context that context_del() has already
freed.
Nothing reaches this below Fermi today, because the subscription is
gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On
Fermi and newer the window is real but narrow, since a kill has to land
exactly while the channel is being destroyed. That is reason enough on
its own, which is why this carries a Fixes: tag. The last patch in this
series subscribes Tesla channels as well; nothing kills those today, so
it does not widen the exposure now, but it is the groundwork for a
recovery path that would, and the ordering is better fixed before that
lands than alongside it.
Drop the subscription before anything it depends on is torn down.
Fixes: ea13e5abf8 ("drm/nouveau: signal pending fences when channel has been killed")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Marek Czernohous <marek@czernohous.de>
Fixes: ea13e5abf8 ("drm/nouveau: signal pending fences when channel has been killed")
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260812231330.705425-2-mczernohous@gmail.com
SYNC_BO does not constrain its size, so a request for zero bytes reaches
drm_clflush_virt_range(), which ends with an unconditional
clflushopt(end - 1). For an empty range that is the byte before the
mapping, and abo->mem.kva comes from vmap(), so the access lands in the
guard page below the vmalloc area and faults:
BUG: unable to handle page fault for address: ffffd16fbbc70fff
#PF: supervisor read access in kernel mode
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 7 UID: 1000 Comm: sync_bo_probe
RIP: 0010:drm_clflush_virt_range+0x3c/0x70
Call Trace:
amdxdna_drm_sync_bo_ioctl+0x124/0x430 [amdxdna]
drm_ioctl+0x301/0x4c0
__x64_sys_ioctl+0x115/0x2f0
do_syscall_64+0xa6/0x3d0
Any process that can open the render node can do this. Reproduced 3 of 3
times on a Strix Point NPU (1022:17f0), by calling SYNC_BO with size 0 on
an AMDXDNA_BO_SHARE object. The import arm takes the same request but
flushes the whole scatterlist, so it survives it.
Nothing needs flushing for an empty range, so answer before choosing a
path.
Fixes: e252e3f348 ("accel/amdxdna: Revise device bo creation and free")
Cc: stable@vger.kernel.org
Signed-off-by: Taimuraz Kaitmazov <taimuraz@kaitmazov.com>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260817230655.356785-1-taimuraz@kaitmazov.com
time so that it receives the proper lag compensation
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmqB/CQACgkQEsHwGGHe
VUq4Eg//ZeldqtFqUxohjcy5ZrgJ9dhdxwRfqZgYhZCSqTJHVLqAxWVAHnJZWfiz
Vh63rnt78rIPpVX6E/lZLnYm2VwhEO6P6piMzG4CVlh2pMySjhoRIQ3ufNAQRt0o
P79Y29rLhDhHkOaL+jjgSr+ePiDzerrkBfYHK0wJ+BAjphjWxML1wYyCGwhWk/Lu
KuXN/jzbEbAn2QWEwEy9KyxztzJlTYTE+l8jiGfRywAeZOBo8HaXg0HhuCwLnaXb
yPmarhof2/7XUdW/CBGYggLaXF+mW6VeMaiqdhxSKl48KMpIfPnBC99/YCJy6vmQ
pD+kOiysGSFy+3vMbTvjwOYV8T3g7LOpeVkY8KkVmAHUFVF9wBSyPULyooNuxGS9
2pBv6Uz2ojm3wMVk+gggt2VU5uVNLsn9IKpNObyuBRDkt3My4Jej3cQ89LeqyS8Z
q49JbAhEwCRfGpxq92WW6izMWjOnduhiTd9TXF/WoXVtcT9ZSbyxJ3sCxbTBrJxd
na7xln2xsR8w9+G91DmmNPRnBtBkBOJ6xRGacKDeV8dcfKcZGGH6/sRMN9mIhP8v
huCVazSwNCVWDaHn8o/ORBJ0dEJ/536a806ysYfB6MdNzZYtU8iepCj5Lr+uAG/Q
W49ftqYFst9o22wT2i4ZdTfrDrkbekVU67BLv9yu8VcmoQJgt90=
=bK3W
-----END PGP SIGNATURE-----
Merge tag 'sched_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fix from Borislav Petkov:
- Make sure a delayed sched entity's runtime stats are updated at the
right time so that it receives the proper lag compensation
* tag 'sched_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched: Update time before requeueing delayed entities
fallback to the physical one instead
- Fix a build error with ARM rpc_defconfig and function tracer enabled
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmqB+qQACgkQEsHwGGHe
VUr7zQ//d2p80ASoa/3p6qzDs5FiySg2tWEfdRp6PoWDeonu5xVcXHs4GJyFFunP
X7pu4kZ+gXq5RoWuk/ClFschaakeij0XtNCjMrpA7ZZpqwBwx387nv3v/9KecU3n
IGqS6bz22d/99te9cMo+1vj3gm/PBIE3SOEnwQQ7oD2pAc2TzdLeoXo554EE5zZu
tBpgdCz4fDcvmpr9sXzw9fDjgJgPjlVJYq/+juCtxXAWQtGJnHWCqGdMxbOtzHHo
E2lLQhZNgC3Vi+jbTYB7mpa70R9iS8TmjuosjKpan3uxakQZnE/+pqN6xFpDh3Ho
090dtBFOUYxx7LDcX6RjXrbddIaHwZNCP1W6OB0EKPUntcpD6MMo4GMBURUxJ4mO
TT0gCtd1bsgYhNwZDVBUxhwoqM1e+EtL44ndT26E0HnIIT0gqr4QE6ODvFpeUQmj
2sNdnBSslrLYeHYypBFRRo3aiDmfYCrML2z/OWEdRmAOYvUssJP4euXrBbInobd5
VtBxjjQmBCSiV7nD0vor9eU5kJ4y6VNfiDDBuByNBzIWliMznLNgN92zAGPn7uwR
IZ1wBWSbMYoc2C8h0CIPax1J+S517G17WVhMbJnYNlg9SzMAxttBWoHHvrdGMfW8
Nua9plybvDVa+SRgCgJl7fiY19/UtXh/9NxHFQtcJnqR0eQfxJs=
=IlDf
-----END PGP SIGNATURE-----
Merge tag 'timers_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fixes from Borislav Petkov:
- Detect a broken EL2 virtual timer in the bcm2712 SoC boards (RPi5)
and fallback to the physical one instead
- Fix a build error with ARM rpc_defconfig and function tracer enabled
* tag 'timers_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
clocksource/drivers/arm_arch_timer: Workaround bcm2712 broken EL2 virtual timer
tick: Include ktime.h and jiffies.h in linux/tick.h
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmqB+IQACgkQEsHwGGHe
VUoLoA//UiK75T3O49g7pPmQh3lOqoadcvFduoGPVulWr9MqMYb9la+XRAPTO2aX
lMldJhHoQBdL4chQU/2r1LgcM9i2GF753ssqO+MhAQHrDUMhZD87fRkQt+0e1jEc
iAfjQCWVV7+abzsgKbZOlvXeYBFY6Bcy/EwGr9OhNPn1Zg6yGT73gV/ihgc1KYtj
gyUCNjgu5n5UWLZOsAfy0JpSxdeHqCaydYKRRIWbQrbjlp+fauRPtbyOXua3mwNt
gCnBpXnB3rD3R98KGr9C1GHg4DhwTSWZIQj67KMSnEKLco3fzhzq1PW1GwY3UFqn
81OKGIqKHP+VDJTNsk4F0zrXLqG3NWaKwCu9jLV5yhA1z3/4GXNAE3iOT8DT3lmp
upDnQ85aNkPSruF/ZjFxeNT3qrPOLCyMz0p/6qhZN7A3V/4R+B9vRYpvWZunvzvC
k5hqeV1NyeRSoqvEp8ySH++v7Ifny2LbltIcuL+9wWUvRCb45ACQTgsjfIIRrm8F
5mGBRyZs53lU7NthyE1FScNrVUFw7HaWAIapzaZPZIqhNh2+MAOODclTggYp0Y2A
tIEGLohrsuEiPDA3xwa+6a+826M7Uan0lfIVV39BwTM2axuMOuapn/Ou5GmPSvx6
guE0WRugo7TN5st8e+Go0ZrUMXzcQ61G3fdNJOR7UIbQROmrgEo=
=7htY
-----END PGP SIGNATURE-----
Merge tag 'core_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull rseq fix from Borislav Petkov:
- Prevent a lockup when rseq grants a timeslice extension
* tag 'core_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
rseq: Prevent hard lockup on granted time slice extension
Split mt7921_mcu_regd_update() into two functions to prevent recursive
mutex acquisition. Introduce __mt7921_mcu_regd_update() as the internal
implementation that assumes the mutex is already held by the caller,
while mt7921_mcu_regd_update() remains as the external interface that
handles mutex acquisition and release.
This fixes a deadlock issue when mt7921_regd_set_6ghz_power_type() is
called with the device mutex already held. Without this change, calling
mt7921_mcu_regd_update() would attempt to acquire the same mutex again,
causing a recursive lock deadlock.
The __mt7921_mcu_regd_update() function can be safely called when the
caller has already acquired the device mutex, avoiding the deadlock
while maintaining proper synchronization for regulatory domain updates.
Fixes: dc2608cf5224 ("wifi: mt76: mt7921: refactor regulatory notifier flow")
Signed-off-by: Charlie-cy Wu <Charlie-cy.Wu@mediatek.com>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 0a4bb2abc3.
This was reported to break the touchpad on at least some Thinkpads, and
while the revert has hit the i2c tree, it hasn't hit mine. So I'm
reverting it directly just to have this resolved for the imminent 7.2
release.
Reported-by: Thorsten Leemhuis <linux@leemhuis.info>
Link: https://lore.kernel.org/all/b4a4eadb-282f-464c-843a-19d415a34d0c@leemhuis.info/
Cc: Mario Limonciello <mario.limonciello@amd.com>
CC: Hardik Prakash <hardikprakash.official@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
- Avoid use-after-free of an event's group leader by promoting detached
sibling events to standalone entities and correct related accounting and
state transitions
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmqB6xQACgkQEsHwGGHe
VUpWFQ/+KyU6R2DC48ifpChzgTFmQ2gmIjy1IIsWSGmdSbyD5CEWar8hHDRq1X9r
peuQizTXTQ2Ze75atTMIBExR6eUFYb2sKA1HpobcGnB96cpK8e2vmxhvXoHgB3IZ
TYDXQ1RMPnbyTn2rCQwr5cgSq2Qe7w2tMXMQKzfmDxP1r7cE81zJVFAsRdVVZP75
kvlcCL43pIwzxzP7sDb9bU9lTkW2Sw83dLIp3jBd3iiUpIQpwqV+UG3/fkInV58n
L56cYFsovLbvWdxq4oj6cFwRBmvyrYKV0zkT+zW0SO2AzlVhfwCD/o74hxLwrN//
Gas0d51uQfWt+5M7s6T0KFQYBfClG4uoIi2yh7zXxWEXyhcNuvmAVrY3xiQxReIi
m88+ByWHfBc/mYTHKWJAqb8sHhJiktU52T55ktOJaPNGczA5+O/4alnOg3Kxvw7d
CXp1raxJLqDxvd7Ubu/LVjWY96ds+fAaC15ydC6Lh08b9LPhA8rRCavf7NeSOzOD
E1NA3QLS3TwbrTboaGqLMmzOLPkBBZ+28PUASg1ZpyfGnw91Ggv/gOVNUgr5PvMU
D/gzRCwEYfDdhOrIHzGrfJ1fwj4qFsZ6HSge3sHDj8/BCcQYj/zmlTKe0CHKbaiy
D7bkLNwdBc0z+eh5T7UfCYodUu0qiiek5Y0G3q8FVad0mFDYtUA=
=moR8
-----END PGP SIGNATURE-----
Merge tag 'perf_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Borislav Petkov:
- Prevent the use of exited events as group leaders
- Avoid use-after-free of an event's group leader by promoting detached
sibling events to standalone entities and correct related accounting
and state transitions
* tag 'perf_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/core: Fix group leader use-after-free after sibling detach
perf: Reject exited events as group leaders
x86 prompted mainly by a recent finding on AMD related to INVLPGB/TYLBSYNC
invalidations. Having the command line option is simply another way to
alleviate the situation short-term
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmqB44wACgkQEsHwGGHe
VUqKSRAAgQKrFw3mH29qsNGjS0GH1m1B6DShBB6/BwJb716gGNfFV/EmYrcwRM4+
GTSA+LGLkKrb45gR+PkKkyoiXDPB/OzfmSlNvD+VCt1t78RdHCXLByye7SxxFjV/
smboswwphQJPLJ8iTeJn+I1jbfC45Wla1hlMgCdHC7tTyyBOPfg32JdQ37cnd2PE
8igsVVhMbEvszhbDrjVAWWUUjlWEjax8ix4rEKMV9J9zETgurK6Vy/G4QNTePSQU
cc31FFUp+z+iBNWjCv1jhsuxUbxsH4u7SM3x18cTmgfKz03DQwVnCafkGPy8Rs2o
nIdgojAnDginPQ0CsGvB1la7zHQ2MFtBRbNabW+m6WGs2OdwHs1+ATcm0/bFuQBh
UqXic8fZ9jYsoGwRfqy/Nsg1ywkrm+IJ5RxSD1+wreGgYPPpEk5tzs5tx4vPFemX
dm2ZizKr+kDxZThdTutwV0WY1A/xaix8M5y2poXb929zMy6E+sMwe7fjdnFSZph4
I84PzW4vlH5BTnEK96ROl+ZB4tTMLGBGM/3ymtlmeXAkLiyrj10f+QdKCF1GPHsO
Ljv0LVtVL6h4/AJzoV6mYNLCOQUmooMkwwvTYWoHZ3yoqjHGWjGlWDyx7b5uL6BY
mFv81rxp0TWcFKLxv8g737NLKH95JAbP9/bKbldc9rmMl/tBOKE=
=1btz
-----END PGP SIGNATURE-----
Merge tag 'x86_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fix from Borislav Petkov:
- Add a proper kernel cmdline option to control the TLB invalidation
method on x86 prompted mainly by a recent finding on AMD related to
INVLPGB/TYLBSYNC invalidations.
Having the command line option is simply another way to alleviate
the situation short-term
* tag 'x86_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/CPU: Add a tlbi= cmdline switch
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmqBJfoQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpnZvEAC5y7aQuMkr++q00K/+gkRF2mef/kZPyySR
N7alVJW69FgAluun+2MD9Sg1SXNXKlJ+8WAouKwhwbo/LuzzxdrJhJ8FO+94JTqn
Dnf01ZCsbSU2KU1/D5Nk81vJTJMHTAmaefvejdJ1X0R8arBNLJ+8TZRRtuxixyez
6kt5HZTEY4n7WtkJs1sDUrbUCYt3jGXRz+sE+bNSzNFOCaTDBqCEquucZpa5QGRl
Z7uVdHmpl8aQBCPNJq3H9l3HCav3FYCP8j+6DOzw8wNamlFdBj7ALldEz6uX1Kr9
EySUjW5MT9WwkN6dbSGOmF5bNQYuO8Umv0VsWTnIxXmEb34Jsz7PwVKZ+lJydsp5
Lm1JN9qT0uvN0CHyAL4ni3FnsTZnWDiTozBrZ4+vEPO8jRhTHg52eWtF4kfpaMxJ
h2gw0MmPW+TaMQ13EiJ6fqppm/BrqtsX7WBKyKyflZIDXTy+KOoXxaiMO/IDMV0i
ttS3yc6qLtvTR9BacLKlGc6YkiP4R9/1xSLWpOjNh18qljzgFFYjxOuszbcCE0/p
vrefCd8J14HcCt5Qlw2XGYBptowbsNkEJ/k6L8Og36RAnyYzE84kbfVpiWddk0EU
WqwAFWKc1J+1Ujf0TvmiprU1OfCPPeNp2xbDMMCGMRgLb6WSDUgUwBTiM9Hl2TmN
N59eL2LfxA==
=jmZj
-----END PGP SIGNATURE-----
Merge tag 'block-7.2-20260815' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fix from Jens Axboe:
"A single fix for a regression in this cycle, where drbd would leak
shared secrets over netlink. This restores the behavior to match
what we had before"
* tag 'block-7.2-20260815' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
drbd: don't leak the shared secret to unprivileged netlink dumps
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmqA/oQQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpj4ND/9OYcaM9+R/w7sv5+gefzm0omHhlLeg1nZ9
RCUKvG86yq2PaNQfL4Tu+xJAiAMoW1maL0BIhLITzB4Q7X+L6MA6ddEi7180YvoH
J3vimltNwJRdwRwQVFgjMI+L5DpBbM864s8Uk53Dj8nYl6pNh/0rcVxxjEfy/6Mz
XyT5lijBXSHieL5qynLxPnHyz5jLq0Y/Y9uVWhPxRuYYwrOjWNVPugsnrg17vNpC
3m9OwDzYldsAvoJehd8d6jrDGU/yxRynvP9NV8UfMnwg9k3F+C1f0PdbUrVwQlHh
KqmpGluSpYyPuoyL82nS3WUpZ3iTpCvzPEl6g3HpKK3xo2DutaohrqLFt0q/oJd0
B1LoMuIs7nO486ZoodtyvzWWevkEFbKtYlOleLYhYX9N+oOPRczsO64ZL3lyT2MG
FsNWaiyN6F5VlI4UAZyxg1PNqtTFutcU6WZjrsWVhOOEvq+rf5on1RgXH/i6LR4n
DxEBTXeVrBUWOT0+Y2txxHz6T1UbcWkqdpk781dOZY+HCTg1MVCha20x3YttASBd
9JY03+JSolbBFzocaFXF/mWR1MGJdATWu3mutrdNoboeUiy5R/Kb3E81+a0CCR2K
fI0TQ9RhQ+UxI8XW7IkxlTK/6bSyxiEIudgv0sYmKEZgH9O8SNY6ZTD8MeuA1fVN
YgbVYoS8eA==
=vArh
-----END PGP SIGNATURE-----
Merge tag 'io_uring-7.2-20260815' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull io_uring fix from Jens Axboe:
"Just a single fix for a potential issue on 32-bit x86 with PAE"
* tag 'io_uring-7.2-20260815' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
io_uring/rsrc: reject overflowing regvec bvec byte counts
The conversion to explicit netlink serialization dropped the
exclude_sensitive parameter from net_conf_to_skb(), so each caller has
to sanitize by hand. Two dump paths were missed:
drbd_nl_get_connections_dumpit() and the volume-less connection branch
of get_one_status(). Neither op carries GENL_ADMIN_PERM, so any
unprivileged local user could read the CRAM-HMAC secret.
Add a net_conf_to_skb_sanitized() wrapper and route all three callers
through it.
Fixes: 8098eeb693 ("drbd: replace genl_magic with explicit netlink serialization")
Reported-by: Vivek Parikh <vivek.parikh@breachx.ai>
Signed-off-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
Link: https://patch.msgid.link/20260814151617.73752-1-christoph.boehmwalder@linbit.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
These are three last-minute fixes for the 7.2 release,
though nothing alarming:
- one error handling fix for optee firmware
- incorrect i2c data for the apple M3 that was added in 7.2
- a boot time warning fix for nvidia tegra
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmp/kkEACgkQmmx57+YA
GNn0sRAAnDh3M8YkrmeGdU4aLCEIFDa+SB4+5OF2ANtjunGy3kUlPj1f9y9Sk7aq
CEA2foLgAOThE7anz3VrV5RC+OHBqfe3OD39kMqdlTJlqZNLpVEbqFsyoMr8owAw
zpfwDl8n1u9ROjGEyQ7t6QAE512ZLbwZ3wducoQPFGXZfjTpiuF4P00lpXa729xF
H+Pb0WOMz3zytIfGKvKx4RWkiH0/xatiLoy0AO+73b2lCQgkJF4bhdkM+G5XAIvG
XBhzO488Pu9vuoXpNnY0lizE2xZiJdhBJkR8/Ad0KrTlaLsjwJkF237ozWQ89F8U
/00wS8zE9FXsEQNw9uJj7EjW7nKItxTloq3MELjoXbGV7xW5sEsjWZM3xsvFX5rD
uJo4laNmjp7LZgTvlOZ9T5HM3XIMes3MNTqa4qx0bmrpxwy8BiaTuED9ugrUAIkv
xR2xejKQdFEIEfJRga9YSVbVhF1fDH0dFG+8BVchx6npFWwFRk/RI0JycFGqUul7
8CNXuweWNaVb0Q/zfwWz99pVNqdDySJpAMh4Pl4GKB++jYRvnHU4sCSqDYrkqWRo
UGMpZhuXHpwzVWu3B/gPdk2YW/Mo1jfGN6dPFP3JsfdQx1BaUx/2j4ggJn20nTUw
v7bBU2i0ljMvNkClCqY8sIfgWDxiI1vsFzabW5o2PRzm8R+jm94=
=xgY+
-----END PGP SIGNATURE-----
Merge tag 'soc-fixes-7.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC fixes from Arnd Bergmann:
"These are three last-minute fixes for the 7.2 release, though nothing
alarming:
- one error handling fix for optee firmware
- incorrect i2c data for the apple M3 that was added in 7.2
- a boot time warning fix for nvidia tegra"
* tag 'soc-fixes-7.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
arm64: tegra: Add EL2 virtual timer interrupt for Tegra194
arm64: dts: apple: t8122: Fix I2C resources
optee: ffa: Add NULL check in optee_ffa_lend_protmem
A bug fix found by researchers.
* Ensure to mask all privileged bits when restoring the supervisor
register from sigreturn.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE2cRzVK74bBA6Je/xw7McLV5mJ+QFAmqABmQACgkQw7McLV5m
J+TL9A/7BmXvg+A5KT0xKxYrC//OCvD5dGwwKVhc5tEtNhpcWZU4fQo9WioRUpcz
OfbBcKN4RGrpm9Do685mqc2+nOGFcK9SId6eN47ri2G1ZJ1+wXE1IVKLIddlpBzp
rBJJyStBAKG2ICQfgoKM26JGbRttH19hJWSDITLzA2vAMp2gxpV7I1tSiLMrbOym
e/fKuclQ2tlH3DX+CJrRia/azeKRMjhlTCsSCH+FQSG+oegtCd6PP+rWi+i7cIas
pdSrDes+ES6LcGncK+uaNQfIi4D9tm37POYOK1zq4cyQknl4yl0mCWzHDegHocM3
EMAeZXgIxWR2sDn/xGl42gXsEjsIxgwUn9eufvAaNNVomFKOE8cVTsTAI7sgOCsj
9eiLLTCAQdGt8wiKYZLfnSm/tkIrtUs+Uc0v1OWslWUN9pVOuhiE5RYVwt6oOgyf
/16K0OFVggElHSyCkk9WPWryER1fg2n/eaOHflyOCO7YaQj9LL2e6TkVae7jQ+re
vZ1ZgNuSO9ZchcemvtQ0gH28sceRy+R2ICQV7ytuR+7Isxk1kQwXuKFhjNkKcy35
pTVFaFY1d/PwrtgUglk45/9ITFLJZNiz4ToE8jrP8P9+DlQhdp7tmZ2gNmtPb3Ll
H0fOU2Bh4QeAQm4T0XDGlm1U2eGA5gy3HFUUNMXomLdNfpT2vIU=
=p9Ll
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of https://github.com/openrisc/linux
Pull OpenRISC fix from Stafford Horne:
"A bug fix found by researchers:
- mask all privileged bits when restoring the supervisor register
from sigreturn"
* tag 'for-linus' of https://github.com/openrisc/linux:
openrisc: signal: do not restore privileged SR bits on sigreturn
restore_sigcontext() copies the whole supervision register (SR) from the
signal frame and only clears SPR_SR_SM before the value is reloaded into
the hardware SR (through ESR and l.rfe) on the return to user space. All
other SR bits are left under user control.
An unprivileged task can thus return from a signal handler through a
crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the
CPU performs no translation or protection on data accesses, so the task
gains read and write access to arbitrary physical memory, a local
privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH
and the cache-enable bits are exposed the same way. The ptrace GPR regset
already refuses any change to SR for exactly this reason.
Restore only the arithmetic flag bits (F, CY, OV) from the signal frame
and take every privileged control bit from the SR the kernel saved on
signal entry.
Verified with qemu-system-or1k -M or1k-sim: before this change an
unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to
physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the
same PoC receives SIGSEGV and physical memory is unchanged.
Fixes: ac689eb7f9 ("OpenRISC: Signal handling")
Cc: stable@vger.kernel.org
Signed-off-by: Ali Ahmet Memis <ali@iusegentoo.com>
Signed-off-by: Stafford Horne <shorne@gmail.com>
- A couple of fixes to the sur40 touchscreen driver to correct
registration and teardown ordering, and to fix error path unwinding
when video device registration fails.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQST2eWILY88ieB2DOtAj56VGEWXnAUCan/qAgAKCRBAj56VGEWX
nIwLAQCryq8oWRzTY1H7QurNDJ89vSwdRJ8CxiLqQgJmWCzgzQD/Vr9SJmWacfn1
TEtDiqHoRSk2wOrZaSDRgsWTH2BOYQI=
=RCXW
-----END PGP SIGNATURE-----
Merge tag 'input-for-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input fixes from Dmitry Torokhov:
- A couple of fixes to the sur40 touchscreen driver to correct
registration and teardown ordering, and to fix error path
unwinding when video device registration fails.
* tag 'input-for-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: sur40 - fix V4L error path cleanup
Input: sur40 - fix input device registration ordering
scheduler:
- revert fair scheduler patches due to regression
- mark fair as experimental
connector:
- fix OOB read in hdmi audio infoframe
log:
- fix divide by 0 if module param is set to 0
- fix OOB read on empty message
- fix infinite loop for too large scale
xe:
- Fix DPT Allocation paths
- Fixes around UM queue BO
- Order ring writes before ring tail updates
- Add termination on resume for PXP
- Document Sentinel and make CTX_TIMESTAMP read TOCTOU-safe
- Fix sync entry leak on OA config emit failure
- Check managed mutex initilization errors
- Fix min frequency setting
- Fix xe_device_probe error path
amdgpu:
- Bounds checking fix in CS IOCTL
- Bounds checking fix in GEM IOCTL
- Display fixes
- GPUVM fix
- ASPM fix
- UVD bounds checking fixes
- VCE 3 fix
- BT.2020 fixes
- NBIF 6.3.1 fix
- IP discovery fix
radeon:
- Runtime pm fix
amdxdna:
- skip attempting to populate unmapped pages
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmp/eCcACgkQDHTzWXnE
hr4BoA/7By6sGa+PelN5D3XzzJCHWd8/G/A3TFAFLrtpVK6M84qzNHenGFTNO1SF
3stK9CANA5GmXTudR3UJ4/ZagTde2ZU2hI0tHwOlldRvV91+Ed4lTcr6Kf4xzSnP
R+Z3KZ/ggvGpKb628Z7hbwhNBkbkTY4TgotY0vCGK59t1M9Is0b3rMDB9ok7Z9ET
B2nQr6UQ/3rb7aoOm0cYik2vTplTI7P1pchq0yKaXwZLNGlmuf556u/t3zsb2+3T
E2ouifY82di75Fq+mQFhr4IP9SnFukxeXZw0mkykg2TUlPNRosHHYifdBWZztVLn
ZVICunIDuzBb/bSgCeC3qM1nhNW3IBse9xTwpcNIm6zA7qantoCB83t8MPbR6d/C
C1NVGcWC89AP7sKT5s15Yzpk7Ink1CJ8GReDV87g0NGFQKCihb4MnW8AkF4nRR5O
CZuIwEE3M8MDncDBErL+9K1KmHO5UnIy0FEV3lEgSmoRqgG9m/6BAMwzNXbVU3W4
CwlgcKyeFS23f++GW02OMWJVAp4VV7S7b4pxllL0zoL2ZPQZ827BYwpnKBtiOrJp
Sb0U0dIKxgho+nA6R2XvdCZItN0OvjyvQK6OCNYAMtC7XEGboJJ3jBf+rkvgM4jo
rpumV+1lI/urWO9rhhg2Ri318N9mWIWqIbmKYPIMrGojG3MiKBw=
=rauR
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2026-08-15' of https://gitlab.freedesktop.org/drm/kernel
Pull drm fixes from Dave Airlie:
"While this is large for rc8 time but also AI driven fixes is a lot of
it, we had a more traditional screw up, and a regression was just
found in the fair scheduling patches that went in back in rc1. This
reverts the fair scheduler back to an option and sets the default back
to what it should have been. We might have been a bit overly zealous
in switching over, but at least it feels more normal than the AI
driven fixes.
Apart from the scheduler, it's mostly amdgpu and xe fixes, with some
misc fixes to the log code and connector code.
scheduler:
- revert fair scheduler patches due to regression
- mark fair as experimental
connector:
- fix OOB read in hdmi audio infoframe
log:
- fix divide by 0 if module param is set to 0
- fix OOB read on empty message
- fix infinite loop for too large scale
xe:
- Fix DPT Allocation paths
- Fixes around UM queue BO
- Order ring writes before ring tail updates
- Add termination on resume for PXP
- Document Sentinel and make CTX_TIMESTAMP read TOCTOU-safe
- Fix sync entry leak on OA config emit failure
- Check managed mutex initilization errors
- Fix min frequency setting
- Fix xe_device_probe error path
amdgpu:
- Bounds checking fix in CS IOCTL
- Bounds checking fix in GEM IOCTL
- Display fixes
- GPUVM fix
- ASPM fix
- UVD bounds checking fixes
- VCE 3 fix
- BT.2020 fixes
- NBIF 6.3.1 fix
- IP discovery fix
radeon:
- Runtime pm fix
amdxdna:
- skip attempting to populate unmapped pages"
* tag 'drm-fixes-2026-08-15' of https://gitlab.freedesktop.org/drm/kernel: (51 commits)
drm/log: Fix infinite loop when scale is too large for display
drm/log: Fix out-of-bounds read on empty message length
drm/log: Fix division by zero when scale module parameter is 0
drm/xe: Fix xe_device_probe() failure
drm/xe: Fix a bug in pc_adjust_freq_bounds()
drm/xe/oa: Check managed mutex initialization errors
drm/xe/oa: Fix sync entry leak on OA config emit failure
drm/xe/lrc: document sentinel and make CTX_TIMESTAMP read TOCTOU-safe
drm/xe/pxp: add termination on resume
drm/xe: Order ring writes before ring tail updates
drm/xe/guc_ads: use uncached mapping for UM queue BO
drm/xe/guc_ads: allocate UM queues in VRAM on dGFX
drm/xe/guc_ads: allocate UM queues in a separate BO
drm/xe: Fix DPT allocation paths.
accel/amdxdna: Skip unmapped range in aie2_populate_range()
drm/amdgpu: Prefer default discovery offset
drm/amdgpu: Reject UVD message with invalid number of h265 refs
drm/amdgpu: fix nbif 6.3.1 l1 low power not functional
drm/amd/display: fix BT.2020 YCbCr output CSC matrices for DCE
drm/amd/display: fix BT.2020 YCbCr limited output CSC matrix
...
