Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4584295imm; Wed, 30 May 2018 08:13:43 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK3yio0PY/safEMTgR8K+SxWfXT96f2pGB2nv4YDaVzYOIAy15+eoZY3PLBrumClSCgJddB X-Received: by 2002:a62:1152:: with SMTP id z79-v6mr3115419pfi.135.1527693223067; Wed, 30 May 2018 08:13:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527693223; cv=none; d=google.com; s=arc-20160816; b=Rz6vqbL+yQcNMDzrtiHHnamzli4Dbfa991mYOC7lwp0X2XBqrhtTQSax2JlSLLbIfm aQo7WJVbKvBpTKmwdVZhs1TNQvydWV9e9CHgmwkFLpn4Lk5lljai+xP6p9LTE2FcI8xy X9hvHnLoNTB/f2y1TbNv6yBg9HTwpd6cXHbEIgX0nfKmXKfau/HLgFl3yU02vXJrc+qP GgBRZ7WhHxKqE9kbm55A6czlOFcHoyItHUf5vDyserRU/ihZe5KVfuwWytmjTuWWxghA Xr0d3wlGEyr2BGuQkhPNd32MH16QLhu4QsxnR/dliqP6pa7OhFsRYC/rosuTmbH4n9k7 92pQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=uDgpFowcfY0tOKE4xp7wjorkrQ42WCZs1uBe5JRLMgA=; b=xpKG50VZwRQP1Cr6XYtcpN7oD8t4dh91VAeUPj6Bm+iQjPvwEv8fEg3mvGokyNdxDt iIMuywxJdbXL7grO0cX5yQ1CPvLJc0grh8z2ZDSac8onjFQmhgUZvLV/aQwRsoVhzrCm LjaL8DukIVLVMuNXf/DLYWC3xTGVN4NpA3lt02pVEzUTyIzhCN8GWy4vB6sNVmubJ3qI XitD2jk/2XQ6i27yyaTF7go+2l+o0IxQGJJT/p6f6qLXx27p/yg4aFWmQkc2qRhyDb0e /rgJFIGOJQUWcEMVhiFprRD/INIqto7MLe28patrEnDfoAx5zlVjzpNkAL9zB1XOe2O/ AJ8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=bU3jZGz5; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s14-v6si34345074plp.589.2018.05.30.08.13.28; Wed, 30 May 2018 08:13:43 -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; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=bU3jZGz5; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753929AbeE3PM0 (ORCPT + 99 others); Wed, 30 May 2018 11:12:26 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:32955 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753648AbeE3PMS (ORCPT ); Wed, 30 May 2018 11:12:18 -0400 Received: by mail-oi0-f67.google.com with SMTP id k5-v6so16649909oiw.0 for ; Wed, 30 May 2018 08:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uDgpFowcfY0tOKE4xp7wjorkrQ42WCZs1uBe5JRLMgA=; b=bU3jZGz5huuJBLfiejZfWzHkfzyUxRc+zpyNM78rR3JA/+K2bHf9loyYaUfsWg+Tna hdagLVgkePw0pFxceifdc306Jk2VyY23oIqlTB/vGz1nHoYN6pPQAurOPXJNlPimET7j WzrFLX7Q6JmqfxU7AacLnbJeXfP+319rlrip8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uDgpFowcfY0tOKE4xp7wjorkrQ42WCZs1uBe5JRLMgA=; b=BXPtvzJizKCFlDHNFKy/C+2zdEwJYl4eHmiJqSWUyncMJ8rgtyZywGmRQf/8zP+yVW lIHLAtD8wrsgo/IBPm7DcrKKEFURpFaPTcHxUdukWnxZgn4BxV1TJKx7QXBP8yzc8/8G u5nqacMJLBvXpv7KvaRhFuUuvXBkZYP2J/wsYtlatXpLNFOWlnhidADk+z7C0JUXs32B es+l2wJgNLCIc1TfdGLgCQ9SiEdvwVPkgLg1r997gWI6eLHjG0OSjc+orn+mrx8DUZGc o6ZUE1dsRS7kdWk/L2Q4KNyIaZJuoObRqOQEhdJPLgjeVNqBe4MsZp3sPHtwpDwHOLhy xbAg== X-Gm-Message-State: ALKqPweEVXLkkWeLBu/lK/R/oQSdBl4de8vYQ10HJgFWeKh0NYZ7i2CD iJkedPm4H3aA/oJ+yIVai2mj4pWWnq4yeuvxbFjEWQ== X-Received: by 2002:aca:a610:: with SMTP id p16-v6mr1676334oie.149.1527693137415; Wed, 30 May 2018 08:12:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:5303:0:0:0:0:0 with HTTP; Wed, 30 May 2018 08:12:16 -0700 (PDT) X-Originating-IP: [176.63.54.97] In-Reply-To: <20180530143044.GB2717@redhat.com> References: <20180529144612.16675-1-mszeredi@redhat.com> <20180529144612.16675-16-mszeredi@redhat.com> <20180530143044.GB2717@redhat.com> From: Miklos Szeredi Date: Wed, 30 May 2018 17:12:16 +0200 Message-ID: Subject: Re: [PATCH 15/28] ovl: Open file with data except for the case of fsync To: Vivek Goyal Cc: Miklos Szeredi , overlayfs , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 30, 2018 at 4:30 PM, Vivek Goyal wrote: > 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))); That was meant to be + realfile = ovl_open_realfile(file, ovl_inode_realdata(file_inode(file))); Is that correct? > 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. Right. Unfortunately not detected with automatic testing... Thanks for spotting! Miklos