[BUG] rcu: stall detected in kcov_ioctl() involving DRM vblank and file release paths

[BUG] rcu: stall detected in kcov_ioctl() involving DRM vblank and file release paths

[WangzXD0325]

Hello,

I am reporting an RCU stall detected during syzkaller-style fuzz testing.
The stall is reported while executing kcov_ioctl(), and eventually
involves DRM vblank handling and DRM file release paths, leading to
RCU grace-period starvation.

=== Summary ===
The kernel reports an RCU stall with:
"INFO: rcu detected stall in kcov_ioctl"
The stall persists for more than 10 seconds and results in the
rcu_preempt grace-period kthread being starved. Multiple CPUs are
observed spinning in native_queued_spin_lock_slowpath(), including
DRM-related interrupt and file-release paths.

=== Environment ===
Kernel: 6.18.0 (locally built)
Config: PREEMPT(full)
Arch: x86_64
Hardware: QEMU Standard PC (i440FX + PIIX)
Workload: syz-executor (syzkaller-style fuzzing)

=== Triggering context ===
The stall is detected while a userspace syzkaller executor invokes
kcov_ioctl(). The call path includes large vmalloc allocations:
kcov_ioctl
vmalloc_user_noprof
__vmalloc_node_range_noprof
alloc_vmap_area
kasan_populate_vmalloc
alloc_pages_bulk_noprof
At the same time, other CPUs are executing DRM-related paths.

=== Warning details ===
RCU reports:
INFO: rcu_preempt detected stalls on CPUs/tasks
rcu_preempt kthread starved for over 10000 jiffies
Unless rcu_preempt kthread gets sufficient CPU time,
OOM is now expected behavior.

=== Call trace ===
CPU 0 (IRQ context):
native_queued_spin_lock_slowpath
drm_handle_vblank
vkms_vblank_simulate
hrtimer_interrupt
CPU 1 (task context):
native_queued_spin_lock_slowpath
drm_file_free
drm_close_helper
drm_release
__fput
RCU GP kthread:
rcu_gp_fqs_loop
rcu_gp_kthread

=== Observations ===
The issue appears to be caused by an interaction between:
Long-running memory allocation and vmalloc paths triggered by kcov_ioctl()
DRM (vkms) vblank interrupt handling holding spinlocks
DRM file release paths acquiring the same or related locks
PREEMPT(full) configuration amplifying scheduling latency
This results in CPUs spinning on contended spinlocks while the
rcu_preempt kthread is unable to obtain sufficient CPU time to
advance the grace period.

=== Reproducer ===
No standalone reproducer is currently available.
The issue was observed during syzkaller-style fuzz testing.

=== Expected behavior ===
Invoking kcov_ioctl(), even under heavy or malformed fuzzing workloads,
should not lead to prolonged RCU stalls or starvation of the RCU
grace-period kthread.

=== Actual behavior ===
RCU reports prolonged stalls, multiple CPUs spin in
native_queued_spin_lock_slowpath(), and the rcu_preempt kthread is
starved for over 10 seconds.

=== Notes ===
Full kernel logs and configuration can be provided upon request.
Please let me know if additional instrumentation or debugging would
be helpful.

Reported-by:
Zhi Wang