Date: Wed, 26 Oct 2005 13:07:37 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/87255: Large malloc-backed mfs crashes the system Message-ID: <20051026090736.GB44697@comp.chem.msu.su> In-Reply-To: <23000.1129042509@critter.freebsd.dk> References: <200510111450.j9BEoLEB006718@freefall.freebsd.org> <23000.1129042509@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 11, 2005 at 04:55:09PM +0200, Poul-Henning Kamp wrote: > In message <200510111450.j9BEoLEB006718@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051026090736.GB44697>