[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YepdxZ+XrAZYv1dX@infradead.org>
Date: Thu, 20 Jan 2022 23:16:21 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Shiyang Ruan <ruansy.fnst@...itsu.com>
Cc: Christoph Hellwig <hch@...radead.org>,
linux-kernel@...r.kernel.org, linux-xfs@...r.kernel.org,
nvdimm@...ts.linux.dev, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, djwong@...nel.org,
dan.j.williams@...el.com, david@...morbit.com, jane.chu@...cle.com
Subject: Re: [PATCH v9 10/10] fsdax: set a CoW flag when associate reflink
mappings
On Fri, Jan 21, 2022 at 10:33:58AM +0800, Shiyang Ruan wrote:
> >
> > But different question, how does this not conflict with:
> >
> > #define PAGE_MAPPING_ANON 0x1
> >
> > in page-flags.h?
>
> Now we are treating dax pages, so I think its flags should be different from
> normal page. In another word, PAGE_MAPPING_ANON is a flag of rmap mechanism
> for normal page, it doesn't work for dax page. And now, we have dax rmap
> for dax page. So, I think this two kinds of flags are supposed to be used
> in different mechanisms and won't conflect.
It just needs someone to use folio_test_anon in a place where a DAX
folio can be passed. This probably should not happen, but we need to
clearly document that.
> > Either way I think this flag should move to page-flags.h and be
> > integrated with the PAGE_MAPPING_FLAGS infrastucture.
>
> And that's why I keep them in this dax.c file.
But that does not integrate it with the infrastructure. For people
to debug things it needs to be next to PAGE_MAPPING_ANON and have
documentation explaining why they are exclusive.
Powered by blists - more mailing lists