Date: Wed, 26 Oct 2005 09:10:20 GMT From: Yar Tikhiy <yar@comp.chem.msu.su> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/87255: Large malloc-backed mfs crashes the system Message-ID: <200510260910.j9Q9AKtg075166@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/87255; it has been noted by GNATS. 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 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@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?200510260910.j9Q9AKtg075166>