[Top] [All Lists]

Re: [PATCH 12/18] ocfs2: use generic posix ACL infrastructure

To: Jan Kara <jack@xxxxxxx>
Subject: Re: [PATCH 12/18] ocfs2: use generic posix ACL infrastructure
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 3 Dec 2013 02:48:54 -0800
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, viro@xxxxxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-btrfs@xxxxxxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx, linux-mtd@xxxxxxxxxxxxxxxxxxx, Mark Fasheh <mfasheh@xxxxxxxx>, Joel Becker <jlbec@xxxxxxxxxxxx>, reiserfs-devel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, jfs-discussion@xxxxxxxxxxxxxxxxxxxxx, cluster-devel@xxxxxxxxxx, linux-nfs@xxxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131202230007.GK12253@xxxxxxxxxxxxx>
References: <20131201115903.910559036@xxxxxxxxxxxxxxxxxxxxxx> <20131201120655.852590677@xxxxxxxxxxxxxxxxxxxxxx> <20131202230007.GK12253@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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.

<Prev in Thread] Current Thread [Next in Thread>