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

Andrew Morton
2004-03-09T00:08:47Z

Andrea Arcangeli <andrea@suse.de> 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
possible.

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