Date: Wed, 8 May 2013 12:58:27 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Extending MADV_PROTECT Message-ID: <20130508095827.GK3047@kib.kiev.ua> In-Reply-To: <201305071433.27993.jhb@freebsd.org> References: <201305071433.27993.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--NeRnyCbrXmug+DvV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 07, 2013 at 02:33:27PM -0400, 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. Wouldn't the pprot_setchildren() miss a child for which the new pid and struct proc are already allocated in the do_fork(), but which is not yet linked into the process tree ? If true, I think this does not fulfill the promise of the PPROT_DESCEND. It seems that the patch posted missed the chunk for sys/proc.h. For HEAD, you probably need e.g. p_flag2 and P2_PROTECTED instead. Since the syscall is mean to be extended in the future, would it make more sense to add a multiplexer, e.g. procctl(2), one operation of which would be PROCCTL_PROTECT ? --NeRnyCbrXmug+DvV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRiiHCAAoJEJDCuSvBvK1BULQQAKEe9JA9Ypl2ovMbLPqMU99k K4/zwadyQdjvTx2PBX7LL/mgcE6TkswR/WCqPqZMkxpA01zeQbK9U1MQ8juNCTS3 f6hYtQiB9IlMii/y1DJN0ho1hE+wLhB3oJNi+s/0vf7IoxFfXoZpy0TBOLeH8lRN c9bXSfxw+26+koWbc+YuvcNV9dwbuhp8LYW3fed/33b2b0viEXdfFy0UAVdFMDgW DfZKy6LDKxv7WNbTx60hWX5GyJaIERDUvmfiPn4rMnS1ddbYZIZi4t221PVshAzE wdV4zO4iJbl2ejtipzv4fsTe9YhOFeHqZ4khCBDySD/6GM/hLEeTEJKwLAlq4cNJ pXDfg6rvxLJQFkqkVbbhq+BtgR4Ub+8kZvjZY72fDWr16BTivMXkherXyhQkY/2B EbrEl2FVJwmvILEEHJhVyHaOyyKflP9JZ0j4HPWRd+2IAUXprRd3zJTuEZi+4XVG AlrTtnOt4gx5KHj/RtU5zVvmuvqtc5vWlocdonDK88nc8E8GO1Ydu4HGSglZTv30 kpnHIEoVXFFC7/c88d/D/WoOTS3oJzkKQzBMSsQICrnkm2dcG/GomgJm0RhhKvFR AQwF52xSa1O++UMhUZLP0WmJqRzjFclIMOS1qyrgJ0Xys14fbnSDjVSG/omLm35h LmQ8v8+o4e/niFBWk45r =BPTh -----END PGP SIGNATURE----- --NeRnyCbrXmug+DvV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130508095827.GK3047>