Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753451AbaBCVUX (ORCPT ); Mon, 3 Feb 2014 16:20:23 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:42364 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753365AbaBCVUT (ORCPT ); Mon, 3 Feb 2014 16:20:19 -0500 Date: Mon, 3 Feb 2014 21:19:55 +0000 From: Al Viro To: Linus Torvalds Cc: Christoph Hellwig , Ilya Dryomov , Sage Weil , Dave Jones , Linux Kernel Mailing List , ceph-devel@vger.kernel.org, linux-fsdevel , Guangliang Zhao , Li Wang , zheng.z.yan@intel.com Subject: Re: [PATCH v2] ceph: fix posix ACL hooks Message-ID: <20140203211955.GY10323@ZenIV.linux.org.uk> References: <1391013467-7598-1-git-send-email-ilya.dryomov@inktank.com> <20140130075421.GA10050@infradead.org> <20140203102943.GF11829@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 03, 2014 at 01:03:32PM -0800, Linus Torvalds wrote: > What do you think? I guess this patch could be split up into two: one > that does the "vfs_xyz()" helper functions, and another that does the > inode_permission() change. I tied them together mainly because I > started with the inode_permission() change, and that required the > vfs_xyz() change. Please, don't do that. Half of that is pointless (e.g. what you are doing with vfs_rmdir() - if anything, we could get rid of the first argument completely, it's always victim->d_parent->d_inode and we are holding enough locks for that to be stable) and ->permission() is just plain wrong. Result *is* a function of inode alone; the problem with 9P is that we are caching FIDs in the wrong place. What really happens is that protocol refers to objects by 32bit tokens, given by server out to client. Many of those can correspond to the same file; think of those as file descriptors. We are associating them with dentries, but if you have several links to the same file a FID acquired for either of them will do. What we ought to do, AFAICS, is moving these guys from dentry to inode; sure, to *get* one in the first place we need some dentry. But by the time ->setxattr() and friends get to see the inode, the caller has already done things that make sure that some FID of his exists. IOW, NAK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/