From owner-freebsd-bugs@FreeBSD.ORG Sat Nov 15 07:10:20 2003 Return-Path: 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 94D7E16A4CE for ; Sat, 15 Nov 2003 07:10:20 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D42643FD7 for ; Sat, 15 Nov 2003 07:10:18 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hAFFAIFY041767 for ; Sat, 15 Nov 2003 07:10:18 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hAFFAI4x041766; Sat, 15 Nov 2003 07:10:18 -0800 (PST) (envelope-from gnats) Resent-Date: Sat, 15 Nov 2003 07:10:18 -0800 (PST) Resent-Message-Id: <200311151510.hAFFAI4x041766@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Dmitry Morozovsky Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0994616A4CE; Sat, 15 Nov 2003 07:03:16 -0800 (PST) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A112643FD7; Sat, 15 Nov 2003 07:03:14 -0800 (PST) (envelope-from marck@woozle.rinet.ru) Received: from woozle.rinet.ru (localhost [127.0.0.1]) by woozle.rinet.ru (8.12.10/8.12.10) with ESMTP id hAFF3DSC058162; Sat, 15 Nov 2003 18:03:13 +0300 (MSK) (envelope-from marck@woozle.rinet.ru) Received: (from marck@localhost) by woozle.rinet.ru (8.12.10/8.12.10/Submit) id hAFF3DFL058161; Sat, 15 Nov 2003 18:03:13 +0300 (MSK) (envelope-from marck) Message-Id: <200311151503.hAFF3DFL058161@woozle.rinet.ru> Date: Sat, 15 Nov 2003 18:03:13 +0300 (MSK) From: Dmitry Morozovsky To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 cc: grog@FreeBSD.org Subject: kern/59303: vinum crashes kernel if concurrent reviving attempts X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Dmitry Morozovsky List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 15:10:20 -0000 >Number: 59303 >Category: kern >Synopsis: vinum crashes kernel if concurrent reviving attempts >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Nov 15 07:10:17 PST 2003 >Closed-Date: >Last-Modified: >Originator: Dmitry Morozovsky >Release: FreeBSD 4-STABLE i386 >Organization: Cronyx Plus LLC (RiNet ISP) >Environment: System: FreeBSD 4-STABLE (4.9-R for instance) mini-kernel (derived from GENERIC, most devices deleted, nothing added) vinum module >Description: It seems vinum somehow destroy portions of kernel memory when admin (incorrectly) requests start operation on currently reviving subdisk. In multiuser mode, kernel usually panics on syslogd write request. However, it is possible, though not so easy, to crash kernel even when all filesystems are in read-only mode, only via read requests. Some tracebacks may be found at http://woozle.hole.ru/misc/vinum/revive/ Coredumps are saved, I would be glad to provide additional info. >How-To-Repeat: - create example vinum mirror: disklabel -e da0 ... disklabel -e da1 vinum create drive a da0h drive b da1h volume test setupstate plex org concat sd len 1g drive a plex org concat sd len 1g drive b newfs -U -v /dev/vinum/test - emulate disk crash: vinum setstate stale test.p1.s0 vinum setstate faulty test.p1 - the following sequence in multiuser mode leads to immediate panic with syslogd as current process (see bt5.txt): vinum start test.p1; sleep 2; \ vinum start; sleep 2; \ vinum start - in single-user mode, mounting every FS r/o, you can still crash kernel via sequence above, followed by _some_ (not so easily reproducible) disk activity, such as ls, su, find or even ps (all other backtraces). >Fix: Unknown for the moment. >Release-Note: >Audit-Trail: >Unformatted: