From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 0996A7F5D for ; Tue, 3 Dec 2013 04:49:12 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id D8B4B8F804C for ; Tue, 3 Dec 2013 02:49:11 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) by cuda.sgi.com with ESMTP id OEyyFww7oTK966zD (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 03 Dec 2013 02:49:11 -0800 (PST) Date: Tue, 3 Dec 2013 02:48:54 -0800 From: Christoph Hellwig Subject: Re: [PATCH 12/18] ocfs2: use generic posix ACL infrastructure Message-ID: <20131203104854.GA3223@infradead.org> References: <20131201115903.910559036@bombadil.infradead.org> <20131201120655.852590677@bombadil.infradead.org> <20131202230007.GK12253@quack.suse.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20131202230007.GK12253@quack.suse.cz> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Jan Kara Cc: cluster-devel@redhat.com, xfs@oss.sgi.com, Mark Fasheh , reiserfs-devel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Christoph Hellwig , linux-mtd@lists.infradead.org, viro@zeniv.linux.org.uk, jfs-discussion@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-nfs@vger.kernel.org, linux-btrfs@vger.kernel.org, Joel Becker On Tue, Dec 03, 2013 at 12:00:07AM +0100, Jan Kara wrote: > Hum, this changes the cluster locking. Previously ocfs2_acl_get() used > from ocfs2_acl_chmod() grabbed cluster wide inode lock. Now getting of ACL > isn't protected by the inode lock. That being said the cluster locking > around setattr looks fishy anyway - if two processes on different > nodes are changing attributes of the same file, changing ACLs post fact > after dropping inode lock could cause interesting effects. Also I'm > wondering how inode_change_ok() can ever be safe without holding inode > lock... Until we grab that other node is free to change e.g. owner of the > inode thus leading even to security implications. But maybe I'm missing > something. Mark, Joel? Hmm, indeed. How does ocfs2_iop_get_acl get away without that lock? Btw, ocfs2 changes will need careful testing as I couldn't find any easy way to run xfstests on ocfs2 out of the box. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs