Hi!
> >>main() { while(1) if (fork()) malloc(1); }
> >>With the patch below I could ssh to the host and killall the offending
> >>processes. To enable reserving VM space for root do
> > what about main() { while(1) system("ftp localhost &"); }
> > This. or so,ething similar should all
On Thu, 16 Nov 2000, Rik van Riel wrote:
> On Thu, 16 Nov 2000, Szabolcs Szakacsits wrote:
> [snip exploit that really shouldn't take Linux down]
I don't really consider it as an exploit. It's a kind of workload
that's optimized for fast testing simulating many busy user daemons
(e.g. dyna
On Thu, 16 Nov 2000, Christoph Hellwig wrote:
> On Thu, Nov 16, 2000 at 01:51:01PM -0200, Rik van Riel wrote:
> > > If you think fork() kills the box then ulimit the maximum number
> > > of user processes (ulimit -u). This is a different issue and a
> > > bad design in the scheduler (see e.g. Tru6
On Thu, Nov 16, 2000 at 01:51:01PM -0200, Rik van Riel wrote:
> > If you think fork() kills the box then ulimit the maximum number
> > of user processes (ulimit -u). This is a different issue and a
> > bad design in the scheduler (see e.g. Tru64 for a better one).
>
> My fair scheduler catches th
On Thu, 16 Nov 2000, Szabolcs Szakacsits wrote:
[snip exploit that really shouldn't take Linux down]
> This or something similar didn't kill the box [I've tried all local
> DoS from Packetstorm that I could find]. Please send a working
> example. Of course probably it's possible to trigg
On Wed, 1 Jan 1997 [EMAIL PROTECTED] wrote:
>>main() { while(1) if (fork()) malloc(1); }
>>With the patch below I could ssh to the host and killall the offending
>>processes. To enable reserving VM space for root do
> what about main() { while(1) system("ftp localhost &"); }
> This.
Hi!
>I've also never said OOM killer should be disabled. In theory the
>non-overcommitting systems deadlock, Linux survives. Ironically
>usually it's just the opposite in practice. Any user can
>deadlock/crash Linux [default install, no quotas] but not an
>non-overcommitting system
Hello,
On Thu, Nov 09, 2000 at 06:30:32PM +0100, Szabolcs Szakacsits wrote:
> BTW, I wanted to take a look at the frequently mentioned beancounter patch,
> here is the current state,
> http://www.asp-linux.com/en/products/ubpatch.shtml
> "Sorry, due to growing expenses for support of publ
On Wed, 8 Nov 2000, Rik van Riel wrote:
> OK. This is a lot more reasonable.
Just the same what was in my first in email.
> I'm actually looking into putting non-overcommit as a configurable
> option in the kernel.
Nice to hear, please make it a boot time option, not a compile time
one. Also
On Wed, 8 Nov 2000, Mikulas Patocka wrote:
> BTW. Why does your OOM killer in 2.4 try to kill process that mmaped
> most memory? mmap is hamrless. mmap on files can't eat memory and
> swap.
Because the thing is too stupid to take that into
consideration? :)
Btw, if your mmap()ed file still take
On Wed, Nov 08, 2000 at 05:36:40PM +0100, Mikulas Patocka wrote:
> BTW. Why does your OOM killer in 2.4 try to kill process that mmaped most
> memory? mmap is hamrless. mmap on files can't eat memory and swap.
Don't complain, build your own and test it ;-)
Apply my patch
http://www.tu-chemnitz.
Hi Mikulas,
On Wed, 8 Nov 2000, Mikulas Patocka wrote:
> BTW. Why does your OOM killer in 2.4 try to kill process that mmaped
> most memory? mmap is hamrless. mmap on files can't eat memory and
> swap.
Be careful: They may have shm segments mmaped!
Greetings
Christoph
-
To unsu
Hi.
> > I also didn't say non-overcommit should be used as default and a
> > patch http://www.cs.helsinki.fi/linux/linux-kernel/2000-13/1208.html,
> > developed for 2.3.99-pre3 by Eduardo Horvath and unfortunately was
> > ignored completely, implemented it this way.
>
> OK. This is a lot more r
--
> On Wed, 8 Nov 2000, Szabolcs Szakacsits wrote:
> > On Mon, 6 Nov 2000, Rik van Riel wrote:
[snip]
> > You could ask, so what's the point for non-overcommit if we use
> > process killing in the end? And the answer, in *practise* this almost
> > never happens, root can always clean up and n
On Wed, 8 Nov 2000, Szabolcs Szakacsits wrote:
> On Mon, 6 Nov 2000, Rik van Riel wrote:
> > On Mon, 6 Nov 2000, Szabolcs Szakacsits wrote:
> > > On Wed, 1 Nov 2000, Rik van Riel wrote:
> > > > but simply because
> > > > it appears there has been amazingly little research on this
> > > > subject
On Mon, 6 Nov 2000, Rik van Riel wrote:
> On Mon, 6 Nov 2000, Szabolcs Szakacsits wrote:
> > On Wed, 1 Nov 2000, Rik van Riel wrote:
> > > but simply because
> > > it appears there has been amazingly little research on this
> > > subject and it's completely unknown which approach will work
> >
On Mon, 6 Nov 2000, Szabolcs Szakacsits wrote:
> On Wed, 1 Nov 2000, Rik van Riel wrote:
>
> > but simply because
> > it appears there has been amazingly little research on this
> > subject and it's completely unknown which approach will work
>
> There has been lot of research, this is the re
On Wed, 1 Nov 2000, Rik van Riel wrote:
> I'm definately looking forward to an "OOM killer showdown"
> where we can compare how the different OOM tactics work.
Since people must live with Linux's overcommiting feature the winner
would be the one that could be tuned runtime. The best general pu
18 matches
Mail list logo
