Received: by 10.192.165.148 with SMTP id m20csp2190509imm; Thu, 26 Apr 2018 07:14:58 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+PB74Aj87Xm6GoW5Nmxgo5nEjBlEVI7xlIh9X0Ddp/Q4Pn7jjbg27kYVbmZv2ZlsASAG8J X-Received: by 2002:a17:902:a5c2:: with SMTP id t2-v6mr34374555plq.360.1524752098181; Thu, 26 Apr 2018 07:14:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524752098; cv=none; d=google.com; s=arc-20160816; b=HeRjhxUClMI7po0klspXAadIgW5pQk/REitG9wf8vPVtVlkzbFAnEVe48nuipCq4Ju ITWTLtPHLVBZW1fn+et/DdbesdJxEICP6q5YqOzUtYttNpBAl338jHGb9TZIAH/aJWOm YCU2I0cRcVvZ0d7OIfAJAfy8Y+tC4HltHA+HBpll0DwTMjWY9SWrDeQYCz0i10Os+YrS OBqCLzKsXrPMUaFFHT6CkawvrNP9Iq5rsnxg8zHzXIKaWUtR+kdDauwX4xtjddq8+17+ 6yFIt7nKKI3KsAitJi9KuzTDENy244WPb/+z6893nQfFdCuKESWl9gP6dE5JKTiHzR9N q54Q== 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=Uu8aCvPxb8CqGhm2L5tAWurRoY4aorZu60L1x6ggAyg=; b=v5CzFHPnsZdqvjC3u2Wf5Ch48rWwy92nzWQBH6dYiL976nxQ8hCD4xNRht8QvLHTP/ /V3wJy0S4BMZ7psXgk5LOCu/Qbm1PqHmOEy5QVrS1RcvyyFap28mMNTm+g0Ws37ZGFOl XGNyrwLbfzfXhbSeznMJsKNjrNSPFusXeVSb6ZMTZDQhlMCegV0BAi9qV7JwR5KWVzZD d9LPQM30AEOgMac1u2/64o2vX1stJcj7LjAlfcUicCheV4iu85ziR6NhZkLfTXtbx0qh pKxoVuYidQIZrT8MRs8+u03XP+GvESXJlnZjCE2fYu8KmpdxiHPcR3lYAzR4+S29VZT6 kFDA== 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 91-v6si18567570plf.78.2018.04.26.07.14.43; Thu, 26 Apr 2018 07:14:58 -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 S1756495AbeDZONl (ORCPT + 99 others); Thu, 26 Apr 2018 10:13:41 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:53266 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754847AbeDZONh (ORCPT ); Thu, 26 Apr 2018 10:13:37 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 507D4406C742; Thu, 26 Apr 2018 14:13:37 +0000 (UTC) Received: from horse.redhat.com (unknown [10.18.25.159]) by smtp.corp.redhat.com (Postfix) with ESMTP id 43D652026E03; Thu, 26 Apr 2018 14:13:37 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 15557220267; Thu, 26 Apr 2018 10:13:37 -0400 (EDT) Date: Thu, 26 Apr 2018 10:13:37 -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: [RFC PATCH 09/35] ovl: stack file ops Message-ID: <20180426141337.GA4308@redhat.com> References: <20180412150826.20988-1-mszeredi@redhat.com> <20180412150826.20988-10-mszeredi@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180412150826.20988-10-mszeredi@redhat.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Thu, 26 Apr 2018 14:13:37 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Thu, 26 Apr 2018 14:13:37 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.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 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. IOW, I am not able to figure out how do we protect agains copy up races when ovl_open() calls file_dentry(). Thanks Vivek