From owner-freebsd-bugs  Sun Aug 10 14:20:07 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id OAA15876
          for bugs-outgoing; Sun, 10 Aug 1997 14:20:07 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id OAA15856;
          Sun, 10 Aug 1997 14:20:03 -0700 (PDT)
Resent-Date: Sun, 10 Aug 1997 14:20:03 -0700 (PDT)
Resent-Message-Id: <199708102120.OAA15856@hub.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, andrew@erlenstar.demon.co.uk
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
X-Send-Pr-Version: www-1.0
Subject: kern/4265: Panic in dsinit when multiple FreeBSD slices exist on one disk
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


>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:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug 10 14:20:01 PDT 1997
>Last-Modified:
>Originator:     Andrew Gierth
>Organization:
>Release:        2.2-STABLE
>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.

>Audit-Trail:
>Unformatted: