kern/87255: Large malloc-backed mfs crashes the system

[Yar Tikhiy]

On Tue, Oct 11, 2005 at 04:55:09PM +0200, Poul-Henning Kamp wrote:
> In message <200510111450.j9BEoLEB006718 at freefall.freebsd.org>, Yar Tikhiy write
> > Just for the record:
> > 
> > The problem seems to involve vfs-md interaction
> > as filling just a bogusly large malloc-backed md
> > device results in harmless ENOSPC at some point.
> 
> ENOSPC may be a problem for filesystems, try changing it to EIO and
> see if they cope better with that.

Tried to, replaced all ENOSPC codes with EIO in sys/dev/md/md.c,
but alas, the problem still is there with exactly the same symptoms.

> In all cases it is a "don't do that then" class of problem.

Yes, of course.  The question is whether we consider it normal
for root to have ability to panic the system using standard tools.
"cat /dev/zero > /dev/mem" still is the ultimate way to.  IMHO it
is a key issue whether we fall back at the academical/research stage
where rough corners are OK and the system is just a toy for eggheads,
or we pretend our system is stable and robust.  I doubt if an admin
can crash the Windows NT kernel from the userland using conventional
interfaces.  I by no means expect this issue to be resolved soon, but
it's worth being reflected on at tea-time :-)

Apropos, here's another reproducible crash induced by md:

	# mdconfig -a -t malloc -s 300m
	md0
	# dd if=/dev/urandom of=/dev/md0 bs=1
	dd: /dev/md0: Input/output error
	79+0 records in
	78+9 records out
	# reboot
	panic: kmem_malloc(4096): kmem_map too small: 86224896 total allocated

Apparently, it is not a fault of md, just our kernel memory
allocator allows other kernel parts to starve it to death.

-- 
Yar