From: Al Viro <viro@zeniv.linux.org.uk>
To: Helge Deller <deller@kernel.org>
Cc: linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>
Subject: Re: [RFC] [PATCH] Fix warning at fs/dcache.c:430 dentry_free
Date: Mon, 6 Apr 2026 21:28:29 +0100 [thread overview]
Message-ID: <20260406202829.GA3836593@ZenIV> (raw)
In-Reply-To: <20260406200733.GZ3836593@ZenIV>
On Mon, Apr 06, 2026 at 09:07:33PM +0100, Al Viro wrote:
> On Mon, Apr 06, 2026 at 09:52:16PM +0200, Helge Deller wrote:
> > The debian buildd servers for the parisc architecture crash reproduceably when
> > building the webkit2gtk debian package, shortly after having shown the warning
> > below.
> >
> > This patch keeps the lock of the dentry up until when the dentry is given back
> > to the cache and after having freed the "external dentry name".
> >
> > I'm not sure if this patch is really correct, but it seems to have fixed the
> > problem, although more testing is needed.
>
> Hard NAK. You are turning every place that grabs ->d_lock on a dentry scheduled
> for freeing (like, say it, any RCU pathwalk trying to check if the end result can
> be grabbed) into a UAF.
>
> Do you have a better localized reproducer?
BTW, could you reproduce it on viro/vfs.git #work.dcache-busy-wait? It's possible
that changes in there might accidentally fix that, and if they did it would narrow
the things down a lot.
Some invariants that ought to hold:
1) dentry_free() should never be called without DCACHE_DENTRY_KILLED
2) DCACHE_DENTRY_KILLED should never be set on positive dentries
3) DCACHE_DENTRY_KILLED | DCACHE_PAR_LOOKUP is only possible for
dentries that had never been inserted into ->d_in_lookup_hash
4) dentry with DCACHE_DENTRY_KILLED should never become positive
Could you turn that
WARN_ON(!hlist_unhashed(&dentry->d_alias));
in whatever you'd been testing into
if (WARN_ON(!hlist_unhashed(&dentry->d_alias)))
printk(KERN_ERR "->d_inode = %p, ->d_flags = %x",
dentry->d_inode, dentry->d_flags);
and see what it shows? That's a separate from #work.dcache-busy-wait test -
please, do that one on the tree where you'd seen the original bug.
next prev parent reply other threads:[~2026-04-06 20:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-06 19:52 [RFC] [PATCH] Fix warning at fs/dcache.c:430 dentry_free Helge Deller
2026-04-06 20:07 ` Al Viro
2026-04-06 20:21 ` Helge Deller
2026-04-06 20:38 ` Al Viro
2026-04-06 20:28 ` Al Viro [this message]
2026-04-06 20:43 ` Helge Deller
2026-04-06 21:10 ` Al Viro
2026-04-07 16:24 ` Helge Deller
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=20260406202829.GA3836593@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=deller@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@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 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.