Date: Sat, 15 Nov 2003 18:03:13 +0300 (MSK) From: Dmitry Morozovsky <marck@rinet.ru> To: FreeBSD-gnats-submit@FreeBSD.org Cc: grog@FreeBSD.org Subject: kern/59303: vinum crashes kernel if concurrent reviving attempts Message-ID: <200311151503.hAFF3DFL058161@woozle.rinet.ru> Resent-Message-ID: <200311151510.hAFFAI4x041766@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311151503.hAFF3DFL058161>