linux-kernel - Re: [PATCH RFC 1/2] configfs: add kernel-space item registration API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aTCTAqEh0qppzVPn@google.com>
Date: Wed, 3 Dec 2025 11:44:02 -0800
From: Joel Becker <jlbec@...lplan.org>
To: Breno Leitao <leitao@...ian.org>
Cc: Andreas Hindborg <a.hindborg@...nel.org>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	linux-kernel@...r.kernel.org, hch@...radead.org,
	linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org,
	gustavold@...il.com, asantostc@...il.com, calvin@...nvd.org,
	kernel-team@...a.com
Subject: Re: [PATCH RFC 1/2] configfs: add kernel-space item registration API

On Tue, Dec 02, 2025 at 07:29:01AM -0800, Breno Leitao wrote:
> Add configfs_register_item() and configfs_unregister_item() functions
> to allow kernel modules to register configfs items whose lifecycle is
> controlled by kernel space rather than userspace.
> 
> This is useful for subsystems that need to expose configuration items
> that are created based on kernel events (like boot parameters) rather
> than explicit userspace mkdir operations. The items registered this
> way are marked as default items (CONFIGFS_USET_DEFAULT) and cannot be
> removed via rmdir.
> 
> The API follows the same pattern as configfs_register_group() but for
> individual items:
> - configfs_register_item() links the item into the parent group's
>   hierarchy and creates the filesystem representation
> - configfs_unregister_item() reverses the registration, removing the
>   item from configfs
> 
> Signed-off-by: Breno Leitao <leitao@...ian.org>
> ---
>  fs/configfs/dir.c        | 134 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/configfs.h |   4 +++
>  2 files changed, 138 insertions(+)
> 
> diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
> index 81f4f06bc87e..f7224bc51826 100644
> --- a/fs/configfs/dir.c
> +++ b/fs/configfs/dir.c
> @@ -1866,6 +1866,140 @@ void configfs_unregister_default_group(struct config_group *group)
>  }
>  EXPORT_SYMBOL(configfs_unregister_default_group);
>  
> +/**
> + * configfs_register_item() - registers a kernel-created item with a parent group
> + * @parent_group: parent group for the new item
> + * @item: item to be registered
> + *
> + * This function allows kernel code to register configfs items whose lifecycle
> + * is controlled by kernel space rather than userspace (via mkdir/rmdir).
> + * The item must be already initialized with config_item_init_type_name().
> + *
> + * Return: 0 on success, negative errno on failure
> + */
> +int configfs_register_item(struct config_group *parent_group,
> +			   struct config_item *item)
> +{
> +	struct configfs_subsystem *subsys = parent_group->cg_subsys;
> +	struct configfs_fragment *frag;
> +	struct dentry *parent, *child;
> +	struct configfs_dirent *sd;
> +	int ret;
> +
> +	if (!subsys || !item->ci_name)
> +		return -EINVAL;
> +
> +	frag = new_fragment();
> +	if (!frag)
> +		return -ENOMEM;
> +
> +	parent = parent_group->cg_item.ci_dentry;
> +	/* Allocate dentry for the item */
> +	child = d_alloc_name(parent, item->ci_name);
> +	if (!child) {
> +		put_fragment(frag);
> +		return -ENOMEM;
> +	}
> +
> +	mutex_lock(&subsys->su_mutex);
> +	link_obj(&parent_group->cg_item, item);
> +	mutex_unlock(&subsys->su_mutex);
> +
> +	inode_lock_nested(d_inode(parent), I_MUTEX_PARENT);
> +	d_add(child, NULL);
> +
> +	/* Attach the item to the filesystem */
> +	ret = configfs_attach_item(&parent_group->cg_item, item, child, frag);
> +	if (ret)
> +		goto err_out;

The behavior here is significantly different than the flow in
configfs_mkdir().  How do we a) ensure we're getting the right outcome
b) make sure that commensurate changes in one are propagated to the
other?

For example, we take pains to get module pinning right in
configfs_mkdir(), both for the parent_item and the child item.  I see no
pinning here.  I see no handling of races with unregister (like the
teardown races with rmdir).

Some of these things are just different with kernel-registered items.  I
presume you are declaring the child item must be fully created, which is
why this code doesn't call ->make_item().  But there is no documentation
of that requirement.

Thanks,
Joel

-- 

"Baby, even the losers
 Get luck sometimes.
 Even the losers
 Keep a little bit of pride."

			http://www.jlbec.org/
			jlbec@...lplan.org