From owner-freebsd-bugs@FreeBSD.ORG Wed Oct 26 09:07:43 2005 Return-Path: X-Original-To: freebsd-bugs@FreeBSD.org Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDC0616A44B; Wed, 26 Oct 2005 09:07:43 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC8EF43D48; Wed, 26 Oct 2005 09:07:42 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j9Q97dvZ048618; Wed, 26 Oct 2005 13:07:39 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j9Q97bnj048596; Wed, 26 Oct 2005 13:07:37 +0400 (MSD) (envelope-from yar) Date: Wed, 26 Oct 2005 13:07:37 +0400 From: Yar Tikhiy To: Poul-Henning Kamp Message-ID: <20051026090736.GB44697@comp.chem.msu.su> References: <200510111450.j9BEoLEB006718@freefall.freebsd.org> <23000.1129042509@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23000.1129042509@critter.freebsd.dk> User-Agent: Mutt/1.5.9i Cc: freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/87255: Large malloc-backed mfs crashes the system X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 09:07:44 -0000 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