[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090114011137.GC14730@mit.edu>
Date: Tue, 13 Jan 2009 20:11:38 -0500
From: Theodore Tso <tytso@....edu>
To: Evgeniy Polyakov <zbr@...emap.net>
Cc: David Rientjes <rientjes@...gle.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Linux killed Kenny, bastard!
On Wed, Jan 14, 2009 at 02:02:40AM +0300, Evgeniy Polyakov wrote:
> > As Alan has already pointed out to you:
> >
> > (echo XXXX > /proc/self/oom_adj ; exec /usr/bin/program)
>
> Yes, I saw that in archive, but did not receive myself, so did not
> answer. This works in the above simple case, but if we dig a little bit
> into the case when there are children, parent has to live and not all
> children should be considered equal by the oom-killer, things change
> dramatially. And we can not change the sources. Well, in particaular my
> case we can, but it is not about the single system :)
I think you will find that most people are far more interested in
making sure we define consistent, usable interfaces --- and depending
on process names is a complete and total hack. Justifying it by
claiming that we won't be able to change application source code, so
we have to use a hack, isn't going to get you very far.
The security implications alone are troubling; OK, so we make the
process name "sshd" privileged and exempt from the OOM killer. What
happens if a user creates a program called sshd in their home
directory and executes it --- gee, it's protected from the OOM killer
as well. It's just not going to fly. Give up now.
If your argument is "we have to protect crappy closed source
applications where their programmers can't be bothered to change their
source code to use a proper interface", you're just going to get
laughed out of the room.
- 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/
Powered by blists - more mailing lists