From: Edvard Conrad <edvard@tuta.io>
To: Amir Goldstein <amir73il@gmail.com>,
Christian Brauner <brauner@kernel.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-unionfs@vger.kernel.org" <linux-unionfs@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
Edvard Conrad <edvard@tuta.io>
Subject: Re: [PATCH v3] fs: let backing files inherit FMODE_NONOTIFY from the user file
Date: Mon, 2 Nov 2026 11:57:34 +0100 (CET) [thread overview]
Message-ID: <P5Qu3co--N-9@tuta.io> (raw)
In-Reply-To: <CAOQ4uxjm=cGPnug18VuhKqiMvkWwLPNLO_TE3KxO8iLZG+veYQ@mail.gmail.com>
On Fri, Oct 30, 2026 at 6:13 PM Amir Goldstein <amir73il@gmail.com> wrote:
> Would you mind adding test cases (or variants) to fanotify26 to cover
> this find and test the attached (sanity tested only) patch.
Two things on the directory side, one settled and one not.
Agreed on 130fdbc3d1f99 ("ovl: pass correct flags for opening real
directory"). Before it ovl_dir_open() passed the user file's f_flags to
ovl_path_open(), and __FMODE_NONOTIFY travelled with them; the commit
reasons through every O_* flag but that one is not an O_* flag. That
fits v6.13 failing the directory case and passing the file case.
The one that is not settled: with your patch, listing a merged
directory through the event fd still deadlocks. ovl_iterate() sends a
directory that has OVL_WHITEOUTS to ovl_iterate_merged(), and
ovl_dir_read() opens each layer with plain ovl_path_open(), which no
user file reaches. A listener that calls getdents64() on the fd before
answering blocks here:
fanotify_handle_event
fsnotify
fsnotify_open_perm_and_set_mode
do_dentry_open
vfs_open
dentry_open
ovl_dir_read_merged
ovl_iterate
iterate_dir
__x64_sys_getdents64
Two controls on the same kernel: the same merged directory without the
listing passes, and a lower-only directory with the listing passes,
since od->realfile is nonotify with your patch and iterate_dir() uses
it directly. That was on 6b4b543fa18 with your patch applied (with some
fuzz); the readdir.c paths involved are the same in today's master. I
have it as an extra case in a local copy of fanotify26 and can post it
once there is a fix to run it against.
Incidentally, I was thinking about your ask for something more
generic: a task-level "creating an event fd" state in fanotify would
cover the file and directory opens in one place, and the copy-up opens
in copy_up.c too, which also go through plain ovl_path_open() and
which an O_RDWR group would trigger for a lower-only file (from
reading, not tested). It would not reach the listing case above, which
runs at getdents() time, long after the fd exists.
Thanks,
Edvard
next prev parent reply other threads:[~2026-11-02 10:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 21:18 Edvard Conrad
2026-10-30 9:26 ` Amir Goldstein
2026-10-30 14:57 ` Christian Brauner
2026-10-30 17:13 ` Amir Goldstein
2026-11-02 10:57 ` Edvard Conrad [this message]
2026-11-02 12:34 ` Amir Goldstein
2026-11-03 13:01 ` Edvard Conrad
2026-11-03 14:46 ` Amir Goldstein
2026-11-03 21:15 ` Edvard Conrad
2026-10-30 14:58 ` Christian Brauner
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=P5Qu3co--N-9@tuta.io \
--to=edvard@tuta.io \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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
all inboxes | Powered by JetHome®