From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>,
Jan Kara <jack@suse.cz>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>,
"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [RFC][PATCH] fanotify: allow setting FAN_CREATE in mount mark mask
Date: Wed, 31 Mar 2021 14:54:12 +0200 [thread overview]
Message-ID: <20210331125412.GI30749@quack2.suse.cz> (raw)
In-Reply-To: <CAOQ4uxirud-+ot0kZ=8qaicvjEM5w1scAeoLP_-HzQx+LwihHw@mail.gmail.com>
On Wed 31-03-21 14:29:04, Amir Goldstein wrote:
> On Wed, Mar 31, 2021 at 12:46 PM Christian Brauner
> <christian.brauner@ubuntu.com> wrote:
> >
> > On Tue, Mar 30, 2021 at 05:56:25PM +0300, Amir Goldstein wrote:
> > > > > > My example probably would be something like:
> > > > > >
> > > > > > mount -t ext4 /dev/sdb /A
> > > > > >
> > > > > > 1. FAN_MARK_MOUNT(/A)
> > > > > >
> > > > > > mount --bind /A /B
> > > > > >
> > > > > > 2. FAN_MARK_MOUNT(/B)
> > > > > >
> > > > > > mount -t ecryptfs /B /C
> > > > > >
> > > > > > 3. FAN_MARK_MOUNT(/C)
> > > > > >
> > > > > > let's say I now do
> > > > > >
> > > > > > touch /C/bla
> > > > > >
> > > > > > I may be way off here but intuitively it seems both 1. and 2. should get
> > > > > > a creation event but not 3., right?
> > > > > >
> > > > >
> > > > > Why not 3?
> > > > > You explicitly set a mark on /C requesting to be notified when
> > > > > objects are created via /C.
> > > >
> > > > Sorry, that was a typo. I meant to write, both 2. and 3. should get a
> > > > creation event but not 1.
> > > >
> > > > >
> > > > > > But with your proposal would both 1. and 2. still get a creation event?
> > > > > >
> > > >
> > > > Same obvious typo. The correct question would be: with your proposal do
> > > > 2. and 3. both get an event?
> > > >
> > > > Because it feels like they both should since /C is mounted on top of /B
> > > > and ecryptfs acts as a shim. Both FAN_MARK_MOUNT(/B) and
> > > > FAN_MARK_MOUNT(/C) should get a creation event after all both will have
> > > > mnt->mnt_fsnotify_marks set.
> > > >
> > >
> > > Right.
> > >
> > > There are two ways to address this inconsistency:
> > > 1. Change internal callers of vfs_ helpers to use a private mount,
> > > as you yourself suggested for ecryptfs and cachefiles
> >
> > I feel like this is he correct thing to do independently of the fanotify
> > considerations. I think I'll send an RFC for this today or later this
> > week.
> >
> > > 2. Add fsnotify_path_ hooks at caller site - that would be the
> > > correct thing to do for nfsd IMO
> >
> > I do not have an informed opinion yet on nfsd so I simply need to trust
> > you here. :)
> >
>
> As long as "exp_export: export of idmapped mounts not yet supported.\n"
> I don't think it matters much.
> It feels like adding idmapped mounts to nfsd is on your roadmap.
> When you get to that we can discuss adding fsnotify path hooks to nfsd
> if Jan agrees to the fsnotify path hooks concept.
I was looking at the patch and thinking about it for a few days already. I
think that generating fsnotify event later (higher up the stack where we
have mount information) is fine and a neat idea. I just dislike the hackery
with dentry flags. Also I'm somewhat uneasy that it is random (from
userspace POV) when path event is generated and when not (at least that's
my impression from the patch - maybe I'm wrong). How difficult would it be
to get rid of it? I mean what if we just moved say fsnotify_create() call
wholly up the stack? It would mean more explicit calls to fsnotify_create()
from filesystems - as far as I'm looking nfsd, overlayfs, cachefiles,
ecryptfs. But that would seem to be manageable. Also, to maintain sanity,
we would probably have to lift generation of all directory events like
that. That would be already notable churn but maybe doable... I know you've
been looking at similar things in the past so if you are aware why this
won't fly, please tell me.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2021-03-31 12:55 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-28 15:56 [RFC][PATCH] fanotify: allow setting FAN_CREATE in mount mark mask Amir Goldstein
2021-03-30 7:31 ` Christian Brauner
2021-03-30 9:31 ` Amir Goldstein
2021-03-30 16:24 ` Amir Goldstein
2021-03-31 10:08 ` Christian Brauner
2021-03-31 10:57 ` Amir Goldstein
2021-04-08 11:44 ` open_by_handle_at() in userns Amir Goldstein
2021-04-08 12:55 ` Christian Brauner
2021-04-08 14:15 ` J. Bruce Fields
2021-04-08 15:54 ` Amir Goldstein
2021-04-08 16:08 ` J. Bruce Fields
2021-04-08 16:48 ` Frank Filz
2021-04-08 15:34 ` Amir Goldstein
2021-04-08 15:41 ` Christian Brauner
2021-03-30 12:12 ` [RFC][PATCH] fanotify: allow setting FAN_CREATE in mount mark mask Christian Brauner
2021-03-30 12:33 ` Amir Goldstein
2021-03-30 12:53 ` Christian Brauner
2021-03-30 12:55 ` Christian Brauner
2021-03-30 13:54 ` Amir Goldstein
2021-03-30 14:17 ` Christian Brauner
2021-03-30 14:56 ` Amir Goldstein
2021-03-31 9:46 ` Christian Brauner
2021-03-31 11:29 ` Amir Goldstein
2021-03-31 12:17 ` Christian Brauner
2021-03-31 12:59 ` Amir Goldstein
2021-03-31 12:54 ` Jan Kara [this message]
2021-03-31 14:06 ` Amir Goldstein
2021-03-31 20:59 ` fsnotify path hooks Amir Goldstein
2021-04-01 10:29 ` Jan Kara
2021-04-01 14:18 ` Amir Goldstein
2021-04-02 8:20 ` Amir Goldstein
2021-04-04 10:27 ` LSM and setxattr helpers Amir Goldstein
2021-04-05 12:23 ` Christian Brauner
2021-04-05 14:47 ` Mimi Zohar
2021-04-06 15:43 ` Amir Goldstein
2021-04-05 16:18 ` Casey Schaufler
2021-04-06 8:35 ` fsnotify path hooks Jan Kara
2021-04-06 18:49 ` Amir Goldstein
2021-04-08 12:52 ` Jan Kara
2021-04-08 15:11 ` Amir Goldstein
2021-04-09 10:08 ` Jan Kara
2021-04-09 10:45 ` Christian Brauner
2021-04-20 6:01 ` Amir Goldstein
2021-04-20 11:41 ` Christian Brauner
2021-04-20 11:58 ` Amir Goldstein
2021-04-20 13:38 ` Christian Brauner
2021-04-09 13:22 ` Amir Goldstein
2021-04-09 14:30 ` Al Viro
2021-04-09 14:39 ` Christian Brauner
2021-04-09 14:46 ` Al Viro
2021-04-09 15:20 ` Christian Brauner
2021-04-09 16:06 ` Amir Goldstein
2021-04-09 16:09 ` Amir Goldstein
2021-04-18 18:51 ` Amir Goldstein
2021-04-19 8:08 ` Amir Goldstein
2021-04-19 16:41 ` Amir Goldstein
2021-04-19 17:02 ` Al Viro
2021-04-19 22:04 ` Amir Goldstein
2021-04-20 7:53 ` Amir Goldstein
2021-03-31 13:06 ` [RFC][PATCH] fanotify: allow setting FAN_CREATE in mount mark mask J. Bruce Fields
2021-03-30 12:20 ` 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=20210331125412.GI30749@quack2.suse.cz \
--to=jack@suse.cz \
--cc=amir73il@gmail.com \
--cc=bfields@fieldses.org \
--cc=christian.brauner@ubuntu.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).