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

Yar Tikhiy yar at comp.chem.msu.su
Wed Oct 26 02:10:22 PDT 2005


The following reply was made to PR kern/87255; it has been noted by GNATS.

From: Yar Tikhiy <yar at comp.chem.msu.su>
To: Poul-Henning Kamp <phk at phk.freebsd.dk>
Cc: freebsd-bugs at FreeBSD.org, bug-followup at FreeBSD.org
Subject: Re: kern/87255: Large malloc-backed mfs crashes the system
Date: Wed, 26 Oct 2005 13:07:37 +0400

 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


More information about the freebsd-bugs mailing list