Re: 2.6 must-fix list, v2

[Dave McCracken <dmccr@us.ibm.com>]

--On Tuesday, May 13, 2003 18:27:35 +0200 Trond Myklebust
<trond.myklebust@fys.uio.no> wrote:

> Ah... mmap()ed writes + truncate()...
> 
> OK. There's currently a known problem here which appears both in 2.4.x
> and 2.5.x: we appear to be incapable of flushing out all the dirty
> pages prior to truncating the file. The usual
> filemap_fdatasync()/filemap_fdatawait() appears to be subject to races
> with VM swapping.
> 
> Could we have some help from the VM experts on this one?

I'm in the process of quantifying a big race condition in vmtruncate().
The scenario for the race is this:

* Task 1 truncates the file, which resets the size and calls vmtruncate().

* Task 1 in vmtruncate() walks all vmas for the file and unmaps pages from
the truncated file region.

* Task 2 then extends the file and faults pages back in.

* Task 1 (still in vmtruncate()) removes pages including the newly remapped
pages from the page cache using the original truncated size.

We now have mapped and dirty pages that do not belong to any page cache and
will not be written back to the file.  All subsequent data written via the
mapped pages will be lost.

I don't have a solution for it yet.  I've just gotten as far as identifying
out the race.

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmccr@us.ibm.com                                        T/L   678-3059