Bug 14486

Summary: repeated arrival/departure of disks leads to panic in dscheck
Product: Base System Reporter: mjacob <mjacob>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description mjacob 1999-10-23 21:00:00 UTC 
repeated arrivals/departures of disks, sometimes with the labels changed,
yields a panic:

Stopped at      dscheck+0x53:   movl    0x10(%edx),%esi
db> t
dscheck(c3327a38,0) at dscheck+0x53
diskstrategy(c3327a38,c0ae4780,200,c0a4db80,0) at diskstrategy+0xad
readdisklabel(c0ae4780,c0a51600,c0a4db80,c0b1e8e0,c0a4db80) at readdisklabel+0x5
3
dsopen(c0a4db80,2000,0,c0b1e8ec,c0b1e8f0) at dsopen+0x248
diskopen(c0a4db80,1,2000,c7c77800,0) at diskopen+0xdb
spec_open(c86afe08,c86afde0,c020ecd9,c86afe08,c86afe7c) at spec_open+0x154
spec_vnoperate(c86afe08,c86afe7c,c0190ace,c86afe08,0) at spec_vnoperate+0x15
ufs_vnoperatespec(c86afe08,0,c86aff80,fffffffc,100) at ufs_vnoperatespec+0x15
vn_open(c86afed8,1,dfd,c7c77800,3) at vn_open+0x37e
open(c7c77800,c86aff80,1,1b0a,bfbfdad1) at open+0xbb
syscall(2f,2f,2f,bfbfdad1,1b0a) at syscall+0x1b1
Xsyscall() at Xsyscall+0x3a

with Supervisor page niot present... This should be enough information
for the responsible designers to do the appropriate hardening.
Comment 1 Bruce Evans 1999-10-29 13:01:28 UTC 
> >Description:
> 
> repeated arrivals/departures of disks, sometimes with the labels changed,
> yields a panic:
> 
> Stopped at      dscheck+0x53:   movl    0x10(%edx),%esi
> db> t
> dscheck(c3327a38,0) at dscheck+0x53
> diskstrategy(c3327a38,c0ae4780,200,c0a4db80,0) at diskstrategy+0xad
> readdisklabel(c0ae4780,c0a51600,c0a4db80,c0b1e8e0,c0a4db80) at readdisklabel+0x5
> 3
> dsopen(c0a4db80,2000,0,c0b1e8ec,c0b1e8f0) at dsopen+0x248
> diskopen(c0a4db80,1,2000,c7c77800,0) at diskopen+0xdb

Rev.1.39 of scsi_da.c (actually, all revs. of subr_disk.c) seems to be
quite buggy.  diskopen(), at least, doesn't seem to do sufficient locking.
The old daopen() holds a lock for essentially the whole open, but
diskopen() allows concurrent opens (and closes!).  Bad things probably
happen if the label is changed.  Even null changes may cause problems if
they are not atomic.

Bruce
Comment 2 Poul-Henning Kamp freebsd_committer freebsd_triage 1999-11-06 10:26:05 UTC 
State Changed
From-To: open->closed