--- Robert Elliott, HPE Persistent Memory > -----Original Message----- > From: Linux-nvdimm [mailto:linux-nvdimm-bounces@xxxxxxxxxxxx] On Behalf Of > Ross Zwisler > Sent: Friday, January 22, 2016 9:58 AM > To: Jan Kara <jack@xxxxxxx> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>; linux-nvdimm@xxxxxxxxxxxx; > Dave Chinner <david@xxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; > Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>; Jan Kara <jack@xxxxxxxx>; linux- > fsdevel@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v2 3/5] dax: improve documentation for fsync/msync > > On Fri, Jan 22, 2016 at 04:01:29PM +0100, Jan Kara wrote: > > On Thu 21-01-16 10:46:02, Ross Zwisler wrote: ... > > > diff --git a/fs/dax.c b/fs/dax.c > > > index d589113..55ae394 100644 > > > --- a/fs/dax.c > > > +++ b/fs/dax.c > > > @@ -350,6 +350,13 @@ static int dax_radix_entry(struct address_space > *mapping, pgoff_t index, > > > > > > if (!pmd_entry || type == RADIX_DAX_PMD) > > > goto dirty; > > > + > > > + /* > > > + * We only insert dirty PMD entries into the radix tree. This > > > + * means we don't need to worry about removing a dirty PTE > > > + * entry and inserting a clean PMD entry, thus reducing the > > > + * range we would flush with a follow-up fsync/msync call. > > > + */ > > > > May be acompany this with: > > > > WARN_ON(pmd_entry && !dirty); > > > > somewhere in dax_radix_entry()? > > Sure, I'll add one. If this is something that could trigger due to I/O traffic, please use WARN_ONCE rather than WARN_ON to avoid the risk of swamping the serial output. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
