linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Anton Salikhmetov" <salikhmetov@gmail.com>
To: Rogier Wolff <R.E.Wolff@bitwizard.nl>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	linux-mm@kvack.org, jakob@unthought.net,
	linux-kernel@vger.kernel.org, valdis.kletnieks@vt.edu,
	riel@redhat.com, ksm@42.dk, staubach@redhat.com,
	jesper.juhl@gmail.com, torvalds@linux-foundation.org,
	a.p.zijlstra@chello.nl, akpm@linux-foundation.org,
	protasnb@gmail.com, hidave.darkstar@gmail.com, hch@infradead.org
Subject: Re: [PATCH -v5 2/2] Updating ctime and mtime at syncing
Date: Thu, 17 Jan 2008 16:34:22 +0300	[thread overview]
Message-ID: <4df4ef0c0801170534w3b019a07g1e1f493d76350e3d@mail.gmail.com> (raw)
In-Reply-To: <20080117132429.GB14692@bitwizard.nl>

2008/1/17, Rogier Wolff <R.E.Wolff@bitwizard.nl>:
> On Thu, Jan 17, 2008 at 04:16:47PM +0300, Anton Salikhmetov wrote:
> > 2008/1/17, Miklos Szeredi <miklos@szeredi.hu>:
> > > > > 4. Recording the time was the file data changed
> > > > >
> > > > > Finally, I noticed yet another issue with the previous version of my patch.
> > > > > Specifically, the time stamps were set to the current time of the moment
> > > > > when syncing but not the write reference was being done. This led to the
> > > > > following adverse effect on my development system:
> > > > >
> > > > > 1) a text file A was updated by process B;
> > > > > 2) process B exits without calling any of the *sync() functions;
> > > > > 3) vi editor opens the file A;
> > > > > 4) file data synced, file times updated;
> > > > > 5) vi is confused by "thinking" that the file was changed after 3).
> > >
> > > Updating the time in remove_vma() would fix this, no?
> >
> > We need to save modification time. Otherwise, updating time stamps
> > will be confusing the vi editor.
>
> If process B exits before vi opens the file, the timestamp should at
> the latest be the time that process B exits. There is no excuse for
> setting the timestamp later than the time that B exits.
>
> If process B no longer modifies the file, but still keeps it mapped
> until after vi starts, then the system can't help the
> situation. Wether or not B acesses those pages is unknown to the
> system. So you get what you deserve.

The exit() system call closes the file memory-mapped file. Therefore,
it's better to catch the close() system call. However, the close() system call
does not trigger unmapping the file. The mapped area for the file may be
used after closing the file. So, we should catch only the unmap() call,
not close() or exit().

>
>         Roger.
>
> --
> ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
> **    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
> *-- BitWizard writes Linux device drivers for any device you may have! --*
> Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
> Does it sit on the couch all day? Is it unemployed? Please be specific!
> Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-01-17 13:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-17  0:57 [PATCH -v5 0/2] Updating ctime and mtime for memory-mapped files Anton Salikhmetov
2008-01-17  0:57 ` [PATCH -v5 1/2] Massive code cleanup of sys_msync() Anton Salikhmetov
2008-01-17 11:01   ` Miklos Szeredi
2008-01-17 11:47     ` Anton Salikhmetov
2008-01-17  0:57 ` [PATCH -v5 2/2] Updating ctime and mtime at syncing Anton Salikhmetov
2008-01-17 11:13   ` Miklos Szeredi
2008-01-17 12:16     ` Anton Salikhmetov
2008-01-17 12:45       ` Miklos Szeredi
2008-01-17 12:51         ` Rogier Wolff
2008-01-17 13:16         ` Anton Salikhmetov
2008-01-17 13:24           ` Rogier Wolff
2008-01-17 13:34             ` Anton Salikhmetov [this message]
2008-01-17 13:33           ` Miklos Szeredi
2008-01-17 13:40             ` Anton Salikhmetov
2008-01-17 15:45               ` Miklos Szeredi
2008-01-17 16:20                 ` Anton Salikhmetov
2008-01-17 16:26                   ` Miklos Szeredi
2008-01-17 16:33                     ` Anton Salikhmetov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4df4ef0c0801170534w3b019a07g1e1f493d76350e3d@mail.gmail.com \
    --to=salikhmetov@gmail.com \
    --cc=R.E.Wolff@bitwizard.nl \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=hidave.darkstar@gmail.com \
    --cc=jakob@unthought.net \
    --cc=jesper.juhl@gmail.com \
    --cc=ksm@42.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=protasnb@gmail.com \
    --cc=riel@redhat.com \
    --cc=staubach@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=valdis.kletnieks@vt.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).