linux-kernel - Re: Linux killed Kenny, bastard!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090113131937.GB17664@mit.edu>
Date:	Tue, 13 Jan 2009 08:19:37 -0500
From:	Theodore Tso <tytso@....edu>
To:	Evgeniy Polyakov <zbr@...emap.net>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Rientjes <rientjes@...gle.com>,
	Bill Davidsen <davidsen@....com>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Linux killed Kenny, bastard!

Instead of trying to specify which process should be protected from
the OOM killer by name, how about something which is inherited from
the parent process?  After all, if having the child not get killed due
to OOM is important, the child won't even have a chance to run if the
parent gets killed off.  And in fact, we have something that fits that
bill fairly well; getrlimit()/setrlimit().  Why not define a new
resource limit which specifies a relative immunity to the oom_killer?

Most of the infrastructure to support that will already be in place
(i.e., shell support, PAM support in /etc/securitylimits.conf); all
that would need to be done is to teach a few userspace
programs/libraries about the new resource limit.

This would be a much cleaner approach, I would think.

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/