From patchwork Fri Feb 17 20:50:12 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: James Bottomley X-Patchwork-Id: 9580763 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5BD22600C5 for ; Fri, 17 Feb 2017 20:50:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4B8D328779 for ; Fri, 17 Feb 2017 20:50:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 402AC2877B; Fri, 17 Feb 2017 20:50:20 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3108C28779 for ; Fri, 17 Feb 2017 20:50:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934271AbdBQUuQ (ORCPT ); Fri, 17 Feb 2017 15:50:16 -0500 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:47990 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932467AbdBQUuP (ORCPT ); Fri, 17 Feb 2017 15:50:15 -0500 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id DCEF88EE191; Fri, 17 Feb 2017 12:50:13 -0800 (PST) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkvTlq3A9kb4; Fri, 17 Feb 2017 12:50:13 -0800 (PST) Received: from [153.66.254.194] (50-47-107-254.evrt.wa.frontiernet.net [50.47.107.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id DAC508EE023; Fri, 17 Feb 2017 12:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1487364613; bh=J6yf23152q5S9rV7hpXJRvOHp54h1RX0n8+vq5Fum1A=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=I5LArzALNnXVUxx93IjLZVTBNiwqpr02EJnjt+Ub9KBUtYHiZY0jvGzk5vwu6KAgB EKAxiW10dPgMZE+mhvZdea+h8JBUpcOLJiYQQeXyUSTYyRTsdmO95Urdb+KCWQJZ6w g2flC21qiwNZj8i/Fsl6kkm5AE8ZtQrnTzWcXwik= Message-ID: <1487364612.4351.34.camel@HansenPartnership.com> Subject: Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount From: James Bottomley To: Al Viro Cc: 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 Date: Fri, 17 Feb 2017 12:50:12 -0800 In-Reply-To: <20170217175118.GF29622@ZenIV.linux.org.uk> 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> X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, 2017-02-17 at 17:51 +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. Right at the moment, the upper layer doesn't cache negative dentries, but that's only a partial solution. I assume you'd now like me to cache negative dentries (principle of least surprise) and handle the underlying negative to positive transition in d_revalidate? I can do that. James diff --git a/fs/shiftfs.c b/fs/shiftfs.c index a4a1f98..5b50447 100644 --- a/fs/shiftfs.c +++ b/fs/shiftfs.c @@ -118,9 +118,50 @@ static struct dentry *shiftfs_d_real(struct dentry *dentry, return real; } +static int shiftfs_d_weak_revalidate(struct dentry *dentry, unsigned int flags) +{ + struct dentry *real = dentry->d_fsdata; + + if (d_unhashed(real)) + return 0; + + if (!(real->d_flags & DCACHE_OP_WEAK_REVALIDATE)) + return 1; + + return real->d_op->d_weak_revalidate(real, flags); +} + +static int shiftfs_d_revalidate(struct dentry *dentry, unsigned int flags) +{ + struct dentry *real = dentry->d_fsdata; + int ret; + + if (d_unhashed(real)) + return 0; + + /* + * inode state of underlying changed from positive to negative + * or vice versa; force a lookup to update our view + */ + if (d_is_negative(real) != d_is_negative(dentry)) + return 0; + + if (!(real->d_flags & DCACHE_OP_REVALIDATE)) + return 1; + + ret = real->d_op->d_revalidate(real, flags); + + if (ret == 0 && !(flags & LOOKUP_RCU)) + d_invalidate(real); + + return ret; +} + static const struct dentry_operations shiftfs_dentry_ops = { .d_release = shiftfs_d_release, .d_real = shiftfs_d_real, + .d_revalidate = shiftfs_d_revalidate, + .d_weak_revalidate = shiftfs_d_weak_revalidate, }; static int shiftfs_readlink(struct dentry *dentry, char __user *data, @@ -423,7 +464,7 @@ static struct dentry *shiftfs_lookup(struct inode *dir, struct dentry *dentry, dentry->d_fsdata = new; if (!new->d_inode) - return NULL; + goto out; newi = shiftfs_new_inode(dentry->d_sb, new->d_inode->i_mode, new); if (!newi) { @@ -431,9 +472,8 @@ static struct dentry *shiftfs_lookup(struct inode *dir, struct dentry *dentry, return ERR_PTR(-ENOMEM); } - d_splice_alias(newi, dentry); - - return NULL; + out: + return d_splice_alias(newi, dentry); } static int shiftfs_permission(struct inode *inode, int mask)