Received: by 10.192.165.148 with SMTP id m20csp2240789imm; Thu, 26 Apr 2018 07:59:51 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+jhmWa6x2Cgpv4+u5k+JLvJg8QpEbs1gaFxSjErBMGxonZ8BDsU8sEJlmy6SKjEcoicaJ+ X-Received: by 2002:a17:902:30a3:: with SMTP id v32-v6mr34599943plb.123.1524754790945; Thu, 26 Apr 2018 07:59:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524754790; cv=none; d=google.com; s=arc-20160816; b=Ps+V4ToThUUaxv7N3IGxfqurJMrGcXMa/1bABfVkgoV1Ci8K0KSzBkA7ZYxbfAQwU1 dVTUhRKx9Df+KV99gMerNgFsVua/1DxSe8Wp+v58Tv/UZSS/nt7XBY5bzdFFy54xOQxE 6TWv7RlLnNLgQCzB8brQBDHENU3VKib0yrj50ji0g6kOCsvfKmuxsPRIzh1vD90TmX1l 3189nYznouplcxUiPk/6nan55mJROIcDRACEMoE7dqgT9Daslg19B8jLF1sfLO+5oD5q mbjdrHd6RSRl15pQd1Eonw+YFbfA/+r+ncjFKuH9cUFNpEk9aYjiSMfKr9gVjQwp9aEf BtbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=DWM9xa7nsiiR0bdlB0P425Q+eRgi0G0OAlD6wN67qe0=; b=DqipThSsUyp3OQxhuCoftMKUeivzh5oc0Y71gBruHXQ6vyp/BeYqR8Le2lBqDtb5O6 f5qmWAGqfGmWIHuleClsmsnRXSx4yhGptRWeEEGdY+YrTlhJaotUa0WgKgRZ7f875C2M 5ObcOKGqvdeKj4AbAu+KHUPYf8vSW0BH6IMkfZzsmQSdS8x2iP2cPq2t0zkJXi3IoUXl p3RI9ZKn6ZaRktBfSjv/b0+fjw7myJUtdvASwoPk/PXKxxHuM9N4zDHxa57OCRSzJPUr VqCt9RQtSBMBZ1VgYi1js6LfNhgIssJanYOXBeytwUtNKGUiRrVAXWVdYZaSLNnHfmoO TVpw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t1-v6si20820171plb.90.2018.04.26.07.59.36; Thu, 26 Apr 2018 07:59:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756662AbeDZO4s (ORCPT + 99 others); Thu, 26 Apr 2018 10:56:48 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:59264 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756664AbeDZO4m (ORCPT ); Thu, 26 Apr 2018 10:56:42 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DEA8C401DEAB; Thu, 26 Apr 2018 14:56:41 +0000 (UTC) Received: from horse.redhat.com (unknown [10.18.25.159]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8B4CB215CDC8; Thu, 26 Apr 2018 14:56:41 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 5343C220267; Thu, 26 Apr 2018 10:56:41 -0400 (EDT) Date: Thu, 26 Apr 2018 10:56:41 -0400 From: Vivek Goyal To: Miklos Szeredi Cc: Miklos Szeredi , overlayfs , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 09/35] ovl: stack file ops Message-ID: <20180426145641.GB4308@redhat.com> References: <20180412150826.20988-1-mszeredi@redhat.com> <20180412150826.20988-10-mszeredi@redhat.com> <20180426141337.GA4308@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 26 Apr 2018 14:56:41 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 26 Apr 2018 14:56:41 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'vgoyal@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 26, 2018 at 04:43:53PM +0200, Miklos Szeredi wrote: > On Thu, Apr 26, 2018 at 4:13 PM, Vivek Goyal wrote: > > On Thu, Apr 12, 2018 at 05:08:00PM +0200, Miklos Szeredi wrote: > > > > [..] > >> diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c > >> new file mode 100644 > >> index 000000000000..a0b606885c41 > >> --- /dev/null > >> +++ b/fs/overlayfs/file.c > >> @@ -0,0 +1,76 @@ > >> +/* > >> + * Copyright (C) 2017 Red Hat, Inc. > >> + * > >> + * This program is free software; you can redistribute it and/or modify it > >> + * under the terms of the GNU General Public License version 2 as published by > >> + * the Free Software Foundation. > >> + */ > >> + > >> +#include > >> +#include > >> +#include > >> +#include "overlayfs.h" > >> + > >> +static struct file *ovl_open_realfile(const struct file *file) > >> +{ > >> + struct inode *inode = file_inode(file); > >> + struct inode *upperinode = ovl_inode_upper(inode); > >> + struct inode *realinode = upperinode ?: ovl_inode_lower(inode); > >> + struct file *realfile; > >> + const struct cred *old_cred; > >> + > >> + old_cred = ovl_override_creds(inode->i_sb); > >> + realfile = path_open(&file->f_path, file->f_flags | O_NOATIME, > >> + realinode, current_cred(), false); > >> + revert_creds(old_cred); > >> + > >> + pr_debug("open(%p[%pD2/%c], 0%o) -> (%p, 0%o)\n", > >> + file, file, upperinode ? 'u' : 'l', file->f_flags, > >> + realfile, IS_ERR(realfile) ? 0 : realfile->f_flags); > >> + > >> + return realfile; > >> +} > >> + > >> +static int ovl_open(struct inode *inode, struct file *file) > >> +{ > >> + struct dentry *dentry = file_dentry(file); > > > > Hi Miklos, > > > > There is one thing I can't wrap my head around, so I better ask. > > > > file_dentry() will call ovl_d_real() and try to find dentry based on > > inode installed in f->f_inode. If ovl_d_real() can't find inode dentry > > matching the passed in inode, it warns. > > > > Assume, I have a stacked overlay configuration. Let me call top level > > overlay layer ovl1 and lower level overlay layer ovl2. Say I open a > > file foo.txt. Now ovl_open() in ovl1 decides that realinode is a lower > > inode and installs that inode f->f_inode of realfile. (This should be > > ovl2 layer inode, let me call it ovl2_inode). Now ovl_open() of ovl2 layer > > will be called and it will call file_dentry() and will look for dentry > > corresponding to ovl2_inode. I am wondering what if a copy up of foo.txt > > was triggered in ovl1 and by the time we called ovl_d_real(dentry, > > ovl2_inode), it will start comparing with inode of ovl1_upper and never > > find ovl2_inode. > > Okay, so we've modified ovl_d_real() to allow returning the overlay > dentry itself. This is important: when we fail to match ovl1_upper > with ovl2_inode, well go on to get ovl2_dentry and call d_real() > recursively. That recursive call should match the inode, return it to > outer ovl_d_real(), which again will match the inode and return > without warning. So current code does following. ovl_d_real() { ... ... real = ovl_dentry_real(dentry); if (inode == d_inode(real)) return real; /* Handle recursion */ if (unlikely(real->d_flags & DCACHE_OP_REAL)) return real->d_op->d_real(real, inode); } If file got copied up in ovl1, then "real" will be ovl1_upper dentry. And upper is regular fs (only ovl1 lower is overlay), then it should not have DCACHE_OP_REAL set and that means we will not recurse further and not find ovl2 dentry matching ovl2_inode and print warning and return ovl1 dentry. What am I missing. Vivek > > > IOW, I am not able to figure out how do we protect agains copy up races > > when ovl_open() calls file_dentry(). > > Racing with a copy up cannot matter, since we'll continue looking for > the inode in the layers and stacks below, regardless of whether we > checked the upper dentry or not. > > Does that make it clearer? > > Thanks, > Miklos