Re: Remap_file_pages, RSS limits, security implications (was: Re: [uml-devel] Re: [RFC] [patch 0/18] remap_file_pages protection support (for UML), try 3)

[Hugh Dickins <hugh@veritas.com>]

On Tue, 20 Sep 2005, Blaisorblade wrote:
> On Wednesday 07 September 2005 14:00, Hugh Dickins wrote:
> 
> Ahh, ok... VM_MAYSHARE is the recorded MAP_SHARED, while VM_SHARED says 
> whether the pages are actually shared and writable.

That's it (let's say "potentially writable" - VM_SHARED says they're
shared and already writable or shared and could be mprotected writable).

It is confusing, but it's been that way for years, and once you grasp it,
you like to keep it that way, so as to feel superior to everyone else ;)

> > Though thinking through that again now, the user of the nonlinear vma
> > is penalized,
> 
> Where? Not in the page fault path.... it's as penalized as the rest of the 
> system. Or will direct reclaim have a preference for pages of the calling 
> process?

Not in the page fault path, no; and no, direct reclaim doesn't have that
preference (sounds quite a good idea, but would need a different way of
choosing pages to free, and would conflict with the swap token idea?).

I meant in reclaim: that since try_to_unmap_cluster makes such poor
choices of what to reclaim, and tries to reclaim more than asked because
it's unable to target the page in question, I'd expect the user of a
nonlinear vma to suffer more thrashing under memory pressure.

> So, it would really be better to actually enforce the RSS rlimit when mapping 
> in pages in *nonlinear* areas (and fallback on setting file PTE's like on 
> NONBLOCK & page not in cache), rather than the "current" Rik's idea of 
> marking pages as inactive on memory-hog processes.

I'd go mad if I delved into these issues, luckily we have suckers like Rik
and Nick and Con who are prepared to give their lives to such endless tuning.

> But oh, right in mm/trash.c, the code which should do part of this is fully 
> commented out - and it was in the very first version of the code (looking 
> through bkcvs-git repository).

mm/trash.c?  I got quite excited, but now it looks like you just mean
mm/thrash.c.  Yawn.

Hugh