Richard Braun <rbr...@sceen.net> writes: > 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.
I'll add this information to the wiki in a few days. > > 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
