Re: mapped pages being truncated [was Re: 2.6.5-rc2-aa5]

From: Andrea Arcangeli
Date: Tue Mar 30 2004 - 14:04:13 EST

On Tue, Mar 30, 2004 at 07:48:42PM +0100, Hugh Dickins wrote:
> On Tue, 30 Mar 2004, Andrea Arcangeli wrote:
> >
> > note that the very same bug triggers with objrmap only applied (before I
> > applied anon-vma and prio-tree on top of it), so at very least this is a
> > bug in Dave's code too. See the same BUG_ON triggering in rmap.c before
> > I replace it with objrmap.c in anon-vma. Almost certainly it will trigger with
> > your patches applied too and probably it happens with mainline 2.6 too
> > but nobody tested that yet.
> Do you have enough evidence that it's the very same bug?

yes, see the two stack traces, they trigger in the same place and it's
the very same workload. Andrew just noticed that xfs indeed calls
truncate_inode_pages before vmtruncate. It will trigger with your
patches too.

> I believe there were other loopholes in the original objrmap code,
> we've both moved on from there (e.g. we both decided it's safer to
> set and clear PageAnon inside the maplock), so I'm not concerned
> about the original objrmap.

Ok I see what you mean, this should fix it, agreed?

--- x/mm/memory.c.~1~ 2004-03-29 19:24:39.000000000 +0200
+++ x/mm/memory.c 2004-03-30 20:57:35.889344056 +0200
@@ -1448,6 +1448,7 @@ retry:
new_page = page;
anon = 1;
+ pageable = 1;


In practice doing a cow on a dma region is pretty useless, so I doubt
anybody would run into it but I agree the above is making the anon page
swappable and it's more correct.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at