[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <752651d1-7cca-45b8-b5ac-9c32ab97e9fd@lucifer.local>
Date: Fri, 18 Apr 2025 11:50:12 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Ye Liu <ye.liu@...ux.dev>, akpm@...ux-foundation.org,
nao.horiguchi@...il.com, linmiaohe@...wei.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Liam.Howlett@...cle.com, harry.yoo@...cle.com, riel@...riel.com,
vbabka@...e.cz, liuye@...inos.cn
Subject: Re: [PATCH v2 1/2] mm/rmap: rename page__anon_vma to page_anon_vma
for consistency
On Fri, Apr 18, 2025 at 12:40:10PM +0200, David Hildenbrand wrote:
> On 18.04.25 11:55, Ye Liu wrote:
> > From: Ye Liu <liuye@...inos.cn>
> >
> > Renamed local variable page__anon_vma in page_address_in_vma() to
> > page_anon_vma. The previous naming convention of using double underscores
> > (__) is unnecessary and inconsistent with typical kernel style, which uses
> > single underscores to denote local variables. Also updated comments to
> > reflect the new variable name.
> >
> > Functionality unchanged.
> >
> > Signed-off-by: Ye Liu <liuye@...inos.cn>
> > ---
> > mm/rmap.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index 67bb273dfb80..b509c226e50d 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -789,13 +789,13 @@ unsigned long page_address_in_vma(const struct folio *folio,
> > const struct page *page, const struct vm_area_struct *vma)
> > {
> > if (folio_test_anon(folio)) {
> > - struct anon_vma *page__anon_vma = folio_anon_vma(folio);
> > + struct anon_vma *page_anon_vma = folio_anon_vma(folio);
>
> I'm extremely confused why this should not simply be called "anon_vma". Why
> do we need the "page" in here *at all* ?
Presumably to differentiate from the VMA's anon_vma, but it seems redundant
and silly to preface it as the page's (really, folio's) anon_vma.
The original patch is strictly an improvement so I'm fine with that, but we
could also rename this to anon_vma to make the function a little simpler to
read.
I guess the key bit where this becomes vaguely relevant is:
vma->anon_vma->root != page_anon_vma->root
This whole thing seems to be to deal with races with unuse_vma() as per the
comment.
Anyway, TL;DR: fine with that rename if we want it!
>
> --
> Cheers,
>
> David / dhildenb
>
Powered by blists - more mailing lists