RE: [PATCH v2 3/5] dax: improve documentation for fsync/msync

From: Elliott, Robert (Persistent Memory)
Date: Fri Jan 22 2016 - 11:18:21 EST




---
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.