Re: 2.6 must-fix list, v2

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Dave McCracken <dmccr@us.ibm.com> writes:

     > 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.

The scenario I'm thinking about is different and can be triggered on a
single process.

The dirty pages are failing to be written out because
they've been swapped out. We then try to do an RPC call to the server
to get it to truncate the file on its side.
Meanwhile one or more of the swapped out pages are faulted in, and
attempted written out. -> race...

Note that we do the vmtruncate() *after* the RPC call (since we cannot
predict whether or not the server will agree to our request) however
actually moving the vmtruncate() to before the RPC call does not
appear to fix the problem.

Cheers,
  Trond