From: Mingyu Wang 25181214217@stu.xidian.edu.cn
Syzkaller fuzzer triggered a kernel panic via a WARNING in drm_prime_destroy_file_private() due to a non-empty prime rb_tree.
The root cause is a complete lack of synchronization in the teardown path. While the import path (drm_gem_prime_fd_to_handle) holds the &file_priv->prime.lock during lookup and insertion, the deletion path (drm_prime_remove_buf_handle) traverses and mutates both the 'handles' and 'dmabufs' rb_trees without acquiring any mutex.
When multiple threads concurrently close GEM handles or interleave import and close operations, the pointers and balance states of the rb_tree nodes get corrupted. As a result, certain members are erased from one tree but remain orphaned in the other. Upon process exit, the final sanity check triggers the WARNING.
[ 448.919314][T19739] ------------[ cut here ]------------ [ 448.945387][T19739] WARNING: CPU: 0 PID: 19739 at drivers/gpu/drm/drm_prime.c:223 drm_prime_destroy_file_private+0x43/0x60 ... [ 449.056535][T19739] Call Trace: [ 449.056544][T19739] <TASK> [ 449.056553][T19739] drm_file_free.part.0+0x805/0xcf0 [ 449.056652][T19739] drm_close_helper.isra.0+0x183/0x1f0 [ 449.056677][T19739] drm_release+0x1ab/0x360 [ 449.056719][T19739] __fput+0x402/0xb50 [ 449.056783][T19739] task_work_run+0x16b/0x260 [ 449.056883][T19739] exit_to_user_mode_loop+0xf9/0x130 [ 449.056931][T19739] do_syscall_64+0x424/0xfa0 [ 449.056977][T19739] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 449.057268][T19739] </TASK> [ 449.057295][T19739] Kernel panic - not syncing: kernel: panic_on_warn set ...
Fix this by acquiring the prime_fpriv->lock mutex around the rb_tree lookup and erasure logic. To respect the locking rules and avoid potential deadlocks with driver-specific memory cleanups, assign the target node to a temporary pointer and defer the dma_buf_put() and kfree() operations until after the mutex is safely dropped.
Fixes: ea2aa97ca37a ("drm/gem: Fix GEM handle release errors") Cc: stable@vger.kernel.org Signed-off-by: Mingyu Wang 25181214217@stu.xidian.edu.cn --- drivers/gpu/drm/drm_prime.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 9b44c78cd77f..26319c638e0f 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -190,6 +190,9 @@ void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, uint32_t handle) { struct rb_node *rb; + struct drm_prime_member *found = NULL; + + mutex_lock(&prime_fpriv->lock);
rb = prime_fpriv->handles.rb_node; while (rb) { @@ -200,8 +203,7 @@ void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, rb_erase(&member->handle_rb, &prime_fpriv->handles); rb_erase(&member->dmabuf_rb, &prime_fpriv->dmabufs);
- dma_buf_put(member->dma_buf); - kfree(member); + found = member; break; } else if (member->handle < handle) { rb = rb->rb_right; @@ -209,6 +211,13 @@ void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, rb = rb->rb_left; } } + mutex_unlock(&prime_fpriv->lock); + + /* Defer resource release outside the mutex to prevent deadlocks */ + if (found) { + dma_buf_put(found->dma_buf); + kfree(found); + } }
void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv)
On 5/28/26 10:29, w15303746062@163.com wrote:
From: Mingyu Wang 25181214217@stu.xidian.edu.cn
Syzkaller fuzzer triggered a kernel panic via a WARNING in drm_prime_destroy_file_private() due to a non-empty prime rb_tree.
The root cause is a complete lack of synchronization in the teardown path. While the import path (drm_gem_prime_fd_to_handle) holds the &file_priv->prime.lock during lookup and insertion, the deletion path (drm_prime_remove_buf_handle) traverses and mutates both the 'handles' and 'dmabufs' rb_trees without acquiring any mutex.
That's just simply incorrect, drm_prime_remove_buf_handle() is called with the lock already held.
See drm_gem_object_release_handle():
mutex_lock(&file_priv->prime.lock);
drm_prime_remove_buf_handle(&file_priv->prime, id);
mutex_unlock(&file_priv->prime.lock);
So the patch you propose here is just nonsense.
What tree are you working on? Could it be that this is something specific to a certain version.
Regards, Christian.
When multiple threads concurrently close GEM handles or interleave import and close operations, the pointers and balance states of the rb_tree nodes get corrupted. As a result, certain members are erased from one tree but remain orphaned in the other. Upon process exit, the final sanity check triggers the WARNING.
[ 448.919314][T19739] ------------[ cut here ]------------ [ 448.945387][T19739] WARNING: CPU: 0 PID: 19739 at drivers/gpu/drm/drm_prime.c:223 drm_prime_destroy_file_private+0x43/0x60 ... [ 449.056535][T19739] Call Trace: [ 449.056544][T19739] <TASK> [ 449.056553][T19739] drm_file_free.part.0+0x805/0xcf0 [ 449.056652][T19739] drm_close_helper.isra.0+0x183/0x1f0 [ 449.056677][T19739] drm_release+0x1ab/0x360 [ 449.056719][T19739] __fput+0x402/0xb50 [ 449.056783][T19739] task_work_run+0x16b/0x260 [ 449.056883][T19739] exit_to_user_mode_loop+0xf9/0x130 [ 449.056931][T19739] do_syscall_64+0x424/0xfa0 [ 449.056977][T19739] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 449.057268][T19739] </TASK> [ 449.057295][T19739] Kernel panic - not syncing: kernel: panic_on_warn set ...
Fix this by acquiring the prime_fpriv->lock mutex around the rb_tree lookup and erasure logic. To respect the locking rules and avoid potential deadlocks with driver-specific memory cleanups, assign the target node to a temporary pointer and defer the dma_buf_put() and kfree() operations until after the mutex is safely dropped.
Fixes: ea2aa97ca37a ("drm/gem: Fix GEM handle release errors") Cc: stable@vger.kernel.org Signed-off-by: Mingyu Wang 25181214217@stu.xidian.edu.cn
drivers/gpu/drm/drm_prime.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 9b44c78cd77f..26319c638e0f 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -190,6 +190,9 @@ void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, uint32_t handle) { struct rb_node *rb;
struct drm_prime_member *found = NULL;mutex_lock(&prime_fpriv->lock); rb = prime_fpriv->handles.rb_node; while (rb) {@@ -200,8 +203,7 @@ void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, rb_erase(&member->handle_rb, &prime_fpriv->handles); rb_erase(&member->dmabuf_rb, &prime_fpriv->dmabufs);
dma_buf_put(member->dma_buf);kfree(member);
found = member; break; } else if (member->handle < handle) { rb = rb->rb_right;@@ -209,6 +211,13 @@ void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, rb = rb->rb_left; } }
mutex_unlock(&prime_fpriv->lock);/* Defer resource release outside the mutex to prevent deadlocks */if (found) {dma_buf_put(found->dma_buf);kfree(found);}}
void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv)
2.34.1
Hi Christian,
Thank you for the review and for catching this. You are absolutely right, and my analysis was flawed. Adding the lock inside `drm_prime_remove_buf_handle` would indeed cause a recursive deadlock.
The syzkaller crash was originally triggered on the v6.18 kernel. When investigating, I checked the latest mainline source for `drm_prime_remove_buf_handle` itself. Since I didn't see any synchronization changes within that specific function, I incorrectly assumed the concurrency issue was still completely unhandled, failing to notice that the upstream tree properly holds the lock in the caller (`drm_gem_object_release_handle`).
I will dive deeper into the code to see if there is still any hidden race condition under the current locking scheme, or if this is strictly a legacy issue that might only require a stable-tree backport. If a fix is still warranted, I will send a v2 patch.
Thanks again for your time and guidance!
Best regards, Mingyu Wang
From: Mingyu Wang 25181214217@stu.xidian.edu.cn
When a GEM handle already exists in the drm_prime_file_private, repeated calls to DRM_IOCTL_PRIME_HANDLE_TO_FD can cause drm_prime_add_buf_handle() to insert multiple entries with the same handle into the handles rb_tree. Because the insertion walk moves left on equality, duplicate keys are structurally accepted by the tree.
Later, when the handle is released via drm_gem_release() -> drm_gem_object_release_handle() -> drm_prime_remove_buf_handle(), the latter iterates the handles tree, removes the first matching node, and breaks out of the loop. Any remaining duplicate nodes that share the same handle are left orphaned in the dmabufs tree - they are no longer reachable through the handles tree and are never freed.
When the drm file is finally closed, drm_prime_destroy_file_private() triggers:
WARN_ON(!RB_EMPTY_ROOT(&prime_fpriv->dmabufs));
because the dmabufs tree is still non-empty. With CONFIG_PANIC_ON_WARN this becomes a kernel panic:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 19739 at drivers/gpu/drm/drm_prime.c:223 drm_prime_destroy_file_private+0x43/0x60 ... Kernel panic - not syncing: kernel: panic_on_warn set ...
Fix this by restarting the lookup from the root of the handles tree after each successful removal, so that all duplicate nodes for the given handle are erased. The caller (drm_gem_object_release_handle) already holds prime_fpriv->lock, so this does not change the locking strategy.
Signed-off-by: Mingyu Wang 25181214217@stu.xidian.edu.cn --- Changes in v2: - Drop the unnecessary mutex_lock addition, as the caller (drm_gem_object_release_handle) already holds the lock. - Rewrite the commit message to accurately reflect the root cause (duplicate handle insertions) rather than an assumed lack of synchronization. - Restart the rb_tree lookup from the root instead of breaking the loop to ensure all orphaned duplicate nodes are thoroughly removed.
drivers/gpu/drm/drm_prime.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 9b44c78cd77f..dc28df1c6698 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -202,7 +202,10 @@ void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv,
dma_buf_put(member->dma_buf); kfree(member); - break; + /* Duplicate handles may exist; restart search from root + * to guarantee removal of all matching entries. + */ + rb = prime_fpriv->handles.rb_node; } else if (member->handle < handle) { rb = rb->rb_right; } else {
On 5/28/26 15:29, w15303746062@163.com wrote:
From: Mingyu Wang 25181214217@stu.xidian.edu.cn
When a GEM handle already exists in the drm_prime_file_private, repeated calls to DRM_IOCTL_PRIME_HANDLE_TO_FD can cause drm_prime_add_buf_handle() to insert multiple entries with the same handle into the handles rb_tree. Because the insertion walk moves left on equality, duplicate keys are structurally accepted by the tree.
That should never happen and would be a major bug.
All callers should check if a handler exists before calling drm_prime_add_buf_handle().
How do you see that a handle is added twice?
Regards, Christian.
Later, when the handle is released via drm_gem_release() -> drm_gem_object_release_handle() -> drm_prime_remove_buf_handle(), the latter iterates the handles tree, removes the first matching node, and breaks out of the loop. Any remaining duplicate nodes that share the same handle are left orphaned in the dmabufs tree - they are no longer reachable through the handles tree and are never freed.
When the drm file is finally closed, drm_prime_destroy_file_private() triggers:
WARN_ON(!RB_EMPTY_ROOT(&prime_fpriv->dmabufs));because the dmabufs tree is still non-empty. With CONFIG_PANIC_ON_WARN this becomes a kernel panic:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 19739 at drivers/gpu/drm/drm_prime.c:223 drm_prime_destroy_file_private+0x43/0x60 ... Kernel panic - not syncing: kernel: panic_on_warn set ...Fix this by restarting the lookup from the root of the handles tree after each successful removal, so that all duplicate nodes for the given handle are erased. The caller (drm_gem_object_release_handle) already holds prime_fpriv->lock, so this does not change the locking strategy.
Signed-off-by: Mingyu Wang 25181214217@stu.xidian.edu.cn
Changes in v2:
- Drop the unnecessary mutex_lock addition, as the caller (drm_gem_object_release_handle) already holds the lock.
- Rewrite the commit message to accurately reflect the root cause (duplicate handle insertions) rather than an assumed lack of synchronization.
- Restart the rb_tree lookup from the root instead of breaking the loop to ensure all orphaned duplicate nodes are thoroughly removed.
drivers/gpu/drm/drm_prime.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 9b44c78cd77f..dc28df1c6698 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -202,7 +202,10 @@ void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv,
dma_buf_put(member->dma_buf); kfree(member);
break;
/* Duplicate handles may exist; restart search from root* to guarantee removal of all matching entries.*/rb = prime_fpriv->handles.rb_node; } else if (member->handle < handle) { rb = rb->rb_right; } else {-- 2.34.1
Hi Christian,
Thank you for insisting on this. I've now gone through all callers of drm_prime_add_buf_handle() in drm_prime.c.
You are absolutely right: both drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_dmabuf() perform the lookup under prime_fpriv->lock before adding, so a duplicate handle should indeed never be inserted through those paths.
That said, the syzkaller report clearly shows that the dmabufs tree is not empty when drm_prime_destroy_file_private() runs, which means some entry wasn't removed. Given that the normal add/remove paths appear correct, the trigger might be something more subtle — perhaps a driver-specific callback that bypasses the generic helpers, or an error path that leaves an orphan in the dmabufs tree. I haven't been able to identify the exact trigger yet.
The proposed change to drm_prime_remove_buf_handle() (restart search instead of break) is intended as a small robustness improvement, not a fix for a confirmed race. In the normal case it will still execute only once, but if the trees ever become inconsistent for any reason, it will clean up all entries for the given handle and prevent the WARNING.
Would you be okay with such a defensive approach, or would you prefer that we first track down the precise trigger (e.g. with additional WARNs or tracing)?
Thanks, Mingyu
Hi Mingyu,
On 5/28/26 15:49, w15303746062 wrote:
Hi Christian,
Thank you for insisting on this. I've now gone through all callers of drm_prime_add_buf_handle() in drm_prime.c.
You are absolutely right: both drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_dmabuf() perform the lookup under prime_fpriv->lock before adding, so a duplicate handle should indeed never be inserted through those paths.
That said, the syzkaller report clearly shows that the dmabufs tree is not empty when drm_prime_destroy_file_private() runs, which means some entry wasn't removed. Given that the normal add/remove paths appear correct, the trigger might be something more subtle — perhaps a driver-specific callback that bypasses the generic helpers, or an error path that leaves an orphan in the dmabufs tree. I haven't been able to identify the exact trigger yet.
The proposed change to drm_prime_remove_buf_handle() (restart search instead of break) is intended as a small robustness improvement, not a fix for a confirmed race. In the normal case it will still execute only once, but if the trees ever become inconsistent for any reason, it will clean up all entries for the given handle and prevent the WARNING.
Would you be okay with such a defensive approach, or would you prefer that we first track down the precise trigger (e.g. with additional WARNs or tracing)?
I don't think so. As far as I can see this is not a robustness improvement but just papering over an issue.
Leaking memory is usually only a very minor problem, things like use after free or random memory corruption is much more worse.
And such things is exactly what starts to happens when you start papering over issues.
So I would say find the root cause of what is going on here, you have certainly stumbled over something, and then we can look into how to fix that.
But just sending out random patches where a bit of simple code reading can prove them incorrect is not really helpful.
Regards, Christian.
Thanks, Mingyu
Hi Christian,
Thank you for your guidance and patience throughout this discussion.
After further investigation, I realize that identifying the precise root cause requires a deeper understanding of the DRM subsystem and access to the specific syzkaller reproducer, which I currently lack.
To avoid wasting your time with incomplete patches, I'll step back from this issue for now and continue learning the codebase. If I manage to reproduce the problem locally or find more concrete evidence, I'll follow up with a proper analysis.
Thank you again for the review and the valuable lessons.
Regards, Mingyu
Hello,
kernel test robot noticed "WARNING:possible_recursive_locking_detected" on:
commit: 60a023d26c97753be2beee6062d71ce9416725b1 ("[PATCH] drm/prime: Fix unsupervised rb_tree corruption in drm_prime_remove_buf_handle") url: https://github.com/intel-lab-lkp/linux/commits/w15303746062-163-com/drm-prim... base: https://gitlab.freedesktop.org/drm/misc/kernel.git drm-misc-next patch link: https://lore.kernel.org/all/20260528082912.1051262-1-w15303746062@163.com/ patch subject: [PATCH] drm/prime: Fix unsupervised rb_tree corruption in drm_prime_remove_buf_handle
in testcase: boot
config: x86_64-rhel-9.4-bpf compiler: gcc-14 test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 32G
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot oliver.sang@intel.com | Closes: https://lore.kernel.org/oe-lkp/202605310941.ddd52610-lkp@intel.com
[ 86.630882][ T218] WARNING: possible recursive locking detected [ 86.631312][ T218] 7.1.0-rc2+ #1 Not tainted [ 86.631634][ T218] -------------------------------------------- [ 86.632065][ T218] (udev-worker)/218 is trying to acquire lock: [ 86.632529][ T218] ffff8881ab017388 (&prime_fpriv->lock){+.+.}-{4:4}, at: drm_prime_remove_buf_handle (gpu/drm/drm_prime.c:195) drm [ 86.633434][ T218] [ 86.633434][ T218] but task is already holding lock: [ 86.633951][ T218] ffff8881ab017388 (&prime_fpriv->lock){+.+.}-{4:4}, at: drm_gem_object_release_handle (gpu/drm/drm_gem.c:377) drm [ 86.638664][ T218] [ 86.638664][ T218] other info that might help us debug this: [ 86.639229][ T218] Possible unsafe locking scenario: [ 86.639229][ T218] [ 86.639769][ T218] CPU0 [ 86.640006][ T218] ---- [ 86.640243][ T218] lock(&prime_fpriv->lock); [ 86.640581][ T218] lock(&prime_fpriv->lock); [ 86.640916][ T218] [ 86.640916][ T218] *** DEADLOCK *** [ 86.640916][ T218] [ 86.641480][ T218] May be due to missing lock nesting notation [ 86.641480][ T218] [ 86.642060][ T218] 4 locks held by (udev-worker)/218: [ 86.642446][ T218] #0: ffff8881022921f8 (&dev->mutex){....}-{4:4}, at: __driver_attach (linux/device.h:1040 base/dd.c:1174 base/dd.c:1294) [ 86.643133][ T218] #1: ffff8881ab020260 (&dev->clientlist_mutex){+.+.}-{4:4}, at: drm_client_register (gpu/drm/drm_client.c:129) drm [ 86.644051][ T218] #2: ffff8882a2b58a70 (&helper->lock){+.+.}-{4:4}, at: drm_fb_helper_initial_config (gpu/drm/drm_fb_helper.c:1717 gpu/drm/drm_fb_helper.c:1710) drm_kms_helper [ 86.644930][ T218] #3: ffff8881ab017388 (&prime_fpriv->lock){+.+.}-{4:4}, at: drm_gem_object_release_handle (gpu/drm/drm_gem.c:377) drm [ 86.645880][ T218] [ 86.645880][ T218] stack backtrace: [ 86.646300][ T218] CPU: 1 UID: 0 PID: 218 Comm: (udev-worker) Not tainted 7.1.0-rc2+ #1 PREEMPT(full) [ 86.646307][ T218] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 86.646311][ T218] Call Trace: [ 86.646316][ T218] <TASK> [ 86.646321][ T218] dump_stack_lvl (dump_stack.c:94 dump_stack.c:120) [ 86.646333][ T218] print_deadlock_bug.cold (locking/lockdep.c:3041) [ 86.646341][ T218] validate_chain (locking/lockdep.c:3093 locking/lockdep.c:3895) [ 86.646350][ T218] __lock_acquire (locking/lockdep.c:5237) [ 86.646366][ T218] lock_acquire (trace/events/lock.h:24 (discriminator 15) trace/events/lock.h:24 (discriminator 15) locking/lockdep.c:5831 (discriminator 15)) [ 86.646372][ T218] ? drm_prime_remove_buf_handle (gpu/drm/drm_prime.c:195) drm [ 86.646516][ T218] ? rcu_is_watching (x86/include/asm/atomic.h:23 linux/atomic/atomic-arch-fallback.h:457 linux/context_tracking.h:128 rcu/tree.c:752) [ 86.646521][ T218] ? drm_prime_remove_buf_handle (gpu/drm/drm_prime.c:195) drm [ 86.646659][ T218] ? lock_acquire (trace/events/lock.h:24 (discriminator 21) locking/lockdep.c:5831 (discriminator 21)) [ 86.646665][ T218] __mutex_lock (locking/mutex.c:646 locking/mutex.c:820) [ 86.646675][ T218] ? drm_prime_remove_buf_handle (gpu/drm/drm_prime.c:195) drm [ 86.646814][ T218] ? drm_prime_remove_buf_handle (gpu/drm/drm_prime.c:195) drm [ 86.646952][ T218] ? __mutex_lock (locking/mutex.c:656 locking/mutex.c:820) [ 86.646958][ T218] ? drm_gem_object_release_handle (gpu/drm/drm_gem.c:377) drm [ 86.647103][ T218] ? __pfx___mutex_lock (locking/mutex.c:914) [ 86.647109][ T218] ? __pfx___mutex_lock (locking/mutex.c:914) [ 86.647116][ T218] ? idr_replace (idr.c:304) [ 86.647124][ T218] ? drm_prime_remove_buf_handle (gpu/drm/drm_prime.c:195) drm [ 86.647264][ T218] drm_prime_remove_buf_handle (gpu/drm/drm_prime.c:195) drm [ 86.647408][ T218] drm_gem_object_release_handle (gpu/drm/drm_gem.c:379) drm [ 86.647555][ T218] drm_gem_handle_delete (gpu/drm/drm_gem.c:413) drm [ 86.647700][ T218] drm_client_buffer_create_dumb (gpu/drm/drm_client.c:424) drm [ 86.647840][ T218] ? __pfx_drm_client_buffer_create_dumb (gpu/drm/drm_client.c:267) drm [ 86.647977][ T218] ? drm_fb_helper_single_fb_probe (gpu/drm/drm_fb_helper.c:1414 gpu/drm/drm_fb_helper.c:1445) drm_kms_helper [ 86.648030][ T218] drm_fbdev_shmem_driver_fbdev_probe (gpu/drm/drm_fbdev_shmem.c:151) drm_shmem_helper [ 86.648045][ T218] ? __pfx_drm_fbdev_shmem_driver_fbdev_probe (gpu/drm/drm_fbdev_shmem.c:119) drm_shmem_helper [ 86.648055][ T218] ? __kmalloc_noprof (linux/local_lock_internal.h:62 slub.c:4771 slub.c:4883 slub.c:5294 slub.c:5307) [ 86.648064][ T218] ? rcu_is_watching (x86/include/asm/atomic.h:23 linux/atomic/atomic-arch-fallback.h:457 linux/context_tracking.h:128 rcu/tree.c:752) [ 86.648073][ T218] drm_fb_helper_single_fb_probe (gpu/drm/drm_fb_helper.c:1454) drm_kms_helper [ 86.648121][ T218] ? __pfx_drm_fb_helper_single_fb_probe (gpu/drm/drm_fb_helper.c:1391) drm_kms_helper [ 86.648167][ T218] ? fb_copy_cmap (video/fbdev/core/fbcmap.c:187) [ 86.648174][ T218] ? fb_alloc_cmap_gfp (video/fbdev/core/fbcmap.c:124 (discriminator 1)) [ 86.648180][ T218] __drm_fb_helper_initial_config_and_unlock (gpu/drm/drm_fb_helper.c:1635) drm_kms_helper [ 86.648230][ T218] drm_fbdev_client_hotplug (gpu/drm/clients/drm_fbdev_client.c:66) drm_client_lib [ 86.648239][ T218] drm_client_register (gpu/drm/drm_client.c:143) drm [ 86.648376][ T218] drm_fbdev_client_setup (gpu/drm/clients/drm_fbdev_client.c:168) drm_client_lib [ 86.648383][ T218] drm_client_setup (gpu/drm/clients/drm_client_setup.c:46 gpu/drm/clients/drm_client_setup.c:35) drm_client_lib [ 86.648390][ T218] bochs_pci_probe (gpu/drm/tiny/bochs.c:776 gpu/drm/tiny/bochs.c:747) bochs [ 86.648405][ T218] ? __pfx_bochs_pci_probe (gpu/drm/tiny/bochs.c:254) bochs [ 86.648413][ T218] local_pci_probe (pci/pci-driver.c:325) [ 86.648422][ T218] pci_call_probe (pci/pci-driver.c:387) [ 86.648427][ T218] ? __pfx_pci_call_probe (pci/pci-driver.c:653) [ 86.648432][ T218] ? find_held_lock (locking/lockdep.c:5350) [ 86.648439][ T218] ? pci_match_device (linux/spinlock.h:390 pci/pci-driver.c:156) [ 86.648444][ T218] ? rcu_is_watching (x86/include/asm/atomic.h:23 linux/atomic/atomic-arch-fallback.h:457 linux/context_tracking.h:128 rcu/tree.c:752) [ 86.648448][ T218] ? trace_preempt_on (trace/events/preemptirq.h:53 (discriminator 21) trace/trace_preemptirq.c:120 (discriminator 21)) [ 86.648452][ T218] ? pci_match_id (pci/pci.h:466 pci/pci.h:460 pci/pci-driver.c:110) [ 86.648459][ T218] ? pci_match_device (pci/pci-driver.c:168) [ 86.648465][ T218] pci_device_probe (pci/pci-driver.c:448 pci/pci-driver.c:482) [ 86.648471][ T218] call_driver_probe (base/dd.c:631) [ 86.648477][ T218] really_probe (base/dd.c:709) [ 86.648484][ T218] __driver_probe_device (base/dd.c:871) [ 86.648489][ T218] driver_probe_device (base/dd.c:901) [ 86.648495][ T218] __driver_attach (base/dd.c:1295) [ 86.648500][ T218] ? __pfx___driver_attach (base/dd.c:1004 (discriminator 1)) [ 86.648504][ T218] bus_for_each_dev (base/bus.c:383) [ 86.648511][ T218] ? __pfx_bus_for_each_dev (base/bus.c:205) [ 86.648516][ T218] ? bus_add_driver (base/bus.c:754) [ 86.648520][ T218] ? trace_preempt_on (trace/events/preemptirq.h:53 (discriminator 21) trace/trace_preemptirq.c:120 (discriminator 21)) [ 86.648526][ T218] bus_add_driver (base/bus.c:756) [ 86.648532][ T218] driver_register (base/driver.c:249) [ 86.648538][ T218] ? __pfx_bochs_pci_driver_init (bochs.c:?) bochs [ 86.648548][ T218] do_one_initcall (main.c:1392) [ 86.648555][ T218] ? __pfx_do_one_initcall (trace/events/initcall.h:10) [ 86.648561][ T218] ? kasan_unpoison (kasan/shadow.c:146 kasan/shadow.c:178) [ 86.648568][ T218] ? __kasan_slab_alloc (kasan/common.c:336 kasan/common.c:366) [ 86.648575][ T218] ? rcu_is_watching (x86/include/asm/atomic.h:23 linux/atomic/atomic-arch-fallback.h:457 linux/context_tracking.h:128 rcu/tree.c:752) [ 86.648579][ T218] ? kasan_unpoison (kasan/shadow.c:146 kasan/shadow.c:178) [ 86.648586][ T218] do_init_module (module/main.c:3106) [ 86.648594][ T218] ? __pfx_do_init_module (trace/events/module.h:50 (discriminator 1)) [ 86.648599][ T218] ? load_module (module/main.c:2528 module/main.c:2523 module/main.c:3575) [ 86.648603][ T218] ? kfree (linux/kasan.h:235 slub.c:2689 slub.c:6250 slub.c:6565) [ 86.648611][ T218] load_module (module/main.c:3580) [ 86.648620][ T218] ? __pfx_load_module (module/main.c:3020) [ 86.648626][ T218] ? __pfx_kernel_read_file (??:?) [ 86.648632][ T218] ? do_syscall_64 (linux/irq-entry-common.h:279 linux/entry-common.h:320 x86/entry/syscall_64.c:100) [ 86.648640][ T218] init_module_from_file (module/main.c:3777) [ 86.648646][ T218] ? __pfx_init_module_from_file (module/main.c:3634) [ 86.648656][ T218] ? idempotent_init_module (linux/spinlock.h:390 module/main.c:3688 module/main.c:3788) [ 86.648661][ T218] ? rcu_is_watching (x86/include/asm/atomic.h:23 linux/atomic/atomic-arch-fallback.h:457 linux/context_tracking.h:128 rcu/tree.c:752) [ 86.648664][ T218] ? trace_preempt_on (trace/events/preemptirq.h:53 (discriminator 21) trace/trace_preemptirq.c:120 (discriminator 21)) [ 86.648669][ T218] ? preempt_count_sub (sched/core.c:5874 (discriminator 2) sched/core.c:5871 (discriminator 2) sched/core.c:5893 (discriminator 2)) [ 86.648676][ T218] idempotent_init_module (module/main.c:3789) [ 86.648682][ T218] ? __pfx_idempotent_init_module (module/main.c:3778) [ 86.648687][ T218] ? preempt_count_sub (sched/core.c:5874 (discriminator 2) sched/core.c:5871 (discriminator 2) sched/core.c:5893 (discriminator 2)) [ 86.648696][ T218] ? security_capable (security.c:660 (discriminator 20)) [ 86.648702][ T218] __x64_sys_finit_module (module/main.c:3815 module/main.c:3799 module/main.c:3799) [ 86.648708][ T218] do_syscall_64 (x86/entry/syscall_64.c:63 x86/entry/syscall_64.c:94) [ 86.648713][ T218] ? rcu_is_watching (x86/include/asm/atomic.h:23 linux/atomic/atomic-arch-fallback.h:457 linux/context_tracking.h:128 rcu/tree.c:752) [ 86.648717][ T218] ? trace_preempt_on (trace/events/preemptirq.h:53 (discriminator 21) trace/trace_preemptirq.c:120 (discriminator 21)) [ 86.648720][ T218] ? do_syscall_64 (linux/randomize_kstack.h:58 x86/entry/syscall_64.c:92) [ 86.648725][ T218] ? preempt_count_sub (sched/core.c:5874 (discriminator 2) sched/core.c:5871 (discriminator 2) sched/core.c:5893 (discriminator 2)) [ 86.648730][ T218] ? do_syscall_64 (linux/randomize_kstack.h:58 x86/entry/syscall_64.c:92) [ 86.648734][ T218] ? irqentry_exit (linux/irq-entry-common.h:280 linux/irq-entry-common.h:325 entry/common.c:162) [ 86.648740][ T218] entry_SYSCALL_64_after_hwframe (x86/entry/entry_64.S:121) [ 86.648747][ T218] RIP: 0033:0x7f3757f90779 [ 86.648768][ T218] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 4f 86 0d 00 f7 d8 64 89 01 48 All code ======== 0: ff c3 inc %ebx 2: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) 9: 00 00 00 c: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 11: 48 89 f8 mov %rdi,%rax 14: 48 89 f7 mov %rsi,%rdi 17: 48 89 d6 mov %rdx,%rsi 1a: 48 89 ca mov %rcx,%rdx 1d: 4d 89 c2 mov %r8,%r10 20: 4d 89 c8 mov %r9,%r8 23: 4c 8b 4c 24 08 mov 0x8(%rsp),%r9 28: 0f 05 syscall 2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax <-- trapping instruction 30: 73 01 jae 0x33 32: c3 ret 33: 48 8b 0d 4f 86 0d 00 mov 0xd864f(%rip),%rcx # 0xd8689 3a: f7 d8 neg %eax 3c: 64 89 01 mov %eax,%fs:(%rcx) 3f: 48 rex.W
The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20260531/202605310941.ddd52610-lkp@i...
linaro-mm-sig@lists.linaro.org
-
Christian König -
kernel test robot -
w15303746062 -
w15303746062＠163.com