From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:58841 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752139AbcAXBlO (ORCPT ); Sat, 23 Jan 2016 20:41:14 -0500 Date: Sun, 24 Jan 2016 01:41:12 +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: <20160124014111.GV17997@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160124005304.GK6033@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Jan 24, 2016 at 11:53:04AM +1100, Dave Chinner wrote: > > readdir() is another potential target for weaker exclusion (i.e. switching > > it to taking that thing shared), but that's a separate story and I'd prefer > > to deal with ->lookup() first. There are potentially hairy issues around > > the instances that pre-seed dcache and I don't want to mix them into the > > initial series. > > So you're doing this for purely to enable lookup concurrency, not > for anyone else to be able to use the inode lock as a read/write > lock? Can anyone use the inode rwsem as a read/write lock for their > own purposes? If so, we can probably use it to replace the XFS > IOLOCK and so effectively remove a layer of locking in various > XFS IO paths. What's the policy you are proposing here? Depends... I definitely want to keep directory modifiers with that thing taken exclusive, with lookup and possibly readdir - shared. Non-directories... it's mostly up to filesystems; the only place where VFS cares is setattr and {set,remove}xattr, and that probably should stay exclusive (or be separated, for that matter, but I hadn't looked into implications of that; we probably can do that, but there might be dragons). 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?