From: Al Viro <viro@zeniv.linux.org.uk>
To: NeilBrown <neil@brown.name>
Cc: Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 5/8] Introduce S_DYING which warns that S_DEAD might follow.
Date: Wed, 11 Jun 2025 02:13:07 +0100 [thread overview]
Message-ID: <20250611011307.GI299672@ZenIV> (raw)
In-Reply-To: <174960360675.608730.17207039742680720579@noble.neil.brown.name>
On Wed, Jun 11, 2025 at 11:00:06AM +1000, NeilBrown wrote:
> Yes.
>
> >
> > Where does your dentry lock nest wrt ->i_rwsem? As a bonus (well, malus, I guess)
> > question, where does it nest wrt parent *and* child inodes' ->i_rwsem for rmdir
> > and rename?
>
> Between inode of parent of the dentry and inode of the dentry.
That's... going to be fun to prove the deadlock avoidance.
Looking forward to such proof...
Look, the reason why I'm sceptical is that we had quite a few interesting
problems with directory locking schemes; fun scenarios are easy to
miss and I've fucked up more than a few times in that area. Fixing it
afterwards can be a real bitch, especially if we get filesystem-specific
parts in the picture.
So let's sort it out _before_ we go there. And I mean proof - verifiable
statements about the functions, etc.
Incidentally, what was the problem with having dentry locked before
the parent? At least that way we would have a reasonable lock ordering...
It would require some preliminary work, but last time I looked at the
area (not very deeply) it felt like a plausible direction... I wonder
which obstacle have I missed...
next prev parent reply other threads:[~2025-06-11 1:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 7:34 [PATCH 0/8 preview] demonstrate proposed new locking strategy for directories NeilBrown
2025-06-09 7:34 ` [PATCH 1/8] VFS: use global wait-queue table for d_alloc_parallel() NeilBrown
2025-06-09 7:34 ` [PATCH 2/8] VFS: use d_alloc_parallel() in lookup_one_qstr_excl() NeilBrown
2025-06-09 7:34 ` [PATCH 3/8] fs/proc: take rcu_read_lock() in proc_sys_compare() NeilBrown
2025-06-09 7:34 ` [PATCH 4/8] VFS: Add ability to exclusively lock a dentry and use for open/create NeilBrown
2025-06-09 7:34 ` [PATCH 5/8] Introduce S_DYING which warns that S_DEAD might follow NeilBrown
2025-06-10 20:57 ` Al Viro
2025-06-11 1:00 ` NeilBrown
2025-06-11 1:13 ` Al Viro [this message]
2025-06-11 2:49 ` NeilBrown
2025-06-09 7:34 ` [PATCH 6/8] VFS: provide alternative to s_vfs_rename_mutex NeilBrown
2025-06-09 7:34 ` [PATCH 7/8] VFS: use new dentry locking for create/remove/rename NeilBrown
2025-06-10 20:36 ` Al Viro
2025-06-11 0:34 ` NeilBrown
2025-06-09 7:34 ` [PATCH 8/8] VFS: allow a filesystem to opt out of directory locking 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=20250611011307.GI299672@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 \
/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.