From: "Peter Zaitsev" <p...@spylog.ru>
Subject: Some questions about linux kernel.
Date: 2000/03/11
Message-ID: <fa.ecg8iiv.1hngjha@ifi.uio.no>#1/1
X-Deja-AN: 596022006
Original-Date: Sat, 11 Mar 2000 13:14:13 +0300
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <017501bf8b42$8ef1fff0$161b10d4@olymp>
To: <linux-ker...@vger.rutgers.edu>
X-Priority: 3
Content-Type: text/plain; charset="koi8-r"
X-Orcpt: rfc822;linux-kernel-outgoing-dig
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Organization: Internet mailing list
X-MSMail-Priority: Normal
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
1) I've found the very simple thing - program which just hogs all memory by
running for(;;) t=malloc(4096); for example run under usual user with no
explicit memory limitations leads system to unusable state after all swap
space is finished.
Well. The kernel still works afterwards but many of inportant processes dies
and so remote mashine can't even be rebooted properly. The worst thing the
same program leads to nothing then run under solaris 2.6 for example - I
just get the message Out of memory for a.out and no process of other users
are affected. I've checked this on many distributions (RH 6.1,Slakware
7.0,Suse 6.3) with up to last kernel 2.2.14 - everythere I have the same
effect.
2) Linux has two parameters related to buffering. Buffers and cache. The
problem is I can't find anywhere the difference between them in any
documentation described good, better then just saying these are different
things. I do not understand why simetimes I got buffers are more than a
cache under havy file I/O and sometimes cache more than buffers. Can anyone
explain this or point me to good documentation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: "Peter Zaitsev" <p...@spylog.ru>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/11
Message-ID: <fa.edj0iiv.1gi0g13@ifi.uio.no>#1/1
X-Deja-AN: 596123898
Original-Date: Sat, 11 Mar 2000 18:32:14 +0300
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <028c01bf8b6e$fd83cd00$161b10d4@olymp>
References: <fa.gchm4lv.k70hih@ifi.uio.no>
To: "Darrell Wright" <beac...@lakeheadu.ca>
Original-References: <017501bf8b42$8ef1fff0$161b10d4@olymp>
<002b01bf8b6c$ef14a660$f41cd...@lakeheadu.ca>
X-Priority: 3
Content-Type: text/plain; charset="koi8-r"
X-Orcpt: rfc822;linux-kernel-outgoing-dig
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Organization: Internet mailing list
X-MSMail-Priority: Normal
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
> Hello,
> you might want to check out pam. It has a file under /etc/security called
> limits.conf. This will allow you to put per user/ per group or default
> limits on many system resource, such as memory, and the number of
processes.
> If you take your code above and put a while (true) {fork()}; without any
> limits placed here your system will die, also.
Well. I know that but this seems to be just a work around. The system should
not die because of usual users things.
Fork won't help as user only have up to 256 proceses by default.
The problem with memory is really importand. The limits - for example I
have 512MB+1GB of swap - so if I limit users memory to 512MB he will not be
upset much and I'll have the system protected. But if 4 different users will
run such stuff the system will die. I can limit this to user groups - the
same result will be if users are from different groups. So you have to
trouble a lot to make a work around, and so the problem has to be solved
anyway. I know it's solved in solaris 2.6 as I wrote in OS/2 and even in
Windows NT. But not in linux :(
So I'm wondering if 2.4 will have something inside to avoid such situations.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: "Khimenko Victor" <k...@sch57.msk.ru>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/11
Message-ID: <fa.g3osp6v.172ktrh@ifi.uio.no>#1/1
X-Deja-AN: 596150819
Original-Date: Sat, 11 Mar 2000 19:19:46 +0300 (MSK)
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-Id: <ADY8doumkD@khim.sch57.msk.ru>
References: <fa.gchm4lv.k70hih@ifi.uio.no>
To: p...@spylog.ru, beac...@lakeheadu.ca
Original-References: <028c01bf8b6e$fd83cd00$161b10d4@olymp>
<017501bf8b42$8ef1fff0$161b10d4@olymp> <002b01bf8b6c$ef14a660$f41cd...@lakeheadu.ca>
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: MCCME
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
In <028c01bf8b6e$fd83cd00$161b10d4@olymp> Peter Zaitsev (p...@spylog.ru) wrote:
>> Hello,
>> you might want to check out pam. It has a file under /etc/security called
>> limits.conf. This will allow you to put per user/ per group or default
>> limits on many system resource, such as memory, and the number of
> processes.
>> If you take your code above and put a while (true) {fork()}; without any
>> limits placed here your system will die, also.
> Well. I know that but this seems to be just a work around. The system should
> not die because of usual users things.
> Fork won't help as user only have up to 256 proceses by default.
> The problem with memory is really importand. The limits - for example I
> have 512MB+1GB of swap - so if I limit users memory to 512MB he will not be
> upset much and I'll have the system protected. But if 4 different users will
> run such stuff the system will die. I can limit this to user groups - the
> same result will be if users are from different groups. So you have to
> trouble a lot to make a work around, and so the problem has to be solved
> anyway. I know it's solved in solaris 2.6 as I wrote in OS/2 and even in
> Windows NT. But not in linux :(
> So I'm wondering if 2.4 will have something inside to avoid such situations.
Ok. This discussion is serveral YEARS old. So do not hold you breath.
There were lots and lots of discussion about this and fewdifferent patches
are floating around for ages (in 2.2.15pre some OOM patches was tried;
perhaps 2.2.15 will include one of them). But ALL patches are designed to help
in case of run-away process and NOT protect against malicious user.
P.S. Of course if you'll be able to cook up patch and solve this outstanding
problem still not solved after few years of exercises by Linux's memory
wizards you are welcome. Just don't think it's so easy :-(
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Rik van Riel <r...@conectiva.com.br>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/11
Message-ID: <fa.lds4tav.1r16t3f@ifi.uio.no>#1/1
X-Deja-AN: 596224044
Original-Date: Sat, 11 Mar 2000 18:43:05 -0300 (BRST)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.4.21.0003111838090.29123-100000@duckman.conectiva>
References: <fa.edj0iiv.1gi0g13@ifi.uio.no>
To: Peter Zaitsev <p...@spylog.ru>
X-Sender: r...@duckman.conectiva
X-Authentication-Warning: duckman.conectiva: riel owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Reply-To: r...@nl.linux.org
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
On Sat, 11 Mar 2000, Peter Zaitsev wrote:
[snip ulimit and OOM]
> Well. I know that but this seems to be just a work around. The
> system should not die because of usual users things.
> I know it's solved in solaris 2.6 as I wrote in OS/2 and even in
> Windows NT. But not in linux :(
> So I'm wondering if 2.4 will have something inside to avoid such
> situations.
It is trivial to solve this problem in a satisfactory
way for 99% of the situations. There has never been a
100% solution however and the last three times I sent
such code to linux-kernel a (small) flamewar started.
If Linus indicates he's willing to accept something
like my 2.2 oom killer patch into 2.3, I'll code
something up.
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Rik van Riel <r...@conectiva.com.br>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/11
Message-ID: <fa.lfbmtiv.1qhgsr4@ifi.uio.no>#1/1
X-Deja-AN: 596225117
Original-Date: Sat, 11 Mar 2000 18:45:50 -0300 (BRST)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.4.21.0003111843320.29123-100000@duckman.conectiva>
References: <fa.g3osp6v.172ktrh@ifi.uio.no>
To: Khimenko Victor <k...@sch57.msk.ru>
X-Sender: r...@duckman.conectiva
X-Authentication-Warning: duckman.conectiva: riel owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Reply-To: r...@nl.linux.org
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
On Sat, 11 Mar 2000, Khimenko Victor wrote:
> Ok. This discussion is serveral YEARS old. So do not hold you
> breath. There were lots and lots of discussion about this and
> fewdifferent patches are floating around for ages (in 2.2.15pre
> some OOM patches was tried; perhaps 2.2.15 will include one of
> them). But ALL patches are designed to help in case of run-away
> process and NOT protect against malicious user.
>
> P.S. Of course if you'll be able to cook up patch and solve this
> outstanding problem still not solved after few years of
> exercises by Linux's memory wizards you are welcome. Just don't
> think it's so easy :-(
On the contrary, putting together a solution to this
problem is easy. The problem has been that people don't
understand the issues involved and start a flamewar as
soon as a patch (re)surfaces.
Also, making a solution that everybody agrees with seems
to be impossible in this situation :)
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: "Peter T. Breuer" <p...@it.uc3m.es>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/13
Message-ID: <fa.gksveav.8604q0@ifi.uio.no>#1/1
X-Deja-AN: 596879234
Original-Date: Mon, 13 Mar 2000 09:57:27 +0100 (MET)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-Id: <200003130857.JAA30396@oboe.it.uc3m.es>
References: <fa.lo5cdvv.1ani8oi@ifi.uio.no>
X-Anonymously-To:
To: James Sutherland <ja...@cam.ac.uk>
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Reply-To: p...@it.uc3m.es
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
"A month of sundays ago James Sutherland wrote:"
> At the time, I suggested moving the grim-reaper code into a userspace
> daemon, to allow much greater/easier configurability. I can think of a few
I believe this is the correct solution. It implies exactly _one_
privileged task, whose job is to decide the privileges of all the rest.
> For the time being, though, the simple "kill the most likely suspect"
> patch should be a pretty good approximation.
Nope. It isn't. It's unacceptable in practice.
I run labs. The lab machines have to have defenses against
_themselves_. First line defence: system daemons restarted by
init if killed. Second line: daemons restarted by cron-based checks
(cron has to be maintained from init) at regular intervals. Third
line: software watchdog checking mem use and ready to pull machine
to runlevel s and back up again if conditions not rectified.
Even so, I get reports every couple of days from machines that
have obviously killed themselves. I just got one from a cron
telling me it had restarted the software watchdog, for goodness'
sake! (amongst others: rpc.nfsd and rpc.mountd seem to be favourites).
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: James Sutherland <ja...@cam.ac.uk>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/14
Message-ID: <fa.jjb0mhv.1ghav97@ifi.uio.no>#1/1
X-Deja-AN: 597372204
Original-Date: Mon, 13 Mar 2000 23:37:36 +0000 (GMT)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.4.10.10003132332280.2054-100000@dax.joh.cam.ac.uk>
References: <fa.gksveav.8604q0@ifi.uio.no>
To: "Peter T. Breuer" <p...@it.uc3m.es>
X-Sender: ja...@dax.joh.cam.ac.uk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
On Mon, 13 Mar 2000, Peter T. Breuer wrote:
> "A month of sundays ago James Sutherland wrote:"
> > At the time, I suggested moving the grim-reaper code into a userspace
> > daemon, to allow much greater/easier configurability. I can think of a few
>
> I believe this is the correct solution. It implies exactly _one_
> privileged task, whose job is to decide the privileges of all the rest.
Yes.
> > For the time being, though, the simple "kill the most likely suspect"
> > patch should be a pretty good approximation.
>
> Nope. It isn't. It's unacceptable in practice.
It's better than the current system, which amounts to "kill processes at
random until there's some free memory again."
> I run labs. The lab machines have to have defenses against
> _themselves_. First line defence: system daemons restarted by
> init if killed. Second line: daemons restarted by cron-based checks
> (cron has to be maintained from init) at regular intervals. Third
> line: software watchdog checking mem use and ready to pull machine
> to runlevel s and back up again if conditions not rectified.
If your watchdog monitors memory usage and corrects problems, then the
kernel OOM handler will never be invoked.
I want to emphasise this point: the OOM handler should **NEVER** be
invoked. If it is ever needed, there is something BADLY wrong with the
system - either we do something drastic (process slaughtering) or the
machine goes down completely. Worrying about which user processes are
killed to avoid an uncontrolled failure is a case of rearranging the
deckchairs on the Titanic.
> Even so, I get reports every couple of days from machines that
> have obviously killed themselves. I just got one from a cron
> telling me it had restarted the software watchdog, for goodness'
> sake! (amongst others: rpc.nfsd and rpc.mountd seem to be favourites).
If your watchdog is dying, then you have some big problems there. Either
it is killing itself for some reason, or you have *very* big problems with
the other software, or the machine's hardware. (Malicious users, perhaps?)
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Jason Gunthorpe <j...@ualberta.ca>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/14
Message-ID: <fa.kcqu24v.1b5ana3@ifi.uio.no>#1/1
X-Deja-AN: 597335107
Original-Date: Mon, 13 Mar 2000 23:33:12 -0700 (MST)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.3.96.1000313231730.19092C-100000@wakko.deltatee.com>
References: <fa.jjb0mhv.1ghav97@ifi.uio.no>
To: James Sutherland <ja...@cam.ac.uk>
X-Sender: j...@wakko.deltatee.com
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Reply-To: Jason Gunthorpe <j...@ualberta.ca>
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
On Mon, 13 Mar 2000, James Sutherland wrote:
> I want to emphasise this point: the OOM handler should **NEVER** be
> invoked. If it is ever needed, there is something BADLY wrong with the
> system - either we do something drastic (process slaughtering) or the
> machine goes down completely. Worrying about which user processes are
> killed to avoid an uncontrolled failure is a case of rearranging the
> deckchairs on the Titanic.
Just as someone who has been bitten by this, I agree with James. The
number one priority is keeping the machine up - I don't care what you
kill, just keep it running and preferably allow remote logins still...
I'd think there are only two ways you can accidently OOM a box - a single
process goes nutz or something like a fork bomb. I'd think the simplest
solution is to look for the process using the most memory or the user with
the most processes+memory (some weird weight factor here) and blow it
away. If this means jonhnie looses their shell, their emacs and whatever
else because someone fork bombed a box then too bad. If this means apache
gets blown away because a CGI went insane then too bad. When the
alternative is having to drive to the site and hit the reset button (which
had to be done, twice :P) it is a minor trouble.
In my case it turned out a WML process got into an infinite ram using
loop, on 2.2.6-ac1 the machine just crashed - no kernel log messages,
nothing, just dead. Unnaceptable :> In this particular case the wml
process got up to some 400meg of ram usage before things got really out of
hand. Lots of swap! These days there is a ulimit protecting these wml
processes, but it was really hit and miss to find out that it was indeed
wml that was causing this.. (Heck, it was a lucky guess it was even OOM)
IMHO a completely seperate topic is how to prevent a malicious user from
abusing this to nuke a machine.. That sounds like a very difficult prolem
indeed.
Jason
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: James Sutherland <ja...@cam.ac.uk>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/14
Message-ID: <fa.jmb0nhv.1hh6u94@ifi.uio.no>#1/1
X-Deja-AN: 597414514
Original-Date: Tue, 14 Mar 2000 09:54:54 +0000 (GMT)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.4.10.10003140947540.1214-100000@dax.joh.cam.ac.uk>
References: <fa.kcqu24v.1b5ana3@ifi.uio.no>
To: Jason Gunthorpe <j...@ualberta.ca>
X-Sender: ja...@dax.joh.cam.ac.uk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
On Mon, 13 Mar 2000, Jason Gunthorpe wrote:
>
> On Mon, 13 Mar 2000, James Sutherland wrote:
>
> > I want to emphasise this point: the OOM handler should **NEVER** be
> > invoked. If it is ever needed, there is something BADLY wrong with the
> > system - either we do something drastic (process slaughtering) or the
> > machine goes down completely. Worrying about which user processes are
> > killed to avoid an uncontrolled failure is a case of rearranging the
> > deckchairs on the Titanic.
>
> Just as someone who has been bitten by this, I agree with James. The
> number one priority is keeping the machine up - I don't care what you
> kill, just keep it running and preferably allow remote logins still...
>
> I'd think there are only two ways you can accidently OOM a box - a single
> process goes nutz or something like a fork bomb. I'd think the simplest
> solution is to look for the process using the most memory or the user with
> the most processes+memory (some weird weight factor here) and blow it
> away. If this means jonhnie looses their shell, their emacs and whatever
> else because someone fork bombed a box then too bad. If this means apache
> gets blown away because a CGI went insane then too bad. When the
> alternative is having to drive to the site and hit the reset button (which
> had to be done, twice :P) it is a minor trouble.
>
> In my case it turned out a WML process got into an infinite ram using
> loop, on 2.2.6-ac1 the machine just crashed - no kernel log messages,
> nothing, just dead. Unnaceptable :> In this particular case the wml
> process got up to some 400meg of ram usage before things got really out of
> hand. Lots of swap! These days there is a ulimit protecting these wml
> processes, but it was really hit and miss to find out that it was indeed
> wml that was causing this.. (Heck, it was a lucky guess it was even OOM)
>
> IMHO a completely seperate topic is how to prevent a malicious user from
> abusing this to nuke a machine.. That sounds like a very difficult prolem
> indeed.
In the simplest case (while(1){malloc(4096);}) then typically the
malicious code will be the first one blown away, at least on most
multi-user boxen (where there a lots of users, each using a few Mb, then
some DOSer grabs the last 50Mb in one process.
On a big system with few users (running huge simulations, say) then the
one big process might get blown away first. On the other hand, the
malicious users shouldn't have logins on those boxen anyway :-)
OK, a more intelligent malicious user could write code that would find the
biggest process currently running, then allocate slightly less memory than
it, then fork and repeat. Fixing this would need per-user resource
limits...
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Rik van Riel <r...@conectiva.com.br>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/15
Message-ID: <fa.lpo4mjv.107uv83@ifi.uio.no>#1/1
X-Deja-AN: 597654422
Original-Date: Tue, 14 Mar 2000 16:16:16 -0300 (BRST)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.4.21.0003141612240.5863-100000@duckman.conectiva>
References: <fa.jmb0nhv.1hh6u94@ifi.uio.no>
To: James Sutherland <ja...@cam.ac.uk>
X-Sender: r...@duckman.conectiva
X-Authentication-Warning: duckman.conectiva: riel owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Reply-To: r...@nl.linux.org
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
On Tue, 14 Mar 2000, James Sutherland wrote:
> OK, a more intelligent malicious user could write code that
> would find the biggest process currently running, then allocate
> slightly less memory than it, then fork and repeat. Fixing this
> would need per-user resource limits...
This would be detected by my OOM patch since the hogs
aren't running as long as the big simulation and haven't
used as much CPU time...
People have actually tried this and my patch seems to
catch the hog just fine :)
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: James Sutherland <ja...@cam.ac.uk>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/15
Message-ID: <fa.jmqqnhv.1m1cu94@ifi.uio.no>#1/1
X-Deja-AN: 597726867
Original-Date: Tue, 14 Mar 2000 19:32:34 +0000 (GMT)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.4.10.10003141928120.1474-100000@dax.joh.cam.ac.uk>
References: <fa.lpo4mjv.107uv83@ifi.uio.no>
To: r...@nl.linux.org
X-Sender: ja...@dax.joh.cam.ac.uk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
On Tue, 14 Mar 2000, Rik van Riel wrote:
> On Tue, 14 Mar 2000, James Sutherland wrote:
>
> > OK, a more intelligent malicious user could write code that
> > would find the biggest process currently running, then allocate
> > slightly less memory than it, then fork and repeat. Fixing this
> > would need per-user resource limits...
>
> This would be detected by my OOM patch since the hogs
> aren't running as long as the big simulation and haven't
> used as much CPU time...
Not necessarily the one big simulation case (that's easy :) but what about
a typical case? Say, a multi-user system, hundreds of user processes,
various sizes and CPU times. Now, I come along and run my "malloc() bomb",
BUT modified so it has a busy loop in. Allocating, say, 4K every second.
After a couple of hours, maybe a day or two, it has chewed up many hours
of CPU time, and many Mb of RAM. It then looks like a legitimate process,
and other things die :-)
> People have actually tried this and my patch seems to
> catch the hog just fine :)
Any sufficiently well-coded bomb is indistinguishable from an innocent
unattended package :-)
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Rik van Riel <r...@conectiva.com.br>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/15
Message-ID: <fa.lqo6njv.137su80@ifi.uio.no>#1/1
X-Deja-AN: 597982869
Original-Date: Tue, 14 Mar 2000 17:03:09 -0300 (BRST)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.4.21.0003141651450.5863-100000@duckman.conectiva>
References: <fa.jmqqnhv.1m1cu94@ifi.uio.no>
To: James Sutherland <ja...@cam.ac.uk>
X-Sender: r...@duckman.conectiva
X-Authentication-Warning: duckman.conectiva: riel owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Reply-To: r...@nl.linux.org
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
On Tue, 14 Mar 2000, James Sutherland wrote:
> It then looks like a legitimate process, and other things die
> :-)
>
> > People have actually tried this and my patch seems to
> > catch the hog just fine :)
>
> Any sufficiently well-coded bomb is indistinguishable from an
> innocent unattended package :-)
Indeed. There is always a way to fool any OOM killer.
The only thing that could save us here are proper
per-user resource limits, but even then we'd still want
an emergency OOM killer to rescue the system in situations
where we hit the wall...
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Paul Jakma <paul.ja...@compaq.com>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/16
Message-ID: <fa.nskc7iv.1ehccrc@ifi.uio.no>#1/1
X-Deja-AN: 598203705
Original-Date: Wed, 15 Mar 2000 14:22:49 +0000 (GMT Standard Time)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.WNT.4.21.0003151418220.161-100000@8938cs820195.ied.cpqcorp.net>
References: <fa.lqo6njv.137su80@ifi.uio.no>
To: r...@nl.linux.org
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-X-Sender: digital2/c-jakma@[dboexc1]
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
On Tue, 14 Mar 2000, Rik van Riel wrote:
> Indeed. There is always a way to fool any OOM killer.
> The only thing that could save us here are proper
> per-user resource limits,
so isn't what should be concentrated on? Per user limits are a cleaner
way of fixing the problem.
i guess though it's a 2.5 thing. Rik, do you know of anyone
investigating per-user limits for 2.5? (a lot of linux users would
like to see it.. hint hint..)
:)
> but even then we'd still want
> an emergency OOM killer to rescue the system in situations
> where we hit the wall...
>
OOM is a stopgap. Ideally we should be able to set ironclad policies so
that we never encounter OOM.
> Rik
groetjes,
-paul jakma
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Rik van Riel <r...@conectiva.com.br>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/22
Message-ID: <fa.lfauuqv.1ohos37@ifi.uio.no>#1/1
X-Deja-AN: 600914718
Original-Date: Wed, 22 Mar 2000 11:27:36 -0300 (BRST)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.4.21.0003221126340.12774-100000@duckman.conectiva>
References: <fa.nskc7iv.1ehccrc@ifi.uio.no>
To: Paul Jakma <paul.ja...@compaq.com>
X-Sender: r...@duckman.conectiva
X-Authentication-Warning: duckman.conectiva: riel owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Reply-To: r...@nl.linux.org
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
On Wed, 15 Mar 2000, Paul Jakma wrote:
> On Tue, 14 Mar 2000, Rik van Riel wrote:
>
> > Indeed. There is always a way to fool any OOM killer.
> > The only thing that could save us here are proper
> > per-user resource limits,
>
> so isn't what should be concentrated on? Per user limits are a
> cleaner way of fixing the problem.
s/fixing/avoiding/
s/.$/ in a lot of cases./
> i guess though it's a 2.5 thing. Rik, do you know of anyone
> investigating per-user limits for 2.5? (a lot of linux users
> would like to see it.. hint hint..)
Some people are looking into this and if you remind them
they might even finish it :)
cheers,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Marcelo Tosatti <marc...@conectiva.com.br>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/22
Message-ID: <fa.kl564gv.hm0tab@ifi.uio.no>#1/1
X-Deja-AN: 601045846
Original-Date: Wed, 22 Mar 2000 14:12:29 -0300 (BRST)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.4.20.0003221410470.995-100000@freak.conectiva>
References: <fa.lfauuqv.1ohos37@ifi.uio.no>
To: r...@nl.linux.org
X-Sender: marc...@freak.conectiva
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
On Wed, 22 Mar 2000, Rik van Riel wrote:
> On Wed, 15 Mar 2000, Paul Jakma wrote:
> > On Tue, 14 Mar 2000, Rik van Riel wrote:
> >
> > > Indeed. There is always a way to fool any OOM killer.
> > > The only thing that could save us here are proper
> > > per-user resource limits,
> >
> > so isn't what should be concentrated on? Per user limits are a
> > cleaner way of fixing the problem.
>
> s/fixing/avoiding/
> s/.$/ in a lot of cases./
>
> > i guess though it's a 2.5 thing. Rik, do you know of anyone
> > investigating per-user limits for 2.5? (a lot of linux users
> > would like to see it.. hint hint..)
http://bazar.conectiva.com.br/~marcelo/userbean.5
> Some people are looking into this and if you remind them
> they might even finish it :)
Rik, could you please describe yours per-user resource limits idea which
we were discussing?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: Rik van Riel <r...@conectiva.com.br>
Subject: Re: Some questions about linux kernel.
Date: 2000/03/22
Message-ID: <fa.lfrmtav.1o10tje@ifi.uio.no>#1/1
X-Deja-AN: 601079423
Original-Date: Wed, 22 Mar 2000 18:50:14 -0300 (BRST)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.4.21.0003221828560.15103-100000@duckman.conectiva>
References: <fa.kl564gv.hm0tab@ifi.uio.no>
To: Marcelo Tosatti <marc...@conectiva.com.br>
X-Sender: r...@duckman.conectiva
X-Authentication-Warning: duckman.conectiva: riel owned process doing -bs
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Reply-To: r...@nl.linux.org
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu
On Wed, 22 Mar 2000, Marcelo Tosatti wrote:
> On Wed, 22 Mar 2000, Rik van Riel wrote:
> > On Wed, 15 Mar 2000, Paul Jakma wrote:
> > > i guess though it's a 2.5 thing. Rik, do you know of anyone
> > > investigating per-user limits for 2.5? (a lot of linux users
> > > would like to see it.. hint hint..)
> > Some people are looking into this and if you remind them
> > they might even finish it :)
>
> Rik, could you please describe yours per-user resource limits
> idea which we were discussing?
OK, the idea was to have the kernel keep the per-user
limits in kernel memory, with a (flexible?) configuration
file that's handled in userspace.
The kernel simply keeps the info for all UIDs with running
processes in memory and reuses the others in LRU order (so
that a user that gets lots of email doesn't cause the info
to be reloaded every few seconds).
The way to load the info into the kernel is probably best
done by a userland helper program that parses the config
file (in a flexible and easy format) and hands the data to
the kernel in a more rigid and compact format.
(just as we do now with loading modules)
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/