All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Runyu Xiao" <runyu.xiao@seu.edu.cn>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v7 1/4] fs: configfs: add helpers for opening non-configfs paths
Date: Sun, 27 Sep 2026 08:39:09 +0000	[thread overview]
Message-ID: <20260927083909.A2EC21F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260927082011.638723-2-runyu.xiao@seu.edu.cn>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] fs: deadlock bypass in configfs_open_root() via mountpoint traversal
--

commit 493a740e66f883a25d1e14e7e3f3596fe9f2721a
Author: Runyu Xiao <runyu.xiao@seu.edu.cn>

fs: configfs: add helpers for opening non-configfs paths

This commit adds configfs_file_open() and configfs_open_root() to allow
configfs store callbacks to open non-configfs paths without re-entering
configfs. It checks if the provided root is on configfs to prevent
acquiring the non-recursive fragment semaphore again.

Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>

> diff --git a/fs/configfs/mount.c b/fs/configfs/mount.c
> --- a/fs/configfs/mount.c
> +++ b/fs/configfs/mount.c

[ ... ]

> +struct file *configfs_open_root(const struct path *root, const char *name,
> +				int flags, umode_t mode)
> +{
> +	if (root->dentry->d_sb->s_type == &configfs_fs_type)
> +		return ERR_PTR(-EINVAL);
> +
> +	return file_open_root(root, name, flags, mode);

[Severity: Medium]
Could this bypass the deadlock prevention if a configfs mount exists inside the
starting directory?

The check against configfs_fs_type only validates the starting root directory's
superblock. However, file_open_root() can traverse mountpoints.

If a user mounts configfs inside the non-configfs root directory, the final
resolved file could still be on configfs.

If this happens during a store callback that already holds frag_sem,
file_open_root() opening the file will trigger configfs_open_file(). This
would try to acquire down_read(&frag->frag_sem) again, which could result
in a deadlock.

> +}
> +EXPORT_SYMBOL_GPL(configfs_open_root);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260927082011.638723-1-runyu.xiao@seu.edu.cn?part=1

  reply	other threads:[~2026-09-27  8:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-27  8:20 [PATCH v7 0/4] nvmet: avoid recursive configfs open Runyu Xiao
2026-09-27  8:20 ` [PATCH v7 1/4] fs: configfs: add helpers for opening non-configfs paths Runyu Xiao
2026-09-27  8:39   ` sashiko-bot [this message]
2026-09-27  8:20 ` [PATCH v7 2/4] nvmet: avoid recursive configfs open for file-backed namespaces Runyu Xiao
2026-09-27  8:20 ` [PATCH v7 3/4] nvmet: avoid recursive configfs open for passthru Runyu Xiao
2026-09-27  8:20 ` [PATCH v7 4/4] scsi: target: pin db_root for metadata writes Runyu Xiao
2026-09-28  5:12 ` [PATCH v7 0/4] nvmet: avoid recursive configfs open Christoph Hellwig

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=20260927083909.A2EC21F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=runyu.xiao@seu.edu.cn \
    --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 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.