On Tue, 24 Oct 2000, Petr Vandrovec wrote:
> On 23 Oct 00 at 23:05, Alexander Viro wrote:
>
> > Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> > analysis had been done? Petr, can you reproduce the problem on -test7?
> > Unfortunately, clean test would take the backport of ext2 changes
> > (truncate-related, happened around the same time), but IIRC -test7 was
> > relatively stable...
>
> Just FYI - I was able to reproduce it with 2.4.0-test5 and all laters
> (different pre-s of test6/7/8/9/10) I have. I was not able to reproduce
> it with 2.2.17-pre13 (although this kernel had really bad behavior when
> I run out of space with backing file - sendmail suspended itself due
> to load of 37... on machine which has usually load 0.01).
>
> I do not have kernels between 2.2.17 and 2.4.0-test5 installed.
>
> If you have anything I should check...
I see the race that can lead to screwups you've seen, but I don't see a
really clear way to close it.
Race in question:
truncate_inode_pages() removes the page from pagecache.
sync_pte is called before we get to killing the pagetable
references.
Potentially, the following might be more or less OK, but I'm not too
happy with it:
* All ->nopage() methods mark page uptodate (upon success, that
is).
* do_no_page() fails if page is not uptodate.
* vmtruncate starts with setting the size and going through the
pagecache, removing all fully truncated pages from the hash chains and
gathering them in the list and removing uptodate flag.
* then it does vmtruncate_list() calls, zapping the pagetable
references to the pages in question.
* *then* it goes through the list and does the rest of
truncate_inode_pages() work.
The theory being:
once the i_size is set, no new pages will be bound to affected
part of file.
when we unhash all affected pages and mark them non-uptodate there
will be no new pagetable references to them (they will not be found, and
any pagefault in progress will fail since we mark them non-uptodate).
any possible IO-in-progress on these pages will not be disturbed -
it doesn't depend on the page being hashed. Aliases do not matter, since
they won't be bound to the relevant part of file anyway.
once we kill all pagetable references (and no new references are
going to appear at that point) we can be sure that no process will
initiate _any_ operations on these pages. Notice that potential dirty data
on them doesn't matter - it's going to die anyway (file is being
truncated).
*now* we grab the page lock on each of these pages, thus letting
any method-in-progress to be completed and that point we can safely kill
->mapping.
Linus, could you comment on that variant?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:13 EST