BPF List
 help / color / mirror / Atom feed
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

  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