kern/85329: vinum dumpconfig destroys openmask and let FreeBSD 4.11 Stable crash

Andreas Longwitz longwitz at
Fri Aug 26 21:50:02 GMT 2005

>Number:         85329
>Category:       kern
>Synopsis:       vinum dumpconfig destroys openmask and let FreeBSD 4.11 Stable crash
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Aug 26 21:50:01 GMT 2005
>Originator:     Andreas Longwitz
Data Service Stockelsdorf, Germany
4.11-STABLE FreeBSD 4.11-STABLE #0: Thu Aug  4 00:39:17 CEST 2005     root at bsdmhs.longwitz:/usr/obj/usr/src/sys/BSDMHS  i386
The byte ds_openmask is handled by the routines dsopen/dsclose in
subr_diskslice.c and stores the partitions used on the disk. If e.g.
the diskslice da1s1 on the system is completely used by vinum, then 
  disklist->lh_first->d_slice->dss_slices[2].ds_openmask = 0x80,
because vinum sets this bit for the h-partition from open_drive.

Now running 
  vinum dumpconfig da1s1
clears the highest bit in the openmask-byte, because the vinum
program (/usr/src/sbin/vinum/list.c) opens and - with program end -
closes the device "/dev/da1s1h". 

Now running again
  vinum dumpconfig da1s1
lets the kernel (dsopen in subr_diskslice.c) think, that the disk has gone:
       ssp = *sspp;
       need_init = !dsisopen(ssp);    <-- openmask = 0!
       if (ssp != NULL && need_init)

In dsgone memory used by vinum - especially the disklabel -
is freed and if there is some activity on the vinum disk
at this time the system crashes immediately, otherwise it crashes
some time later.

The dumps look like the one described in kern/52916 and kern/58391.
The first hint of the problem I describe here was given in kern/74915. 

On FreeBSD 4.11 Stable give vinum a whole disk and run twice
vinum dumpconfig for this disk. If you e.g. copy a big file on the
vinum disk during this test, the system panics. Please set a
breakpoint at dsgone to avoid the crash.       
It seems to me, that the kernel is not aware of vinum, because
vinum opens the disk not with the open-syscall. I don't know how
to fix this.     

More information about the freebsd-bugs mailing list