linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Gerrit Huizenga <gh@us.ibm.com>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: Dave McCracken <dmccr@us.ibm.com>, Andrew Morton <akpm@digeo.com>,
	mika.penttila@kolumbus.fi, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: Race between vmtruncate and mapped areas?
Date: Wed, 14 May 2003 09:42:45 -0700	[thread overview]
Message-ID: <E19FzL3-0007Gk-00@w-gerrit2> (raw)
In-Reply-To: Your message of Wed, 14 May 2003 08:06:53 PDT. <20030514150653.GM8978@holomorphy.com>

On Wed, 14 May 2003 08:06:53 PDT, William Lee Irwin III wrote:
> On Tuesday, May 13, 2003 18:10:18 -0700 Andrew Morton <akpm@digeo.com> wrote:
> >> That's the one.  Process is sleeping on I/O in filemap_nopage(), wakes up
> >> after the truncate has done its thing and the page gets instantiated in
> >> pagetables.
> >> But it's an anon page now.  So the application (which was racy anyway)
> >> gets itself an anonymous page.
> 
> On Wed, May 14, 2003 at 10:02:10AM -0500, Dave McCracken wrote:
> > Which the application thinks is still part of the file, and will expect its
> > changes to be written back.  Granted, if the page fault occurred just after
> > the truncate it'd get SIGBUS, so it's clearly not a robust assumption, but
> > it will result in unexpected behavior.  Note that if the application later
> > extends the file to include this page it could result in a corrupted file,
> > since all the pages around it will be written properly.
> 
> Well, for this one I'd say the app loses; it was its own failure to
> synchronize truncation vs. access, at least given that the kernel
> doesn't oops.

Hmm...  I'd disagree... The operations of truncation and access should
be synchronized with respect to the mm, even if multiple threads are
performing the operations.  The application *should* have synchronization
to understand which event will happen first, but the principle of least
surprise would suggest that either the access would happen first
followed by truncation (and future access might then extend the file,
putting in zero'd pages for the range that was trunacated) or the
truncation will happen first, and the access (beyond the new end
of the file) will behave as a normal access beyond the end of file.

Having truly garbage data between the previous end of file and the
new end of file is just wrong.

gerrit
--
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:"aart@kvack.org"> aart@kvack.org </a>

  parent reply	other threads:[~2003-05-14 16:42 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-13 20:44 Dave McCracken
2003-05-13 20:58 ` Mika Penttilä
2003-05-13 21:04   ` William Lee Irwin III
2003-05-13 22:26   ` Dave McCracken
2003-05-13 22:49     ` William Lee Irwin III
2003-05-13 23:00       ` Dave McCracken
2003-05-13 23:11         ` William Lee Irwin III
2003-05-13 23:16           ` Dave McCracken
2003-05-13 23:20             ` William Lee Irwin III
2003-05-13 23:28               ` Dave McCracken
2003-05-13 23:29                 ` William Lee Irwin III
2003-05-13 23:16         ` William Lee Irwin III
2003-05-14  1:10         ` Andrew Morton
2003-05-14 15:02           ` Dave McCracken
2003-05-14  1:10     ` Andrew Morton
2003-05-14 15:02       ` Dave McCracken
2003-05-14 15:06         ` William Lee Irwin III
2003-05-14 15:25           ` Dave McCracken
2003-05-14 16:42           ` Gerrit Huizenga [this message]
2003-05-14 17:34         ` Andrew Morton
2003-05-14 17:42           ` Dave McCracken
2003-05-14 17:57             ` Andrew Morton
2003-05-14 18:05               ` Dave McCracken
2003-05-14 18:17                 ` Andrew Morton
2003-05-14 18:24                   ` Dave McCracken
2003-05-14 18:53                     ` Andrew Morton
2003-05-15  8:50                       ` Andrea Arcangeli
2003-05-14 19:02               ` Rik van Riel
2003-05-14 19:04                 ` Rik van Riel
2003-05-14 19:07                   ` Dave McCracken
2003-05-14 19:11                     ` Rik van Riel
2003-05-15  0:49             ` Andrea Arcangeli
2003-05-15  2:36               ` Rik van Riel
2003-05-15  9:46                 ` Andrea Arcangeli
2003-05-15  9:55                   ` Andrew Morton
2003-05-15  8:32               ` Andrew Morton
2003-05-15  8:42                 ` Andrew Morton
2003-05-15  8:55                 ` Andrea Arcangeli
2003-05-15  9:20                   ` Andrew Morton
2003-05-15  9:40                     ` Andrea Arcangeli
2003-05-15  9:58                       ` Andrew Morton
2003-05-15 16:38                       ` Daniel McNeil
2003-05-15 19:19                         ` Andrea Arcangeli
2003-05-15 22:04                           ` Daniel McNeil
2003-05-15 23:17                             ` Andrea Arcangeli
2003-05-17  0:27                               ` Daniel McNeil
2003-05-17 17:29                                 ` Andrea Arcangeli
2003-05-13 21:00 ` William Lee Irwin III
2003-05-17 18:19 Paul McKenney
2003-05-17 18:42 ` Andrea Arcangeli
2003-05-19 18:11 Paul McKenney

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=E19FzL3-0007Gk-00@w-gerrit2 \
    --to=gh@us.ibm.com \
    --cc=akpm@digeo.com \
    --cc=dmccr@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mika.penttila@kolumbus.fi \
    --cc=wli@holomorphy.com \
    /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