Re: [PATCH v2] mm/page_reporting: replace rcu_access_pointer() with rcu_dereference_protected()
From: SeongJae Park
Date: Tue Dec 27 2022 - 21:09:33 EST
On Wed, 28 Dec 2022 09:45:00 +0800 Miaohe Lin <linmiaohe@xxxxxxxxxx> 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@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?
You're right, thank you for finding this.
I will fix these in the next version.
Thanks,
SJ
>
> Thanks,
> Miaohe Lin