Re: [PATCH v2] mm/page_reporting: replace rcu_access_pointer() with rcu_dereference_protected()

[SeongJae Park <sj@kernel.org>]

On Wed, 28 Dec 2022 09:45:00 +0800 Miaohe Lin <linmiaohe@huawei.com> wrote:

> 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/

Thank you!  I shall add these to scripts/spelling.txt.

> 
> > 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@kernel.org>
> > ---
> > Changes from v1
> > (https://lore.kernel.org/linux-mm/20221227192158.2553-1-sj@kernel.org/)
> > - 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?

You're right, thank you for finding this.

I will fix these in the next version.


Thanks,
SJ

> 
> Thanks,
> Miaohe Lin