From owner-freebsd-bugs@FreeBSD.ORG Wed Oct 26 09:10:21 2005 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBFC916A434 for ; Wed, 26 Oct 2005 09:10:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DE2243D53 for ; Wed, 26 Oct 2005 09:10:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9Q9AKKH075168 for ; Wed, 26 Oct 2005 09:10:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9Q9AKtg075166; Wed, 26 Oct 2005 09:10:20 GMT (envelope-from gnats) Date: Wed, 26 Oct 2005 09:10:20 GMT Message-Id: <200510260910.j9Q9AKtg075166@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Yar Tikhiy Cc: 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 Reply-To: Yar Tikhiy List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 09:10:22 -0000 The following reply was made to PR kern/87255; it has been noted by GNATS. From: Yar Tikhiy To: Poul-Henning Kamp 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