From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>,
NeilBrown <neil@brown.name>
Subject: Re: [RFC] a possible way of reducing the PITA of ->d_name audits
Date: Mon, 8 Sep 2025 01:06:17 +0100 [thread overview]
Message-ID: <20250908000617.GF31600@ZenIV> (raw)
In-Reply-To: <CAHk-=wif3NXNMmTERKnmDjDBSbY3qdFgd5ScWTwZaZg0NFACUw@mail.gmail.com>
On Sun, Sep 07, 2025 at 02:51:18PM -0700, Linus Torvalds wrote:
> On Sun, 7 Sept 2025 at 13:32, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > I would like to discuss a flagday change to calling conventions
> > of ->create()/->unlink()/->rename()/etc. - all directory methods.
> > It would have no impact on the code generation, it would involve
> > quite a bit of localized churn and it would allow to deal with catching
> > ->d_name races on compiler level.
>
> Can you make this more concrete by actually sending an example patch.
>
> Well, two patches: first the patch for the "claim_stability" helper
> type and functions, and then a separate patch for converting _one_ of
> the users (eg 'symlink').
>
> Because I have a hard time visualizing just how noisy the result would
> be (and whether it would be legible end result).
Will do... BTW, for a non-obvious example of the things that show up
in process: ceph_wait_on_conflict_unlink() is actually guaranteed that
its argument is stable. The way it copies ->d_name locally (with
a good reason - there's a loop using that for comparisons, so it's
a valid optimization) would otherwise be seriously racy.
> And I do wonder if it might not be simpler to have a model where
> filesystems always get a stable dentry name - either because we hold
> the parent lock on a VFS level (fairly common, I think), or because we
> pass a separate copy to the filesystem
>
> You did that with the d_revalidate() callback, and I think that was a
> clear success. Can we extend on *that* pattern, perhaps?
Umm... For one thing, there's something wrong with passing two arguments
that always differ by constant offset (and type, of course)... More
serious reason is that in quite a few cases we want both dentry and stable
name accessible for a helper called from those (ceph_wait_on_conflict_unlink(),
for example). And for those we either have to pass both dentry and const
struct qstr * or we still have to trace their call chains every time we
do that audit. Passing struct stable_dentry instead avoids that...
next prev parent reply other threads:[~2025-09-08 0:06 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-07 20:32 [RFC] a possible way of reducing the PITA of ->d_name audits Al Viro
2025-09-07 21:51 ` Linus Torvalds
2025-09-08 0:06 ` Al Viro [this message]
2025-09-08 0:47 ` Linus Torvalds
2025-09-08 2:51 ` Al Viro
2025-09-08 3:57 ` Al Viro
2025-09-08 4:50 ` NeilBrown
2025-09-08 5:19 ` Al Viro
2025-09-08 6:25 ` NeilBrown
2025-09-08 9:05 ` Al Viro
2025-09-10 2:45 ` NeilBrown
2025-09-10 7:24 ` Al Viro
2025-09-10 22:52 ` NeilBrown
2025-09-12 5:49 ` ->atomic_open() fun (was Re: [RFC] a possible way of reducing the PITA of ->d_name audits) Al Viro
2025-09-12 8:23 ` Miklos Szeredi
2025-09-12 18:29 ` Al Viro
2025-09-12 19:22 ` Miklos Szeredi
2025-09-12 20:36 ` Al Viro
2025-09-12 20:50 ` Al Viro
2025-09-13 3:36 ` NeilBrown
2025-09-13 5:07 ` Al Viro
2025-09-13 5:50 ` NeilBrown
2025-09-14 19:01 ` Miklos Szeredi
2025-09-14 19:50 ` Al Viro
2025-09-14 20:05 ` Miklos Szeredi
2025-09-15 8:54 ` Bernd Schubert
2025-09-12 18:55 ` Al Viro
2025-09-12 18:59 ` [PATCH 1/9] allow finish_no_open(file, ERR_PTR(-E...)) Al Viro
2025-09-12 18:59 ` [PATCH 2/9] 9p: simplify v9fs_vfs_atomic_open() Al Viro
2025-09-12 18:59 ` [PATCH 3/9] 9p: simplify v9fs_vfs_atomic_open_dotl() Al Viro
2025-09-12 18:59 ` [PATCH 4/9] simplify cifs_atomic_open() Al Viro
2025-09-12 18:59 ` [PATCH 5/9] simplify vboxsf_dir_atomic_open() Al Viro
2025-09-12 18:59 ` [PATCH 6/9] simplify nfs_atomic_open_v23() Al Viro
2025-09-12 18:59 ` [PATCH 7/9] simplify fuse_atomic_open() Al Viro
2025-09-12 18:59 ` [PATCH 8/9] simplify gfs2_atomic_open() Al Viro
2025-09-12 18:59 ` [PATCH 9/9] slightly simplify nfs_atomic_open() Al Viro
2025-09-12 22:23 ` [PATCH 1/9] allow finish_no_open(file, ERR_PTR(-E...)) Linus Torvalds
2025-09-13 3:34 ` NeilBrown
2025-09-13 21:28 ` [RFC] a possible way of reducing the PITA of ->d_name audits Al Viro
2025-09-14 1:05 ` NeilBrown
2025-09-14 1:37 ` Al Viro
2025-09-14 5:56 ` Al Viro
2025-09-14 23:07 ` NeilBrown
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=20250908000617.GF31600@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=neil@brown.name \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.