From: Andrea Arcangeli
Date: Mon Mar 29 2004 - 17:53:28 EST
On Mon, Mar 29, 2004 at 04:30:51PM -0500, Rajesh Venkatasubramanian wrote:
> Andrew Moroton <akpm@xxxxxxxx> wrote:
> >> Andrea Arcangeli <andrea@xxxxxxx> wrote:
> >> Notably there is a BUG_ON(page->mapping) triggering in
> >> page_remove_rmap in the pagecache case. that could be ex-pagecache
> >> being
> >> removed from pagecache before all ptes have been zapped, infact the
> >> page_remove_rmap triggers in the vmtruncate path.
> > Confused. vmtruncate zaps the ptes before removing pages from
> > pagecache,
> > so I'd expect a non-null ->mapping in page_remove_rmap() is a very
> > common
> > thing. truncate a file which someone has mmapped and it'll happen every
> > time, will it not?
> Andrea missed a not (!) in the BUG_ON. It is BUG_ON(!page->mapping).
Yep sorry ;)
> The race Andrea hit _may_ be the mremap vs. vmtruncate race I hit:
> A first truncate that raced with mremap and left an orphaned pte.
> The following truncate tried to clear the orphaned pte, and reached
> page_remove_rmap with page->mapping == NULL.
> Yes. It can happen in all 2.4 and 2.6 kernels.
ok fine, so my WARN_ON should work.
> Hugh has a better fix than mine for the mremap vs. truncate race
> in his anobjrmap 7/6 patch.
> With prio_tree we have to modify Hugh's fix, though.
Hugh are you interested to extract the fix against mainline? The
anobjrmap 7/6 is doing most of stuff I don't really need with anon-vma.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/