From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934986AbdBQU1x (ORCPT ); Fri, 17 Feb 2017 15:27:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36962 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932655AbdBQU1v (ORCPT ); Fri, 17 Feb 2017 15:27:51 -0500 Date: Fri, 17 Feb 2017 15:27:49 -0500 From: Vivek Goyal To: Al Viro Cc: James Bottomley , Djalal Harouni , Chris Mason , Theodore Tso , Josh Triplett , "Eric W. Biederman" , Andy Lutomirski , Seth Forshee , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Dongsu Park , David Herrmann , Miklos Szeredi , Alban Crequy , "Serge E. Hallyn" , Phil Estes Subject: Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Message-ID: <20170217202749.GA15841@redhat.com> References: <1486235880.2484.17.camel@HansenPartnership.com> <1486235972.2484.19.camel@HansenPartnership.com> <20170217022918.GC29622@ZenIV.linux.org.uk> <1487352280.4351.19.camel@HansenPartnership.com> <20170217175118.GF29622@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170217175118.GF29622@ZenIV.linux.org.uk> User-Agent: Mutt/1.7.1 (2016-10-04) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 17 Feb 2017 20:27:51 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 17, 2017 at 05:51:18PM +0000, Al Viro wrote: > On Fri, Feb 17, 2017 at 09:24:40AM -0800, James Bottomley wrote: > > > > What happens when somebody comes along and creates the damn thing on > > > the underlying fs? _Not_ via your code, that is - using the > > > underlying fs mounted elsewhere. > > > > Point taken. This, I think fixes the dcache revalidation issue. > > No, it doesn't. Consider a local filesystem. Those do not have any > ->d_revalidate() - the kernel bloody well knows what happens to > directories. If e.g. a previously absent file gets created, it's > been done by the kernel itself and dentry has been made positive; if > a previously existing file has been removed, dentry has either become > negative or, if it had been pinned (e.g. file was opened at the time, > or your code had been holding a reference to it, etc.) it will be unhashed > so that new lookups won't find it, etc. No need to revalidate anything. > > Now, consider your code. You've done a lookup in the underlying fs. > It has, at the time, come negative, so you have your (negative) dentry > pointing to that on the underlying fs. If somebody comes and does > e.g. mkdir() via your fs, it will call vfs_mkdir() on the underlying > sucker, hopefully turning it positive and associate a new in-core inode > with your previously negative dentry. But what happens if mkdir is done > via underlying fs, or via another instance of yours over the same tree? > Underlying dentry goes positive; yours is still negative. The underlying > fs either doesn't have ->d_revalidate() or, if there is one it says that > the underlying dentry is valid, thank you very much, no need to invalidate > anything. > > In other words, your patch does nothing for object getting created. I thought assumption here is that underlying subtree is not changed outside of shiftfs. IIUC, overlayfs has the same assumption. Two shiftfs instances writing to same dir will be a problem though. Vivek