From: Miklos Szeredi <miklos@szeredi.hu>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Murphy Zhou <jencce.kernel@gmail.com>,
overlayfs <linux-unionfs@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] ovl: add RWF_NONITIFY flag to skip wrong duplicate fanotify event
Date: Tue, 23 Apr 2019 15:41:23 +0200 [thread overview]
Message-ID: <CAJfpegvwgJnuuAdaVK-TjQ=6_MBwf8zQNztPLcjOK5GpHbeCEA@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxgk-qkn0YdKP5rEvJvmzhhBUZzjPNqUVe6geXQ+xt9eiw@mail.gmail.com>
On Tue, Apr 23, 2019 at 2:44 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Tue, Apr 23, 2019 at 2:40 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> > On Tue, Apr 23, 2019 at 1:00 PM Amir Goldstein <amir73il@gmail.com> wrote:
> > >
> > > On Tue, Apr 23, 2019 at 9:51 AM Murphy Zhou <jencce.kernel@gmail.com> wrote:
> > > >
> > > > Overlays ovl_iter_write calls vfs_iter_write to write on real file,
> > > > in which calls fsnotify_modify on this change, however vfs_write also
> > > > calls fsnotify_modify after ovl_iter_write. The first notification
> > > > sent by vfs_iter_write grabs marks from upper inode and overlay mnt,
> > > > because of its fake path. The second one sent by vfs_write grabs marks
> > > > from ovl inode and ovl mnt.
> > > >
> > > > LTP fanotify06 add modify mark for mnt point, then add ignore modify
> > > > mask on testfile, then truncate and write the file. Because the ignore
> > > > mask is marked on ovl inode, not the upper inode, the first event is not
> > > > masked like the second one. So we get a modification event even with a
> > > > mask on the file.
> > >
> > > Care to extend fanotify06 in a similar manner to the way readahead02
> > > was extended to test overlay test case regardless of the base LTP filesystem?
> > >
> > > >
> > > > Proposing fixing this by add a new RWF flag to skip fsnotify on this IO.
> > > > vfs_iter_write used by ovl can use this flag to skip one duplicate event.
> > > >
> > >
> > > This fix is wrong for several reasons:
> > > - It exports RWF_NONOTIFY to uapi
> > > - It will cause no events at all when overlay writes to file even when user
> > > requested events on upper inode
> > >
> > > Please try attached patch.
> >
> > Would be nice, but until mmap stops using realfile this isn't a good solution.
> >
>
> Sigh! I figured there was a catch...
> Will it be ok if fake path used a cloned private mount of overlay mount?
So the reason we have the fake path is e.g. /proc/$$/maps. That can
only work with the original mount, AFAICS.
We could have one realfile for regular I/O and a separate one for mmap
but that would increase complexity as well as resource use, so I'm not
quite sure if that's the right solution.
Thanks,
Miklos
next prev parent reply other threads:[~2019-04-23 13:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-23 6:50 [PATCH] ovl: add RWF_NONITIFY flag to skip wrong duplicate fanotify event Murphy Zhou
2019-04-23 10:59 ` Amir Goldstein
2019-04-23 11:39 ` Miklos Szeredi
2019-04-23 12:44 ` Amir Goldstein
2019-04-23 13:41 ` Miklos Szeredi [this message]
2019-04-23 13:53 ` Amir Goldstein
2019-04-23 14:16 ` Miklos Szeredi
2019-04-23 15:05 ` Amir Goldstein
2019-04-23 16:24 ` Amir Goldstein
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='CAJfpegvwgJnuuAdaVK-TjQ=6_MBwf8zQNztPLcjOK5GpHbeCEA@mail.gmail.com' \
--to=miklos@szeredi.hu \
--cc=amir73il@gmail.com \
--cc=jencce.kernel@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
/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).