Messages in this thread | | | Date | Tue, 13 May 2003 11:45:07 -0500 | From | Dave McCracken <> | Subject | Re: 2.6 must-fix list, v2 |
| |
--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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |