[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YNSqHzKM5oi2XSxZ@casper.infradead.org>
Date: Thu, 24 Jun 2021 16:51:59 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 02/46] mm: Add folio_rmapping()
On Wed, Jun 23, 2021 at 09:56:58AM +0200, Christoph Hellwig wrote:
> > +static inline void *folio_rmapping(struct folio *folio)
>
> This name, just like the old one is not exaclty descriptive. I guess the
> r stands for raw somehow? As a casual contributor to the fringes of the
> MM I would have no idea when to use it.
>
> All this of course also applies to the existing (__)page_rmapping, but
> maybe this is a good time to sort it out.
Yes, good point. I don't like the name rmapping either, since
we already have rmap which has nothing to do with this. I'll
leave page_rmapping() alone for now; no need to add that churn.
I think they all become calls to folio_raw_mapping() later.
> >
> > struct anon_vma *page_anon_vma(struct page *page)
> > {
> > + struct folio *folio = page_folio(page);
> > + unsigned long mapping = (unsigned long)folio->mapping;
> >
> > if ((mapping & PAGE_MAPPING_FLAGS) != PAGE_MAPPING_ANON)
> > return NULL;
> > + return folio_rmapping(folio);
>
> It feelds kinda silly to not just open code folio_rmapping here
> given that we alredy went half the way.
Yeah, I thought about that too. Done:
- return folio_rmapping(folio);
+ return (void *)(mapping - PAGE_MAPPING_ANON);
Powered by blists - more mailing lists