Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4542683imm; Wed, 30 May 2018 07:32:09 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJtnfciEcHXdGwHNWuzhTsULR56Kp+nDkJu9PwvbgeV7XVvOxkz0YIgHk+CqzB20Ngf+Dgb X-Received: by 2002:a65:4d08:: with SMTP id i8-v6mr2443520pgt.427.1527690729289; Wed, 30 May 2018 07:32:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527690729; cv=none; d=google.com; s=arc-20160816; b=VGLqR6oVwl53pWgNYuBcmbqtdezVrQ83k6EL6Xtr2qHXXVZhmTwt9YSmV3toWCdyUD B3LK727ySzeV+2PAJ4MI+gETKzKR/eqw09xLBrYffJhgf9EJRuPtzSGEWptlePCOqrtU 4wR616qWjyUK/74NPkFigevRE7aFTPu+aYH7UzsqoyqJ9VRGsFG/v+eDYjDM3BFZ2RFS eGs+l8rIOrlo2qzFDGaCcDpBbZVvxJzLh5BFWYpg4r8iXOZPQtwXUnEHhLs/I9jFQY/d ncQtRw2FdvKdoX9EmgYwez1Gax4H4ct8HPnEyP4u3GCGcVSCpu/7Ri5onx0s99oCUxx0 pJ+w== 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=Tk7sBNFAQ3PrFK4J2iklAEWNk8Ae++Dosze3z14jHHM=; b=MOUzky/28ebu0BkMupM0MLnqTMksK0z5hYqSuU2v5JtyL7GjlrCllgbnD0U8mL7Jsz SbYs1MU7GvxmkSMZf38jrd1Mt/GgPMCihK2iT4Urk+DzfaWKSIXS/w9GBUhec47gsxST 6ggRk1gYwpFaNXNFCOLVPNsSNhDUaJlya5g8qXHZ3nF8XD4IH+LAfJqDSTRV0LgRcwJc ydBYw4KKDIT2ULeHFdITVu5jPy28riB5ne0OzrtrarXImdl1QWwDQmrXQqvMSG+mBucz dnI6CJWPIvTnZw8WaOLCjz4KN6q2mzQbdgWJdfqXqm7f25aqgJwodN32cPCjytqzUSk3 U5yw== 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 d18-v6si35468347plr.265.2018.05.30.07.31.49; Wed, 30 May 2018 07:32:09 -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 S1753534AbeE3Oaz (ORCPT + 99 others); Wed, 30 May 2018 10:30:55 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:44180 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751474AbeE3Oap (ORCPT ); Wed, 30 May 2018 10:30:45 -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 A2B34401EF11; Wed, 30 May 2018 14:30:44 +0000 (UTC) Received: from horse.redhat.com (unknown [10.18.25.159]) by smtp.corp.redhat.com (Postfix) with ESMTP id 85676208C6C1; Wed, 30 May 2018 14:30:44 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 233C82239B4; Wed, 30 May 2018 10:30:44 -0400 (EDT) Date: Wed, 30 May 2018 10:30:44 -0400 From: Vivek Goyal To: Miklos Szeredi Cc: linux-unionfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 15/28] ovl: Open file with data except for the case of fsync Message-ID: <20180530143044.GB2717@redhat.com> References: <20180529144612.16675-1-mszeredi@redhat.com> <20180529144612.16675-16-mszeredi@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180529144612.16675-16-mszeredi@redhat.com> 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.5]); Wed, 30 May 2018 14:30:44 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 30 May 2018 14:30:44 +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 Tue, May 29, 2018 at 04:45:59PM +0200, Miklos Szeredi wrote: > From: Vivek Goyal > > ovl_open() should open file which contains data and not open metacopy > inode. With the introduction of metacopy inodes, with current > implementaion we will end up opening metacopy inode as well. > > But there can be certain circumstances like ovl_fsync() where we want to > allow opening a metacopy inode instead. > > Hence, change ovl_open_realfile() and add _ovl_open_real() and add extra > parameter which specifies whether to allow opening metacopy inode or not. > If this parameter is false, we look for data inode and open that. > > This should allow covering both the cases. > > Signed-off-by: Vivek Goyal > Reviewed-by: Amir Goldstein > Signed-off-by: Miklos Szeredi > --- > fs/overlayfs/file.c | 39 ++++++++++++++++++++++++++++++--------- > 1 file changed, 30 insertions(+), 9 deletions(-) > > diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c > index 266692ce9a9a..c7738ef492c8 100644 > --- a/fs/overlayfs/file.c > +++ b/fs/overlayfs/file.c > @@ -14,11 +14,20 @@ > #include > #include "overlayfs.h" > > -static struct file *ovl_open_realfile(const struct file *file) > +static char ovl_whatisit(struct inode *inode, struct inode *realinode) > +{ > + if (realinode != ovl_inode_upper(inode)) > + return 'l'; > + if (ovl_has_upperdata(inode)) > + return 'u'; > + else > + return 'm'; > +} > + > +static struct file *ovl_open_realfile(const struct file *file, > + struct inode *realinode) > { > 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; > > @@ -28,7 +37,7 @@ static struct file *ovl_open_realfile(const struct file *file) > revert_creds(old_cred); > > pr_debug("open(%p[%pD2/%c], 0%o) -> (%p, 0%o)\n", > - file, file, upperinode ? 'u' : 'l', file->f_flags, > + file, file, ovl_whatisit(inode, realinode), file->f_flags, > realfile, IS_ERR(realfile) ? 0 : realfile->f_flags); > > return realfile; > @@ -72,17 +81,24 @@ static int ovl_change_flags(struct file *file, unsigned int flags) > return 0; > } > > -static int ovl_real_fdget(const struct file *file, struct fd *real) > +static int ovl_real_fdget_meta(const struct file *file, struct fd *real, > + bool allow_meta) > { > struct inode *inode = file_inode(file); > + struct inode *realinode; > > real->flags = 0; > real->file = file->private_data; > > + if (allow_meta) > + realinode = ovl_inode_real(inode); > + else > + realinode = ovl_inode_realdata(inode); > + > /* Has it been copied up since we'd opened it? */ > - if (unlikely(file_inode(real->file) != ovl_inode_real(inode))) { > + if (unlikely(file_inode(real->file) != realinode)) { > real->flags = FDPUT_FPUT; > - real->file = ovl_open_realfile(file); > + real->file = ovl_open_realfile(file, realinode); > > return PTR_ERR_OR_ZERO(real->file); > } > @@ -94,6 +110,11 @@ static int ovl_real_fdget(const struct file *file, struct fd *real) > return 0; > } > > +static int ovl_real_fdget(const struct file *file, struct fd *real) > +{ > + return ovl_real_fdget_meta(file, real, false); > +} > + > static int ovl_open(struct inode *inode, struct file *file) > { > struct dentry *dentry = file_dentry(file); > @@ -107,7 +128,7 @@ static int ovl_open(struct inode *inode, struct file *file) > /* No longer need these flags, so don't pass them on to underlying fs */ > file->f_flags &= ~(O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC); > > - realfile = ovl_open_realfile(file); > + realfile = ovl_open_realfile(file, ovl_inode_real(file_inode(file))); Hi Miklos, Hmm...so there have been some changes in this patch. My original intention was that to always open data inode (lower/upper) in ovl_open(). So if upper inode is a metacopy only, I will open lower inode instead. But new logic seems to be to always open real inode (that means upper metacopy inode as well). And that means that later when read happens on the file we will end up opening lower file, read data and close lower file. I am concerned a bit if there are performance implications to this. This will be hot path for containers. Thanks Vivek