linux-kernel - 答复: [外部邮件] Re: [PATCH] x86/sgx: Fix SRCU list traversal

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] [day] [month] [year] [list]

Message-ID: <cd326e6b8aa745688628bfcef94aa9b9@baidu.com>
Date: Thu, 5 Feb 2026 21:15:40 +0000
From: "Li,Rongqing" <lirongqing@...du.com>
To: Dave Hansen <dave.hansen@...el.com>, Jarkko Sakkinen <jarkko@...nel.org>,
	Dave Hansen <dave.hansen@...ux.intel.com>, Thomas Gleixner <tglx@...nel.org>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	"x86@...nel.org" <x86@...nel.org>, "H . Peter Anvin" <hpa@...or.com>,
	"linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: 答复: [外部邮件] Re: [PATCH] x86/sgx: Fix SRCU list traversal

> On 2/4/26 17:53, lirongqing wrote:
> > Replace list_for_each_entry_rcu() with list_for_each_entry_srcu() when
> > traversing the encl->mm_list protected by SRCU. This ensures proper
> > synchronization annotation and avoids potential lockdep warnings about
> > incorrect RCU usage.
> 
> Does lockdep trip on this today?
> 
> > The list is protected by encl->srcu, not RCU, so the SRCU-specific
> > iterator with srcu_read_lock_held() annotation is required.
> 
> From a quick look, list_for_each_entry_rcu() still seems *really* common
> under SRCU. It also looks like list_for_each_entry_srcu() is a relatively recent
> (2020) addition to the kernel.
> 
> So, this wasn't a bug when the SGX code went in, but started causing a
> problem at some point? Did lockdep add some RCU warnings or something
> that made this necessary?
> 
> The patch seems logical and all. I just feel like I'm missing the bigger picture.

Seem this patch adds the check

commit 28875945ba98d1b47a8a706812b6494d165bb0a0
Author: Joel Fernandes (Google) <joel@...lfernandes.org>
Date:   Tue Jul 16 18:12:22 2019 -0400

    rcu: Add support for consolidated-RCU reader checking

    This commit adds RCU-reader checks to list_for_each_entry_rcu() and
    hlist_for_each_entry_rcu().  These checks are optional, and are indicated
    by a lockdep expression passed to a new optional argument to these two
    macros.  If this optional lockdep expression is omitted, these two macros
    act as before, checking for an RCU read-side critical section.

    Signed-off-by: Joel Fernandes (Google) <joel@...lfernandes.org>
    [ paulmck: Update to eliminate return within macro and update comment. ]
    Signed-off-by: Paul E. McKenney <paulmck@...ux.ibm.com>


And there are several similar fixes:

d681107 nvme-multipath: fix suspicious RCU usage warning
5dd18f0 nvme/multipath: Fix RCU list traversal to use SRCU primitive
6d1c699 nvme/host: Fix RCU list traversal to use SRCU primitive
6a0c617 KVM: eventfd: Fix false positive RCU usage warning
df9a30f kvm: mmu: page_track: Fix RCU list API usage

[Li,Rongqing]