aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
diff options
context:
space:
mode:
authorJens Axboe <[email protected]>2025-09-18 19:59:15 +0000
committerJens Axboe <[email protected]>2025-09-18 19:59:15 +0000
commitdf8922afc37aa2111ca79a216653a629146763ad (patch)
treec75fa1b2325c54e460cea5d7732c3dfe659fd190 /drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
parentio_uring: include dying ring in task_work "should cancel" state (diff)
downloadkernel-df8922afc37aa2111ca79a216653a629146763ad.tar.gz
kernel-df8922afc37aa2111ca79a216653a629146763ad.zip
io_uring/msg_ring: kill alloc_cache for io_kiocb allocations
A recent commit: fc582cd26e88 ("io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU") fixed an issue with not deferring freeing of io_kiocb structs that msg_ring allocates to after the current RCU grace period. But this only covers requests that don't end up in the allocation cache. If a request goes into the alloc cache, it can get reused before it is sane to do so. A recent syzbot report would seem to indicate that there's something there, however it may very well just be because of the KASAN poisoning that the alloc_cache handles manually. Rather than attempt to make the alloc_cache sane for that use case, just drop the usage of the alloc_cache for msg_ring request payload data. Fixes: 50cf5f3842af ("io_uring/msg_ring: add an alloc cache for io_kiocb entries") Link: https://lore.kernel.org/io-uring/[email protected]/ Reported-by: [email protected] Signed-off-by: Jens Axboe <[email protected]>
Diffstat (limited to 'drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c')
0 files changed, 0 insertions, 0 deletions