On Tue, 2006-10-10 at 20:34 +0530, Srinivasa Ds wrote: > Eric Sandeen wrote: > > Ingo Molnar wrote: > > > >> * Srinivasa Ds <srinivasa@xxxxxxxxxx> wrote: > >> > >> > >>> On debugging I found out that,"dmsetup suspend <device name>" calls > >>> "freeze_bdev()",which locks "bd_mount_mutex" to make sure that no new > >>> mounts happen on bdev until thaw_bdev() is called. > >>> This "thaw_bdev()" is getting called when we resume the device > >>> through "dmsetup resume <device-name>". > >>> Hence we have 2 processes,one of which locks > >>> "bd_mount_mutex"(dmsetup suspend) and Another(dmsetup resume) unlocks > >>> it. > >>> > >> hm, to me this seems quite a fragile construct - even if the > >> mutex-debugging warning is worked around by reverting to a semaphore. > >> > >> Ingo > >> > > > > Ingo, what do you feel is fragile about this? It seems like this is a > > reasonable way to go, except that maybe a down_trylock would be good if > > a 2nd process tries to freeze while it's already frozen... > > > > Thanks, > > > > -Eric > > > Ingo, As per the discussion resending the patch with down_trylock. Hi, I still think that effectively exporting this semaphore to userspace is a big design mistake; but at least it can't be a mutex for this reason so the patch is sane in that regard... Greetings, Arjan van de Ven -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
