From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762221AbZCQMXl (ORCPT ); Tue, 17 Mar 2009 08:23:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754777AbZCQMXc (ORCPT ); Tue, 17 Mar 2009 08:23:32 -0400 Received: from mx1.redhat.com ([66.187.233.31]:56077 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754512AbZCQMXc (ORCPT ); Tue, 17 Mar 2009 08:23:32 -0400 Date: Tue, 17 Mar 2009 08:23:28 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com To: OGAWA Hirofumi cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] deadlock when swapping to FAT In-Reply-To: <878wn7h3la.fsf@devron.myhome.or.jp> Message-ID: References: <87zlfqohfn.fsf@devron.myhome.or.jp> <878wn7h3la.fsf@devron.myhome.or.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Mikulas > Thanks. > -- > OGAWA Hirofumi >