From marck@woozle.rinet.ru  Sat Nov 15 07:03:16 2003
Return-Path: <marck@woozle.rinet.ru>
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 <marck@rinet.ru>
Reply-To: Dmitry Morozovsky <marck@rinet.ru>
To: FreeBSD-gnats-submit@freebsd.org
Cc: grog@freebsd.org
Subject: vinum crashes kernel if concurrent reviving attempts
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         59303
>Category:       kern
>Synopsis:       [vinum] vinum crashes kernel if concurrent reviving attempts
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    le
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Nov 15 07:10:17 PST 2003
>Closed-Date:    Sat Nov 26 15:41:46 GMT 2005
>Last-Modified:  Sat Nov 26 15:41:46 GMT 2005
>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:
Responsible-Changed-From-To: freebsd-bugs->grog 
Responsible-Changed-By: kris 
Responsible-Changed-When: Sat Nov 15 13:24:33 PST 2003 
Responsible-Changed-Why:  
Assign to vinum author 

http://www.freebsd.org/cgi/query-pr.cgi?pr=59303 

From: Dmitry Morozovsky <marck@rinet.ru>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: kern/59303: followup
Date: Sun, 25 Apr 2004 21:38:47 +0400 (MSD)

 Testing with today's 4.10-RC sources, I can't reproduce the panic. Still, in
 some situations vinum starts more than one reviving process on the same
 subdisk, which I think should be avoided by some kind of locking. Also, after
 concurrent reviving attempts subdisk referred has been out in inaccessible
 state, so any attempt to revive it after lock fails with
 
 # vinum start test.p1.s0
 Can't start test.p1.s0: Drive is down (5)
 
 Which could be avoided onle by reloading vinum, which is troublesome when you
 have loaded vinum system or (which is even more painful) have vinum root
 installed (so you cant unload vinum module on the fly)
 
 Unfortunately, I can't provide patches for any part of this issue.
 
 
 Sincerely,
 D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
 ------------------------------------------------------------------------
 *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
 ------------------------------------------------------------------------
Responsible-Changed-From-To: grog->le 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Sep 9 19:04:32 GMT 2004 
Responsible-Changed-Why:  
With permission of both, reassign from grog to le. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=59303 
State-Changed-From-To: open->closed 
State-Changed-By: le 
State-Changed-When: Sat Nov 26 15:40:57 GMT 2005 
State-Changed-Why:  
Since 'classic' vinum isn't supported anymore, I'm closing this PR. 

If the described behaviour is still happening on newer systems with 
geom_vinum, a new PR can be opened. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=59303 
>Unformatted:
