Re: Race between vmtruncate and mapped areas?

[William Lee Irwin III <wli@holomorphy.com>]

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.


-- wli