On 2022/12/28 9:29, SeongJae Park wrote: > Page reporting fetches pr_dev_info using rcu_access_pointer(), which is > for safely fetching a pointer that will not be dereferenced but could > concurrently updated. The code indeed does not dereference pr_dev_info > after fetcing it using rcu_access_pointer(), but it fetches the pointer Thanks for your work. Might something to improve. s/fetcing/fetching/ > while concurrent updtes to the pointer is avoided by holding the update s/updtes/updates/ > side lock, page_reporting_mutex. > > In the case, rcu_dereference_protected() is recommended because it > provides better readability and performance on some cases, as > rcu_dereference_protected() avoids use of READ_ONCE(). Replace the > rcu_access_pointer() calls with rcu_dereference_protected(). > > Signed-off-by: SeongJae Park <sj@xxxxxxxxxx> > --- > Changes from v1 > (https://lore.kernel.org/linux-mm/20221227192158.2553-1-sj@xxxxxxxxxx/) > - Explicitly set the protection condition (Matthew Wilcox) > > mm/page_reporting.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/mm/page_reporting.c b/mm/page_reporting.c > index 79a8554f024c..5c557a3e1423 100644 > --- a/mm/page_reporting.c > +++ b/mm/page_reporting.c > @@ -356,7 +356,8 @@ int page_reporting_register(struct page_reporting_dev_info *prdev) > mutex_lock(&page_reporting_mutex); > > /* nothing to do if already in use */ > - if (rcu_access_pointer(pr_dev_info)) { > + if (rcu_dereference_protected(pr_dev_info, > + lockdep_is_held(&page_reporting_order))) { I think it should be lockdep_is_held(&page_reporting_mutex) instead of lockdep_is_held(&page_reporting_order) here? Thanks, Miaohe Lin
