Re: objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in<=16G machines)

From: Andrew Morton
Date: Mon Mar 08 2004 - 19:12:07 EST

Andrea Arcangeli <andrea@xxxxxxx> wrote:
> > btw, mincore() has always been broken with nonlinear vma's. If you could
> > fix that up some time using that pagetable walker it would be nice. It's
> > not very important though.
> Ok! I'm still late at this though, I wish I would be working on the
> nonlinear stuff by now ;), I'm still stuck at the anon_vma_chain...

As I say, broken mincore() on nonlinear mappings isn't a showstopper ;)

> If I understand well, vmtruncate will also need the pagetable walker to
> nuke all mappings of the last pages of the files before we free them
> from the pagecache. So it should be a library call that mincore can use
> too then, I don't see problems.

If we want to bother with the traditional truncate-causes-SIGBUS semantics
on nonlinear mappings, yes. I guess it would be best to do that if

> btw (for completeness), about the cpu consumption concerns about objrmap
> w.r.t. security (that was Ingo's only argument against objrmap),
> whatever malicious waste of cpu that could happen during paging, can be
> already triggered in any kernel out there by using truncate on the same
> mappings instead of swapping them out.

Yes, malicious apps can DoS the machine in many ways. I'm more concerned
about non-malicious ones getting hurt by the new search activity. Say, a
single-threaded app which uses a huge number of vma's to map discontiguous
parts of a file. The 2.4-style virtual scan would handle that OK, and the
2.6-style pte_chain walk would handle it OK too. People do weird things.

(objrmap could perhaps terminate the vma walk after it sees the page->count
fall to a value which means there are no more pte's mapping the page - that
would halve the search cost on average).
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