Re: Locking in disk(9) api

[David Young <dyoung%pobox.com@localhost>]

On Tue, Dec 29, 2009 at 08:06:40AM +0000, Michael van Elst wrote:
> haaaad%gmail.com@localhost (Adam Hamsik) writes:
> 
> >I looked at fss driver and I think that it is working by luck only [1]. =
> >disk_unbusy iw for example called without any lock held. In [2] =
> >disk_busy/disk_unbusy is called without any lock held, too.
> 
> Maybe. fss calls disk_*busy in a separate thread, where do you
> see concurrent operations?
> 
> >If you are ok with my patch attached below I will commit it .
> 
> I wouldn't use dk_openlock, just keep a private lock with the
> dm instance. dk_openlock is used by the dk driver internally,
> it is also abused by ld(4) and md(4) because they replicate
> parts of the dk driver.

dk_openlock synchronizes access to dk_{b,c,}openmask in struct disk.  A
disk driver has to use it.

ld(4) and md(4) may not use correct synchronization or accessors with
struct disk, but disk-like devices are correct to use struct disk.
You may be confusing disk(9) and dk(4), or struct disk and struct
dkwedge_softc: besides dk(4), disk drivers should not use dkwedge_softc.

It looks to me like a dk(4) instance ("wedge") does access
dk_{b,c,}openmask on its parent's struct disk, so it is not sufficient
for dm(4) to synchronize access with itself, it has to synchronize with
any wedges configured on top, too, using dk_openlock.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933