Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759362AbZCQQJN (ORCPT ); Tue, 17 Mar 2009 12:09:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755123AbZCQQI4 (ORCPT ); Tue, 17 Mar 2009 12:08:56 -0400 Received: from mail.parknet.ad.jp ([210.171.162.6]:44534 "EHLO mail.officemail.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755203AbZCQQI4 (ORCPT ); Tue, 17 Mar 2009 12:08:56 -0400 From: OGAWA Hirofumi To: Mikulas Patocka Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] deadlock when swapping to FAT References: <87zlfqohfn.fsf@devron.myhome.or.jp> <878wn7h3la.fsf@devron.myhome.or.jp> Date: Wed, 18 Mar 2009 01:08:49 +0900 In-Reply-To: (Mikulas Patocka's message of "Tue, 17 Mar 2009 08:23:28 -0400 (EDT)") Message-ID: <87prgg6sj2.fsf@devron.myhome.or.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.10/RELEASE, bases: 24052007 #308098, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1297 Lines: 30 Mikulas Patocka writes: > On Sun, 15 Mar 2009, OGAWA Hirofumi wrote: > >> Mikulas Patocka 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 -- 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/