From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:60064 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750842AbcAXHsx (ORCPT ); Sun, 24 Jan 2016 02:48:53 -0500 Date: Sun, 24 Jan 2016 07:48:50 +0000 From: Al Viro To: Dave Chinner Cc: Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [git pull] vfs.git - including i_mutex wrappers Message-ID: <20160124074850.GY17997@ZenIV.linux.org.uk> References: <20160123145854.GM17997@ZenIV.linux.org.uk> <20160123223456.GH6033@dastard> <20160123224435.GI6033@dastard> <20160123230944.GR17997@ZenIV.linux.org.uk> <20160124005304.GK6033@dastard> <20160124014111.GV17997@ZenIV.linux.org.uk> <20160124070406.GL6033@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160124070406.GL6033@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Jan 24, 2016 at 06:04:06PM +1100, Dave Chinner wrote: > Hence even for ->setattr, we can remove the IOLOCK usage if the > vfs takes the the new i_rwsem in exclusive mode because we would > still have a functional IO submission barrier.... > > > For data operations on regular files it's probably up to filesystems, as > > i_mutex is now. Not sure if IOLOCK would map well on that; can you live with > > that thing taken outside of transaction? > > Yes. IOLOCK has the same scope as i_mutex in the IO path. Umm... So e.g. xfs_create() could take IOLOCK before xfs_trans_reserve()? If so, you probably could eventually be able to use ->i_rwsem for it (and drop it in places where it's already taken by method callers). I'm nowhere near being familiar enough with details of fs/xfs locking to tell how much PITA would the last part be - e.g. a function used both inside ->lookup() and in ->read_iter() and currently taking IOLOCK shared would need to have it lifted into both callers and removed from ->lookup(), etc., which might or might not be painful.