[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Oct 2006 20:34:30 +0530
From: Srinivasa Ds <srinivasa@...ibm.com>
To: Eric Sandeen <sandeen@...deen.net>
CC: Ingo Molnar <mingo@...e.hu>, dm-devel@...hat.com,
linux-lvm@...hat.com, linux-kernel@...r.kernel.org, agk@...hat.com
Subject: Re: [RFC] Reverting "bd_mount_mutex" to "bd_mount_sem"
Eric Sandeen wrote:
> Ingo Molnar wrote:
>
>> * Srinivasa Ds <srinivasa@...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.
Signed-off-by: Srinivasa DS <srinivasa@...ibm.com>
View attachment "dmsetup.fix" of type "text/plain" (2389 bytes)
Powered by blists - more mailing lists