Re: [PATCH][RFC][BUG] updating the ctime and mtime time stamps inmsync()

[Peter Staubach]

Anton Salikhmetov wrote:
> 2008/1/10, Rik van Riel <riel@xxxxxxxxxx>:
>   
> > On Thu, 10 Jan 2008 18:56:07 +0300
> > "Anton Salikhmetov" <salikhmetov@xxxxxxxxx> wrote:
> >
> >     
> > > However, I don't see how they will work if there has been
> > > something like a sync(2) done after the mmap'd region is
> > > modified and the msync call.  When the inode is written out
> > > as part of the sync process, I_DIRTY_PAGES will be cleared,
> > > thus causing a miss in this code.
> > >
> > > The I_DIRTY_PAGES check here is good, but I think that there
> > > needs to be some code elsewhere too, to catch the case where
> > > I_DIRTY_PAGES is being cleared, but the time fields still need
> > > to be updated.
> > >       
> > Agreed. The mtime and ctime should probably also be updated
> > when I_DIRTY_PAGES is cleared.
> >
> > The alternative would be to remember that the inode had been
> > dirty in the past, and have the mtime and ctime updated on
> > msync or close - which would be more complex.
> >     
>
> Adding the new flag (AS_MCTIME) has been already suggested by Peter
> Staubach in his first solution for this bug. Now I understand that the
> AS_MCTIME flag is required for fixing the bug.

Well, that was the approach before we had I_DIRTY_PAGES.  I am
still wondering whether we can get this approach to work, with
a little more support and heuristics.  PeterZ's work to better
track dirty pages should be helpful in determining when and why
a patch was dirty.

I keep thinking that by recording the time when a page was found
to be dirty and the file is mmap'd and then updating the mtime
and ctime fields in the inode during msync() and sync_single_inode()
if that time is newer than the mtime and ctime fields, then we
can solve the problem of when and when not to update those two
time fields.

I haven't had a chance to think it all through completely or do
the appropriate analysis yet though.

      ps
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/