Re: [BUG] RCU Detected Stall in sys_process_vm_writev

[David Hildenbrand <david@redhat.com>]

On 19.05.25 07:19, Guoyu Yin wrote:
> Hi,
> 
> I discovered a kernel crash using the Syzkaller framework, described
> as "INFO: rcu detected stall in sys_process_vm_writev". This issue
> occurs during the execution of the sys_process_vm_writev system call,
> where RCU detects a stall on CPU 0.
> 
>  From the dmesg log, CPU 3 is stuck trying to acquire a spinlock in the
> pgd_free function (arch/x86/mm/pgtable.c:490), leading to the RCU
> stall. This is likely caused by spinlock contention triggered by the
> page pinning and unpinning logic in sys_process_vm_writev under high
> load or abnormal conditions.

pgd_free() calls pgd_dtor() where we should be taking the pgd_lock. 
Apart from that, only the buddy allocator might be taking locks when 
freeing the page.

> 
> I recommend reviewing the page pinning (pin_user_pages_remote) and
> unpinning (unpin_user_pages_dirty_lock) logic in
> process_vm_rw_single_vec (mm/process_vm_access.c) to ensure it does
> not cause prolonged spinlock blocking due to scheduling delays or
> resource contention.

This almost reads like AI generated content.

Anyhow, unpin_user_pages_dirty_lock() should only be taking the folio 
lock, and pin_user_pages_remote() should only be taking page table locks.

As I am sure you wouldn't bother us with AI generated slop, what makes 
you think that the pgd_lock is relevant in the context of GUP?

-- 
Cheers,

David / dhildenb