> >>> The list is protected by encl->srcu, not RCU, so the SRCU-specific
> >>> iterator with srcu_read_lock_held() annotation is required.
> >>>
> >>> Signed-off-by: Li RongQing <[email protected]>
> >> Acked-by: Kai Huang <[email protected]>
> > Thanks for reviewing , and ping
>
> It's a light NAK from me with the current changelog.
>
> I want a wee bit more background and some reasoning _somewhere_ about
> why this wasn't a bug when the code went in originally but arguably became a
> buglet at some point.
The buggy commit is 1728ab54b4be ("x86/sgx: Add a page reclaimer") in v5.11, it
should use list_for_each_entry_srcu()which is introduced in v5.10, so I rewrite
the commit message as below, is it ok?
x86/sgx: Use list_for_each_entry_srcu() for mm_list traversal
In commit 1728ab54b4be ("x86/sgx: Add a page reclaimer") (v5.11),
list_for_each_entry_rcu() was used to traverse the enclave's mm_list.
However, this is incorrect because the list is protected by a Sleepable
RCU (SRCU) lock (encl->srcu).
Since commit 28875945ba98 ("rcu: Add support for consolidated-RCU reader
checking") (v5.4), RCU lockdep checking has become stricter. When
CONFIG_PROVE_RCU is enabled, using the standard list_for_each_entry_rcu()
while only holding an SRCU lock triggers "suspicious RCU usage" false
positive warnings, as it does not recognize SRCU read-side critical
sections.
Fix this by switching to list_for_each_entry_srcu(), which was
introduced specifically for this purpose in commit ae2212a7216
("rculist: Introduce list/hlist_for_each_entry_srcu() macros") (v5.10).
This correctly associates the traversal with the SRCU lock and
eliminates the lockdep warnings.
Fixes: 1728ab54b4be ("x86/sgx: Add a page reclaimer")
Signed-off-by: Li RongQing <[email protected]>
