[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proxy-defpager for all users?

From: Richard Braun
Subject: Re: proxy-defpager for all users?
Date: Tue, 6 Nov 2018 11:52:45 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Mon, Nov 05, 2018 at 11:02:47PM +0100, Samuel Thibault wrote:
> proxy-defpager is typically set on /servers/default-pager, but its
> permissions are by default 644, which makes it unusable by normal users,
> it'd need to be 755 (see the x check in the defpager source).
> Apart from allowing users to eat memory, which they currently already
> can do anyway, is there any downside to making this 755 so people can
> mount their own tmpfs?

I personally wondered why it wasn't the case from the start.

That being said, I'll use this as an opportunity to restate a core
problem of Mach memory management, as I couldn't find it on the wiki.
This problem may or may not be even more triggered by using unprivileged
tmpfs instances.

Thu Dec 29 2016 :
< braunr> i've identified a fundamental flaw with the default pager
< braunr> and actually, with mach in general i suppose
< braunr> i assumed that it was necessary to trust the server only
< braunr> that a server didn't need to trust its client
< braunr> but mach messages carry memory that is potentially mapped from 
unprivileged pagers
< braunr> which means faulting on that memory effectively makes the faulting 
process a client to the unprivileged pager 
< braunr> and that's something that can happen to the default pager during 
heavy memory pressure
< braunr> in which case it deadlocks on itself because the copyout hangs on a 
fault, waiting for the unprivileged pager to provide the data
< braunr> (which it can't because of heavy memory pressure and because it's 
unprivileged, it's blocked, waiting until allocations resume)
< braunr> the pageout daemon will keep paging out to the default pager in the 
hope those pages get freed
< braunr> but sending to the default pager is now impossible because its map is 
locked on the never-ending fault

Richard Braun

reply via email to

[Prev in Thread] Current Thread [Next in Thread]