DoS tmpfs,ramfs, malloc, saga continues

DoS tmpfs,ramfs, malloc, saga continues

[Ivan Kalvatchev]

As Alan Cox pointed me, tmpfs bug is a VM bug. I was
able to reproduce the bug with a simple memory
"eating" program. (for the lazy ones copy-paste from
bottom).
As oom_kill.c says:
"...
*If we run out of memory, we have the choice between
either
 * killing a random task (bad), letting the system
crash (worse)
 * OR try to be smart about which process to kill.
Note that we
 * don't have to be perfect here, we just have to be
good.
 *
..."
Oh, how dumb. Now the system kills random tasks and
hangs with 50% probability. Just run the sample
program twice. Oh, system hangs while waiting for kill
(I wont wait for months). 
Good job for Alan Cox, with his patch i could run the
sample program 20 times before it crashed the system.
I cannot belive that instead of keeping this
masskiller for deathlocks, no way out situation, and
as last resort, You The Great Kernel Hackers use it
for every day and every body solution. Is it so hard
to make more memory checks for user level malloc?
Windows does. Every other OS does. Why linux doesn't? 
Fix it in the next kernel!

//-------------------eatmem.c-------------------
#include <stdio.h>
#include <stdlib.h>
int main()
{
int i;
void *p;
	for(i=0;;i++)
	{
		p=malloc(4096);
		printf("malloc #%d (%p)\n",i,p);
		if(p==NULL) break;
	}
	printf("I can't free mem:)");
return 0;
}


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: DoS tmpfs,ramfs, malloc, saga continues

[Alan Cox]

> Good job for Alan Cox, with his patch i could run the
> sample program 20 times before it crashed the system.
> I cannot belive that instead of keeping this
> masskiller for deathlocks, no way out situation, and
> as last resort, You The Great Kernel Hackers use it
> for every day and every body solution. Is it so hard
> to make more memory checks for user level malloc?
> Windows does. Every other OS does. Why linux doesn't? 
> Fix it in the next kernel!

ROTFL

If you cant crash windows nt by running out of memory you aren't doing the
right things.  Just for example feed the Nvidia direct X an infinite number
of objects to draw.

The basic answer is "Set resource limits". The default ones fit typical
usage of a system well but not your case. The more complex answer is to
provide the option for very precise group based resource accounting (aka
the beancounter patch). That is for those who want to pay the probable 2%
or so system penalty for being able to precisely manage a system resource
set. With the beancounter infrastructure you can then get to the point where
student processes are being OOM killed while the admins quake session is
unharmed.

Somewhere in the middle there is address space accounting, where you never 
allow the total address space to violate

	(read-only-pages +
		foreach writeable page
			number of extant copies +
				numer of COW potential copies
	) - kernel fudge factor (space the kernel might need)
	
			>

		    ram + swap


That is much more lightweight and covers all the general cases. However
nobody wants it much as is evident by the fact nobody has either contributed
code or paid for the work to be done

Alan

Re: DoS tmpfs,ramfs, malloc, saga continues

[Szabolcs Szakacsits]

On Tue, 14 Aug 2001, Alan Cox wrote:

> If you cant crash windows nt by running out of memory you aren't doing the
> right things.

Alan, although I didn't completely get what patch Ivan refered, 2.4.8
seems to be the far most instable when OOM happens (it just never
survived the 2nd wave of memory stressing for me).

> The basic answer is "Set resource limits". The default ones fit typical

Sure, every experienced user knows that but many people are lazy, busy,
etc to do it properly and most newcomers, desktop users basically don't
want to know about it. Forget distributors setting unreasonable limits
for them, kernel just shouldn't crash in OOM - it could handle it in the
past. This OOM issue wasn't such big problem in the past but recently
it's really getting scary. I've ported the OOM killer to 2.2 and added
reserved root VM support and AFAIR I mentioned only once here, google
indexed the page and people hits it increasingly -- about 10-20 times
more often then OOM problems pop up here. Most of them USER_AGENT
contains the Windows word - and yes, they are explicitely looking for
solution for Linux related OOM problems.

> usage of a system well but not your case. The more complex answer is to
> provide the option for very precise group based resource accounting (aka
> the beancounter patch). That is for those who want to pay the probable 2%
> or so system penalty for being able to precisely manage a system resource
> set. With the beancounter infrastructure you can then get to the point where

It's not ready for use. It was touched last time about one year ago for
2.4.0-test7.

> Somewhere in the middle there is address space accounting, where you never
> allow the total address space to violate

BTW, 2.4 has another feature. vm_enough_memory() in 2.2 underestimated
the available free memory (memory is overcommited anyway) and apps got
more frequently ENOMEM. 2.4 overestimates free memory (because
e.g. nobody knows how much cache could be freed) so apps get killed
mostly by OOM killer.

[ ... non-overcommitting algorithm ...]
> That is much more lightweight and covers all the general cases. However
> nobody wants it much as is evident by the fact nobody has either contributed
> code or paid for the work to be done

In most cases I would definitely agree with this argument but I think in
this case people who have this problem either can't code it themself or
"can't" pay for it - they just expect (unconsciously) Linux can handle
OOM just as good as others or even better.

	Szaka

Re: DoS tmpfs,ramfs, malloc, saga continues

[Andrey Savochkin]

On Wed, Aug 15, 2001 at 05:20:09PM +0300, Szabolcs Szakacsits wrote:
> 
> > usage of a system well but not your case. The more complex answer is to
> > provide the option for very precise group based resource accounting (aka
> > the beancounter patch). That is for those who want to pay the probable 2%
> > or so system penalty for being able to precisely manage a system resource
> > set. With the beancounter infrastructure you can then get to the point where
> 
> It's not ready for use. It was touched last time about one year ago for
> 2.4.0-test7.

I just can't spare time now to maintain the patch properly and make a port
for each kernel release.
When 2.5 is started, I've promised myself to put other things aside and work
on the patch to have it in the mainstream.

	Andrey