From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: [PATCH] exofs: remove BKL from super operations Date: Sun, 23 Aug 2009 16:40:30 +0300 Message-ID: <4A9146CE.1080409@panasas.com> References: <4A8C12AE.2010801@panasas.com> <20090819234933.GB12113@lst.de> <4A91305E.1030909@panasas.com> <20090823133107.GA25220@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel To: Christoph Hellwig Return-path: Received: from ip67-152-220-67.z220-152-67.customer.algx.net ([67.152.220.67]:4613 "EHLO daytona.int.panasas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933741AbZHWNkh (ORCPT ); Sun, 23 Aug 2009 09:40:37 -0400 In-Reply-To: <20090823133107.GA25220@lst.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 08/23/2009 04:31 PM, Christoph Hellwig wrote: > On Sun, Aug 23, 2009 at 03:04:46PM +0300, Boaz Harrosh wrote: >> On 08/20/2009 02:49 AM, Christoph Hellwig wrote: >>> Any chance you could also remove the lock_super usage once your start >>> revisiting the lock? lock_super is never taken by the VFS anymore, so >>> you can easily replace it with fs-local locking. >>> >> >> OK Sure, thanks. >> >> One question please? >> >> I need a mutex_lock I can sleep on. Could I use the inode_lock associate >> with the root_inode. Or that could lead to dead-locks with the VFS? > > It could lead to all kinds of lock dependency problems no one even > thinks about. > >> (Or should I just allocate another mutex at the fs-sb-data?) > > Yes. > Thanks, I'll do that