linux-kernel - Re: [BUG] RCU Detected Stall in sys_process_vm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <14bbdbd4-fa86-4317-a051-8e1defc7192e@redhat.com>
Date: Mon, 19 May 2025 09:36:55 +0200
From: David Hildenbrand <david@...hat.com>
To: Guoyu Yin <y04609127@...il.com>, akpm@...ux-foundation.org
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org,
 tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, x86@...nel.org,
 hpa@...or.com
Subject: Re: [BUG] RCU Detected Stall in sys_process_vm_writev

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