Date: Tue, 07 May 2013 11:39:23 -0700 From: Julian Elischer <julian@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Extending MADV_PROTECT Message-ID: <51894A5B.7060101@freebsd.org> In-Reply-To: <201305071433.27993.jhb@freebsd.org>
index | next in thread | previous in thread | raw e-mail
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?help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51894A5B.7060101>