From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: [PATCH 2/2] ->write_super lock_super pushdown Date: Tue, 12 May 2009 13:10:10 +0300 Message-ID: <4A094B02.20606@panasas.com> References: <20090511213503.GB19326@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from gw-ca.panasas.com ([209.116.51.66]:24716 "EHLO laguna.int.panasas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751941AbZELKKM (ORCPT ); Tue, 12 May 2009 06:10:12 -0400 In-Reply-To: <20090511213503.GB19326@lst.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 05/12/2009 12:35 AM, Christoph Hellwig wrote: > Push down lock_super into ->write_super instances and remove it from the > caller. > > Following filesystem don't need ->s_lock in ->write_super and are skipped: > > * bfs, nilfs2 - no other uses of s_lock and have internal locks in > ->write_super > * ext2 - uses BKL in ext2_write_super and has internal calls without s_lock > * reiserfs - no other uses of s_lock as has reiserfs_write_lock (BKL) in > ->write_super > * xfs - no other uses of s_lock and uses internal lock (buffer lock on > superblock buffer) to serialize ->write_super. Also xfs_fs_write_super > is superflous and will go away in the next merge window > > > Signed-off-by: Christoph Hellwig > Ack-by Boaz Harrosh > =================================================================== > --- vfs-2.6.orig/fs/exofs/super.c 2009-05-11 23:26:24.971786995 +0200 > +++ vfs-2.6/fs/exofs/super.c 2009-05-11 23:28:12.929808342 +0200 > @@ -214,6 +214,7 @@ static void exofs_write_super(struct sup > return; > } > > + lock_super(sb); > lock_kernel(); > sbi = sb->s_fs_info; > fscb->s_nextid = cpu_to_le64(sbi->s_nextid); > @@ -246,6 +247,7 @@ out: > if (or) > osd_end_request(or); > unlock_kernel(); > + unlock_super(sb); > kfree(fscb); > } > Please I have a question about this? lock_super(): I do not see any other lock_super() in exofs, so all this might "lock" is race against itself, right? Should I make sure that concurrent exofs_write_super are protected some other way and remove this? lock_kernel(); What is that used for? What should I check so this can be removed? Sorry for the novice-ness ;-) Thanks Boaz