From: sashiko-bot@kernel.org
To: "Christian Brauner" <brauner@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH 1/9] binfmt_misc: let a register string create an entry disabled
Date: Thu, 30 Jul 2026 13:47:57 +0000 [thread overview]
Message-ID: <20260730134757.A21231F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260730-work-binfmt_misc-preopen-v1-1-4a0b0da71f16@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Inconsistent VFS lockdep subclass usage for the root directory's i_rwsem in bm_entry_write().
--
--- Patch [1]: [PATCH 1/9] binfmt_misc: let a register string create an entry disabled ---
commit 804ba816d20f57c8b2fa3e1866d3a8ae54eeeb11
Author: Christian Brauner <brauner@kernel.org>
binfmt_misc: let a register string create an entry disabled
This commit adds a 'D' flag to binfmt_misc registration, allowing entries to
be created in a disabled state and activated later. This separates creation
from activation and keeps staged entries out of the search list until enabled.
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index 707f8a14f8a63..ca7840b01a2bb 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
[ ... ]
> @@ -1067,9 +1110,27 @@ static ssize_t bm_entry_write(struct file *file, const char __user *buffer,
> case BM_CMD_DISABLE:
> clear_bit(MISC_FMT_ENABLED_BIT, &e->flags);
> break;
> - case BM_CMD_ENABLE:
> + case BM_CMD_ENABLE: {
> + struct inode *root = bm_root_inode(inode->i_sb);
> +
> + /*
> + * The first enable publishes a 'D' entry into the search
> + * list, whole. The lock keeps that ordered against a second
> + * enable and against removal; a removed entry has nothing
> + * left to publish.
> + */
> + inode_lock(root);
[Severity: Medium]
In bm_remove_entry() and bm_remove_all_entries(), the root directory lock is
acquired using inode_lock_nested(root, I_MUTEX_PARENT). Here in
bm_entry_write(), we're using inode_lock(root) which uses the default subclass
(I_MUTEX_NORMAL).
Does this inconsistent VFS lockdep subclass usage defeat lockdep's parent-child
ordering checks? Using different subclasses for the same directory's i_rwsem
might split the lockdep tracking and hide potential deadlocks from the
validator.
Should this be inode_lock_nested(root, I_MUTEX_PARENT) to match the removal
paths?
> set_bit(MISC_FMT_ENABLED_BIT, &e->flags);
> + if (hlist_unhashed(&e->node) && !d_unhashed(e->dentry)) {
> + struct binfmt_misc *misc = i_binfmt_misc(inode);
> +
> + spin_lock(&misc->entries_lock);
> + hlist_add_head_rcu(&e->node, &misc->entries);
> + spin_unlock(&misc->entries_lock);
> + }
> + inode_unlock(root);
> break;
> + }
> case BM_CMD_REMOVE:
> bm_remove_entry(e, inode->i_sb);
> break;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-work-binfmt_misc-preopen-v1-0-4a0b0da71f16@kernel.org?part=1
next prev parent reply other threads:[~2026-07-30 13:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 13:34 [PATCH 0/9] binfmt_misc: bind interpreters to a bpf-backed entry Christian Brauner
2026-07-30 13:34 ` [PATCH 1/9] binfmt_misc: let a register string create an entry disabled Christian Brauner
2026-07-30 13:47 ` sashiko-bot [this message]
2026-07-30 13:34 ` [PATCH 2/9] selftests/exec: let binfmt_flag_supported() return a bool Christian Brauner
2026-07-30 13:34 ` [PATCH 3/9] selftests/exec: test registering an entry disabled Christian Brauner
2026-07-30 13:45 ` sashiko-bot
2026-07-30 13:34 ` [PATCH 4/9] binfmt_misc: document " Christian Brauner
2026-07-30 13:34 ` [PATCH 5/9] selftests/exec: share the bpf handler preconditions Christian Brauner
2026-07-30 13:34 ` [PATCH 6/9] binfmt_misc: carry pre-opened interpreters in struct binfmt_misc_interp Christian Brauner
2026-07-30 13:34 ` [PATCH 7/9] binfmt_misc: let a 'B' entry bind its interpreters Christian Brauner
2026-07-30 13:34 ` [PATCH 8/9] selftests/exec: test interpreters bound to a 'B' entry Christian Brauner
2026-07-30 13:34 ` [PATCH 9/9] binfmt_misc: document interpreters bound by " 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=20260730134757.A21231F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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