From nobody  Sun Aug 10 14:17:13 1997
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id OAA15679;
          Sun, 10 Aug 1997 14:17:13 -0700 (PDT)
Message-Id: <199708102117.OAA15679@hub.freebsd.org>
Date: Sun, 10 Aug 1997 14:17:13 -0700 (PDT)
From: andrew@erlenstar.demon.co.uk
To: freebsd-gnats-submit@freebsd.org
Subject: Panic in dsinit when multiple FreeBSD slices exist on one disk
X-Send-Pr-Version: www-1.0

>Number:         4265
>Category:       kern
>Synopsis:       Panic in dsinit when multiple FreeBSD slices exist on one disk
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug 10 14:20:01 PDT 1997
>Closed-Date:    Tue Mar 27 04:18:05 PST 2001
>Last-Modified:  Tue Mar 27 04:23:09 PST 2001
>Originator:     Andrew Gierth
>Release:        2.2-STABLE
>Organization:
>Environment:
FreeBSD erlenstar.demon.co.uk 2.2-STABLE FreeBSD 2.2-STABLE #0: Sun Aug 10 21:21:51 BST 1997     root@:/usr/src/sys/compile/LOCAL  i386

>Description:
System panics when fsck -p is invoked (if kernel built with DIAGNOSTIC)
or shortly thereafter (if not built with DIAGNOSTIC). This occurs if
multiple FreeBSD slices are used on a disk (other than the root disk?).
The panic is due to a race condition in dsopen/dsinit; dsopen is being
called simultaneously from two of the fsck subprocesses, and this
sequence results:

dsopen() called; dsopen() calls dsinit(); dsinit() allocates dummy
slice table and stores its address; a context switch occurs
dsopen() called again; dsisopen() is false at this point, but a
slice table for the unit is present (the dummy one allocated above) so
dsgone() is called, freeing the slice table;
dsinit() resumes, and calls free() on the dummy slice table to replace
it with the real one, but panics as it has already been freed.

>How-To-Repeat:
timing dependent, so it might be hard, but creating a filesystem on a
second FreeBSD slice on a non-root disk and adding a suitable entry
to /etc/fstab, then rebooting and running fsck -p, does it every time
for me.

>Fix:
dsopen needs to be protected against simultaneous calls for multiple
slices on the same physical unit.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Mon Mar 26 15:45:29 PST 2001 
State-Changed-Why:  
Is this still a problem in more recent releases? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4265 
State-Changed-From-To: feedback->closed 
State-Changed-By: iedowse 
State-Changed-When: Tue Mar 27 04:18:05 PST 2001 
State-Changed-Why:  
It looks like this was fixed in revision 1.14 of subr_disk.c, and 
there are no recent references to this problem in the archives. 

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