Messages in this thread | | | Subject | Re: [RFC] Reverting "bd_mount_mutex" to "bd_mount_sem" | From | Arjan van de Ven <> | Date | Tue, 10 Oct 2006 17:19:05 +0200 |
| |
On Tue, 2006-10-10 at 20:34 +0530, Srinivasa Ds wrote: > Eric Sandeen wrote: > > Ingo Molnar wrote: > > > >> * Srinivasa Ds <srinivasa@in.ibm.com> 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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |