linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
	overlayfs <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
Date: Thu, 26 Apr 2018 11:13:05 -0400	[thread overview]
Message-ID: <20180426151305.GC4308@redhat.com> (raw)
In-Reply-To: <CAJfpeguCtZ+3q6Fr7bu1Q5B3JXFQfS2Y9XJHgr0-OR9g=J9JsA@mail.gmail.com>

On Thu, Apr 26, 2018 at 05:01:37PM +0200, Miklos Szeredi wrote:
> On Thu, Apr 26, 2018 at 4:56 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Thu, Apr 26, 2018 at 04:43:53PM +0200, Miklos Szeredi wrote:
> >> On Thu, Apr 26, 2018 at 4:13 PM, Vivek Goyal <vgoyal@redhat.com> 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 <linux/cred.h>
> >> >> +#include <linux/file.h>
> >> >> +#include <linux/xattr.h>
> >> >> +#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.
> 
> Ah,  that's indeed buggy.  The bug is in "[RFC PATCH 34/35] vfs:
> simplify d_op->d_real()".
> 
> I've already reverted that (due to d_real_inode() acquiring a new
> user) and the old code should be good (AFAICS).

Aha, cool. thanks. While I am at it, let me just ask one more stupid
question.

I am wondering while opening the underlying realfile, why do we pass
in the path/dentry of ovl layer (and not underlying real layer).

        realfile = path_open(&file->f_path, file->f_flags | O_NOATIME,
                             realinode, current_cred(), false);

This forces us to do file_dentry() in ovl_open() later to map top level
dentry to underlying dentry.

We know the realinode and should be figure out real dentry. Can't we
construct path from underlying dentry and mount point and use that
to open underlying real file.  I am sure there is some reason for doing
this way, just trying to understand it.

Vivek

  reply	other threads:[~2018-04-26 15:13 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12 15:07 [RFC PATCH 00/35] overlayfs: stack file operations Miklos Szeredi
2018-04-12 15:07 ` [RFC PATCH 01/35] vfs: clean up dedup Miklos Szeredi
2018-04-12 16:25   ` Matthew Wilcox
2018-04-12 17:24     ` Miklos Szeredi
2018-04-12 15:07 ` [RFC PATCH 02/35] vfs: add path_open() Miklos Szeredi
2018-04-12 16:38   ` Matthew Wilcox
2018-04-12 15:07 ` [RFC PATCH 03/35] vfs: optionally don't account file in nr_files Miklos Szeredi
2018-04-12 15:07 ` [RFC PATCH 04/35] ovl: copy up times Miklos Szeredi
2018-04-13  8:25   ` Amir Goldstein
2018-04-13 14:23   ` Vivek Goyal
2018-04-12 15:07 ` [RFC PATCH 05/35] ovl: copy up inode flags Miklos Szeredi
2018-04-12 15:07 ` [RFC PATCH 06/35] Revert "Revert "ovl: get_write_access() in truncate"" Miklos Szeredi
2018-04-12 15:07 ` [RFC PATCH 07/35] ovl: copy up file size as well Miklos Szeredi
2018-04-24 18:10   ` Vivek Goyal
2018-04-12 15:07 ` [RFC PATCH 08/35] ovl: deal with overlay files in ovl_d_real() Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 09/35] ovl: stack file ops Miklos Szeredi
2018-04-26 14:13   ` Vivek Goyal
2018-04-26 14:43     ` Miklos Szeredi
2018-04-26 14:56       ` Vivek Goyal
2018-04-26 15:01         ` Miklos Szeredi
2018-04-26 15:13           ` Vivek Goyal [this message]
2018-04-26 15:21             ` Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 10/35] ovl: add helper to return real file Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 11/35] ovl: readd read_iter Miklos Szeredi
2018-04-13 13:35   ` Amir Goldstein
2018-04-12 15:08 ` [RFC PATCH 12/35] ovl: readd write_iter Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 13/35] ovl: readd fsync Miklos Szeredi
2018-04-23 13:36   ` Vivek Goyal
2018-04-23 13:39     ` Miklos Szeredi
2018-04-23 13:53       ` Vivek Goyal
2018-04-23 14:09         ` Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 14/35] ovl: readd mmap Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 15/35] ovl: readd fallocate Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 16/35] ovl: readd lsattr/chattr support Miklos Szeredi
2018-04-13 14:48   ` Amir Goldstein
2018-04-17 19:51   ` Amir Goldstein
2018-04-22  8:35     ` Amir Goldstein
2018-04-22 15:18       ` Amir Goldstein
2018-04-23 10:21       ` Miklos Szeredi
2018-04-23 10:28         ` Miklos Szeredi
2018-04-23  6:11   ` Ritesh Harjani
2018-04-12 15:08 ` [RFC PATCH 17/35] ovl: readd fiemap Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 18/35] ovl: readd O_DIRECT support Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 19/35] ovl: readd reflink/copyfile/dedup support Miklos Szeredi
2018-04-17 20:31   ` Amir Goldstein
2018-04-18  8:39     ` Amir Goldstein
2018-05-03 16:04     ` Miklos Szeredi
2018-05-03 19:48       ` Amir Goldstein
2018-04-12 15:08 ` [RFC PATCH 20/35] vfs: don't open real Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 21/35] vfs: add f_op->pre_mmap() Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 22/35] ovl: copy-up on MAP_SHARED Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 23/35] vfs: simplify dentry_open() Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 24/35] Revert "ovl: fix relatime for directories" Miklos Szeredi
2018-04-13 14:02   ` Amir Goldstein
2018-04-13 15:55   ` Vivek Goyal
2018-04-12 15:08 ` [RFC PATCH 25/35] Revert "vfs: update ovl inode before relatime check" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 26/35] Revert "ovl: fix may_write_real() for overlayfs directories" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 27/35] Revert "ovl: don't allow writing ioctl on lower layer" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 28/35] Revert "vfs: add flags to d_real()" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 29/35] Revert "vfs: do get_write_access() on upper layer of overlayfs" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 30/35] Revert "vfs: make argument of d_real_inode() const" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 31/35] Revert "vfs: add d_real_inode() helper" Miklos Szeredi
2018-04-18  8:19   ` Amir Goldstein
2018-04-18 11:42     ` Miklos Szeredi
2018-04-18 13:38       ` Steven Rostedt
2018-04-18 13:49         ` Miklos Szeredi
2018-04-18 13:56           ` Steven Rostedt
2018-04-19 19:54           ` Vivek Goyal
2018-04-20  9:14             ` Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 32/35] Partially revert "locks: fix file locking on overlayfs" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 33/35] Revert "fsnotify: support overlayfs" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 34/35] vfs: simplify d_op->d_real() Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 35/35] ovl: fix documentation of non-standard behavior Miklos Szeredi
2018-04-13 11:23   ` Amir Goldstein
2018-04-25 14:49 ` [RFC PATCH 00/35] overlayfs: stack file operations J. R. Okajima
2018-04-25 19:44   ` Miklos Szeredi
2018-05-04 15:23 ` Miklos Szeredi
2018-05-05 16:37   ` Amir Goldstein
2018-05-08 14:25     ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180426151305.GC4308@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mszeredi@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).