Date: Tue, 7 May 2013 15:39:24 -0400 From: John Baldwin <jhb@freebsd.org> To: Julian Elischer <julian@freebsd.org> Cc: arch@freebsd.org Subject: Re: Extending MADV_PROTECT Message-ID: <201305071539.24900.jhb@freebsd.org> In-Reply-To: <51894A5B.7060101@freebsd.org> References: <201305071433.27993.jhb@freebsd.org> <51894A5B.7060101@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, May 07, 2013 2:39:23 pm Julian Elischer wrote: > On 5/7/13 11:33 AM, John Baldwin wrote: > > One of the issues I have with our current MADV_PROTECT is that it isn't very > > administrative-friendly. That is, as a sysadmin I can't easily protect > > arbitrary processes from the OOM killer. Instead, the binary has to be > > changed to invoke madvise(). Furthermore, once the protection is granted it > > can't be revoked. Also, any binaries that want this have to be run as root. > > Instead, I would like to be able to both set and revoke this for existing > > processes and possibly even allow it to be inherited (so I can tag a top-level > > daemon that forks and have all its future children be protected for example). > > To that end I've whipped up a simple patch (against 8, but should port to HEAD > > easily if folks think it is a good idea) to add a new pprotect() system call > > and userland program (protect) that can be used similar to ktrace(1) either as > > a modifier when running a new program or as a tool for setting or clearing > > protection for existing processes. > > > > The inherit feature isn't implemented yet, but it should be simple to do. One > > would simply need a new flag that PPROT_INHERIT sets that is checked on fork > > and propagates P_PROTECTED if it is set. Also, one other thought I had is > > that at some point we might want to make P_PROTECTED more fine-grained, e.g. > > by allowing for OOM "priorities". To that end, it may make sense to add a new > > argument to protect, though you could also reserve part of the 'op' parameter > > to encode a priority. > > > > The manpage for the proposed protect command is below, then the source of the > > command, then the patch to add pprotect(): > > > > PROTECT(1) FreeBSD General Commands Manual PROTECT(1) > > > > NAME > > protect -- protect processes from being killed when swap space is > > exhausted > > > > SYNOPSIS > > protect [-i] command > > protect [-cdi] -g pgrp | -p pid > > > > > > I like it but it does make it very easy to abuse.. (try protect > everything) > what kinds of limits can there be? Well, only root can do it. Even now MADV_PROTECT is a similar foot shooting device (though not quite as easy to do). You can also get yourself into a heap of trouble with other things like rtprio, etc., so I sort of think that is up to the user/administrator to manage. I do think that the more fine-grained priority approach may be a good way to mitigate that if it really becomes an issue at some point. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201305071539.24900.jhb>