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