[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87prgg6sj2.fsf@devron.myhome.or.jp>
Date: Wed, 18 Mar 2009 01:08:49 +0900
From: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] deadlock when swapping to FAT
Mikulas Patocka <mpatocka@...hat.com> writes:
> On Sun, 15 Mar 2009, OGAWA Hirofumi wrote:
>
>> Mikulas Patocka <mpatocka@...hat.com> writes:
>>
>> > Note that the same race condition is happening in all the other
>> > filesystems. Maybe move that i_alloc_sem up to ->bmap method caller?
>>
>> It can be. However, I guess locking strategy would be per
>> filesystems. Because the fs may be using i_alloc_sem in get_block
>> already.
>
> Which ones take it in get_block? I grepped for i_alloc_sem and don't see
> them. Besides, it is mostly taken only for read and recursive taking of
> read-lock for read is allowed. It is taken for writes only in truncate.
I don't know which fs take it, and whether i_alloc_sem is enough for
which fs. It was just guess. And important one is locking strategy of
that would be per filesystems. E.g. it seems XFS is taking own lock.
Well, personally, I don't have objection to add i_alloc_sem, however I'm
not sure, what does i_alloc_sem guarantee for other fs.
--
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists