[PATCH RFC 0/2] configfs: enable kernel-space item registration

[PATCH RFC 0/2] configfs: enable kernel-space item registration

[Breno Leitao]

This series introduces a new kernel-space item registration API for configfs
to enable subsystems to programmatically create configfs items whose lifecycle
is controlled by the kernel rather than userspace.

Currently, configfs items can only be created via userspace mkdir operations,
which limits their utility for kernel-driven configuration scenarios such as
boot parameters or hardware auto-detection.

This discussion about this feature started 2 years ago[1], when netconsole needed to have
an configfs target that maps to what was passed by cmdline (something as
netconsole=+6666@192.168.1.1....)

The suggestion was to workaround configfs limitation by asking users to create
some pre-defined configfs entries specially named (such as "cmdlineX", where X
is the entry index in the list of targets), that would match entries coming from
cmdline.

That proved to be confusing in many ways, such as:

 1) if cmdline is not properly passed or parsed, then cmdline0 becomes a new
    and unrelated target
 2) If netconsole becomes a module, then cmdline0 is not populated, so, the
    creation of cmdline0 is something unrelated to what we have in cmdline.
 3) The admin needs to create X items properly matching the iterms from cmdline,
    which is error prone.

The solution proposed in this patchset is to manage the life cycle of an item by the
kernel (if the cmdline entry exists, it will populate the cofingfs
automatically), instead of by the user (mkdir-ing special names).

The new configfs_register_item() and configfs_unregister_item() functions fill
this gap by allowing kernel modules to register items that appear in configfs
but are protected from userspace removal. These items are marked with the
CONFIGFS_USET_DEFAULT flag, making them behave similarly to default groups that
are automatically created but cannot be removed via rmdir.

The primary motivation for this work is to support dynamic netconsole target
registration from boot parameters.

Currently, netconsole can be configured either statically at boot time
(cmdline) or dynamically via userspace manipulation of configfs directories.

However, there is no way to create netconsole targets from kernel command line
parameters that persist in configfs for runtime inspection and modification.

This series addresses that limitation by providing the necessary configfs
infrastructure, making netconsole management easier, and simplifying the
code.

Link: https://lore.kernel.org/all/ZRWRal5bW93px4km@gmail.com/ [1]

---
Breno Leitao (2):
      configfs: add kernel-space item registration API
      netconsole: Plug to dynamic configfs item

 drivers/net/netconsole.c |  63 +++++++++++++++-----------------------------
 fs/configfs/dir.c        | 134 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/configfs.h |   4 +++
 3 files changed, 159 insertions(+), 42 deletions(-)
---
base-commit: e538109ac71d801d26776af5f3c54f548296c29c
change-id: 20251128-configfs_netcon-f53ec4ca3363

Best regards,
--  
Breno Leitao <leitao@debian.org>

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

[Breno Leitao]

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@debian.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;
+
+	/*
+	 * CONFIGFS_USET_DEFAULT mark item as kernel-created (cannot be removed
+	 * by userspace)
+	 */
+	sd = child->d_fsdata;
+	sd->s_type |= CONFIGFS_USET_DEFAULT;
+
+	/* Mark directory as ready */
+	spin_lock(&configfs_dirent_lock);
+	configfs_dir_set_ready(child->d_fsdata);
+	spin_unlock(&configfs_dirent_lock);
+
+	inode_unlock(d_inode(parent));
+	put_fragment(frag);
+	return 0;
+
+err_out:
+	d_drop(child);
+	dput(child);
+	inode_unlock(d_inode(parent));
+	mutex_lock(&subsys->su_mutex);
+	unlink_obj(item);
+	mutex_unlock(&subsys->su_mutex);
+	put_fragment(frag);
+	return ret;
+}
+EXPORT_SYMBOL(configfs_register_item);
+
+/**
+ * configfs_unregister_item() - unregisters a kernel-created item
+ * @item: item to be unregistered
+ *
+ * This function reverses the effect of configfs_register_item(), removing
+ * the item from the configfs filesystem and releasing associated resources.
+ * The item must have been previously registered with configfs_register_item().
+ */
+void configfs_unregister_item(struct config_item *item)
+{
+	struct config_group *group = item->ci_group;
+	struct dentry *dentry = item->ci_dentry;
+	struct configfs_subsystem *subsys;
+	struct configfs_fragment *frag;
+	struct configfs_dirent *sd;
+	struct dentry *parent;
+
+	if (!group || !dentry)
+		return;
+
+	subsys = group->cg_subsys;
+	if (!subsys)
+		return;
+
+	parent = item->ci_parent->ci_dentry;
+	sd = dentry->d_fsdata;
+	frag = get_fragment(sd->s_frag);
+
+	if (WARN_ON(!(sd->s_type & CONFIGFS_USET_DEFAULT))) {
+		put_fragment(frag);
+		return;
+	}
+
+	/* Mark fragment as dead */
+	down_write(&frag->frag_sem);
+	frag->frag_dead = true;
+	up_write(&frag->frag_sem);
+
+	inode_lock_nested(d_inode(parent), I_MUTEX_PARENT);
+	spin_lock(&configfs_dirent_lock);
+	configfs_detach_prep(dentry, NULL);
+	spin_unlock(&configfs_dirent_lock);
+
+	configfs_detach_item(item);
+	d_inode(dentry)->i_flags |= S_DEAD;
+	dont_mount(dentry);
+	d_drop(dentry);
+	fsnotify_rmdir(d_inode(parent), dentry);
+	dput(dentry);
+	inode_unlock(d_inode(parent));
+
+	mutex_lock(&subsys->su_mutex);
+	unlink_obj(item);
+	mutex_unlock(&subsys->su_mutex);
+
+	put_fragment(frag);
+}
+EXPORT_SYMBOL(configfs_unregister_item);
+
 int configfs_register_subsystem(struct configfs_subsystem *subsys)
 {
 	int err;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 698520b1bfdb..70f2d113b4b3 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -244,6 +244,10 @@ int configfs_register_group(struct config_group *parent_group,
 			    struct config_group *group);
 void configfs_unregister_group(struct config_group *group);
 
+int configfs_register_item(struct config_group *parent_group,
+			   struct config_item *item);
+void configfs_unregister_item(struct config_item *item);
+
 void configfs_remove_default_groups(struct config_group *group);
 
 struct config_group *

-- 
2.47.3

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

[Joel Becker]

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@debian.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@evilplan.org

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

[Breno Leitao]

Hello Joel,

First of all, thanks for thre review,

On Wed, Dec 03, 2025 at 11:44:02AM -0800, Joel Becker wrote:
> 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@debian.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.

You're absolutely right about the missing module pinning and race
protection. 

On my example (netconsole), the items were added during module
initialization and removed during device tear down, which is not an
excuse, given the interface should be generic enough.

I suppose I want to try_module_get(subsys_owner) and
try_module_get(type->ct_owner) at the beginning of
configfs_register_item(), and then put them back in
configfs_unregister_item(). Would it be enough?


  int configfs_register_item(struct config_group *parent_group,
                             struct config_item *item)
	...
         /*
           * Pin the subsystem module first. The subsystem may belong to a
           * different module than the item being registered. We need to pin
           * both to prevent the subsystem from being unloaded while the item
           * exists.
           */
          if (!subsys->su_group.cg_item.ci_type) {
                  ret = -EINVAL;
                  goto out;
          }
          subsys_owner = subsys->su_group.cg_item.ci_type->ct_owner;
          if (!try_module_get(subsys_owner)) {
                  ret = -EINVAL;
                  goto out;
          }

          /*
           * Pin the item's module. This prevents the module providing the
           * item's type (and its operations) from being unloaded.
           */
          item_owner = type->ct_owner;
          if (!try_module_get(item_owner)) {
                  ret = -EINVAL;
                  goto out_subsys_put;
          }

> 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.

Would CONFIGFS_USET_IN_MKDIR be enought in this case?

> 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.

Right, do you think a kdoc would be enough in this case?

This is the new functions I am coming up with, in case you want to read the full functions.

Thanks for the review!!

-- 

diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index 81f4f06bc87e..73aa4e4a0966 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -1866,6 +1866,248 @@ 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).
+ *
+ * Unlike configfs_mkdir(), which creates the item via ->make_item() callback,
+ * this function expects the item to be FULLY INITIALIZED by the caller before
+ * registration. This means:
+ *  - The item must be initialized with config_item_init_type_name()
+ *  - The item->ci_type must be set and valid
+ *  - The item->ci_type->ct_owner (module) must be valid
+ *  - Any item-specific initialization must be complete
+ *
+ * This function follows the same module pinning and locking semantics as
+ * configfs_mkdir() to ensure proper synchronization with rmdir and module
+ * unloading.
+ *
+ * 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 module *subsys_owner = NULL, *item_owner = NULL;
+	const struct config_item_type *type;
+	struct configfs_fragment *frag;
+	struct dentry *parent, *child;
+	struct configfs_dirent *sd;
+	int ret;
+
+	if (!subsys || !item->ci_name)
+		return -EINVAL;
+
+	/*
+	 * Validate that the item is fully initialized. Unlike configfs_mkdir(),
+	 * we don't call ->make_item(), so the caller must provide a complete
+	 * item with a valid type.
+	 */
+	type = item->ci_type;
+	if (!type) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	/*
+	 * Pin the subsystem module first. The subsystem may belong to a
+	 * different module than the item being registered. We need to pin
+	 * both to prevent the subsystem from being unloaded while the item
+	 * exists.
+	 */
+	if (!subsys->su_group.cg_item.ci_type) {
+		ret = -EINVAL;
+		goto out;
+	}
+	subsys_owner = subsys->su_group.cg_item.ci_type->ct_owner;
+	if (!try_module_get(subsys_owner)) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	/*
+	 * Pin the item's module. This prevents the module providing the
+	 * item's type (and its operations) from being unloaded.
+	 */
+	item_owner = type->ct_owner;
+	if (!try_module_get(item_owner)) {
+		ret = -EINVAL;
+		goto out_subsys_put;
+	}
+
+	frag = new_fragment();
+	if (!frag) {
+		ret = -ENOMEM;
+		goto out_item_put;
+	}
+
+	parent = parent_group->cg_item.ci_dentry;
+	/* Allocate dentry for the item */
+	child = d_alloc_name(parent, item->ci_name);
+	if (!child) {
+		ret = -ENOMEM;
+		put_fragment(frag);
+		goto out_item_put;
+	}
+
+	/*
+	 * Link the item into the parent group's hierarchy under the subsystem
+	 * mutex. This must be done before attaching to the filesystem.
+	 */
+	mutex_lock(&subsys->su_mutex);
+	link_obj(&parent_group->cg_item, item);
+	mutex_unlock(&subsys->su_mutex);
+
+	/*
+	 * From here on, errors must unlink the item since link_obj() has
+	 * been called.
+	 */
+	inode_lock_nested(d_inode(parent), I_MUTEX_PARENT);
+
+	/*
+	 * Protect against racing with configfs_unregister_item() or rmdir.
+	 * The CONFIGFS_USET_IN_MKDIR flag will cause configfs_detach_prep()
+	 * to fail, preventing concurrent teardown.
+	 */
+	sd = parent->d_fsdata;
+	spin_lock(&configfs_dirent_lock);
+	sd->s_type |= CONFIGFS_USET_IN_MKDIR;
+	spin_unlock(&configfs_dirent_lock);
+
+	d_add(child, NULL);
+
+	/* Attach the item to the filesystem */
+	ret = configfs_attach_item(&parent_group->cg_item, item, child, frag);
+	/* if ret > 0, it will end up in err_unlink after unlocking everything */
+
+	spin_lock(&configfs_dirent_lock);
+	sd->s_type &= ~CONFIGFS_USET_IN_MKDIR;
+	if (!ret) {
+		struct configfs_dirent *child_sd = child->d_fsdata;
+		/*
+		 * Mark as CONFIGFS_USET_DEFAULT to indicate this is a
+		 * kernel-created item that cannot be removed via rmdir.
+		 */
+		child_sd->s_type |= CONFIGFS_USET_DEFAULT;
+		configfs_dir_set_ready(child_sd);
+	}
+	spin_unlock(&configfs_dirent_lock);
+	inode_unlock(d_inode(parent));
+
+	/* in case configfs_attach_item() has failed */
+	if (ret)
+		goto err_unlink;
+
+	put_fragment(frag);
+	return 0;
+
+err_unlink:
+	/* Tear down everything we built up */
+	d_drop(child);
+	dput(child);
+	mutex_lock(&subsys->su_mutex);
+	unlink_obj(item);
+	mutex_unlock(&subsys->su_mutex);
+	put_fragment(frag);
+
+out_item_put:
+	module_put(item_owner);
+out_subsys_put:
+	module_put(subsys_owner);
+out:
+	return ret;
+}
+EXPORT_SYMBOL(configfs_register_item);
+
+/**
+ * configfs_unregister_item() - unregisters a kernel-created item
+ * @item: item to be unregistered
+ *
+ * This function reverses the effect of configfs_register_item(), removing
+ * the item from the configfs filesystem and releasing associated resources.
+ * The item must have been previously registered with configfs_register_item().
+ *
+ * This function releases the module references acquired during registration,
+ * following the same teardown semantics as configfs_rmdir().
+ */
+void configfs_unregister_item(struct config_item *item)
+{
+	struct config_group *group = item->ci_group;
+	struct dentry *dentry = item->ci_dentry;
+	struct configfs_subsystem *subsys;
+	struct configfs_fragment *frag;
+	struct configfs_dirent *sd;
+	struct dentry *parent;
+	struct module *subsys_owner = NULL, *item_owner = NULL;
+
+	if (!group || !dentry)
+		return;
+
+	subsys = group->cg_subsys;
+	if (!subsys)
+		return;
+
+	parent = item->ci_parent->ci_dentry;
+	sd = dentry->d_fsdata;
+	frag = get_fragment(sd->s_frag);
+
+	if (WARN_ON(!(sd->s_type & CONFIGFS_USET_DEFAULT))) {
+		put_fragment(frag);
+		return;
+	}
+
+	/*
+	 * Retrieve module owners before detaching. These were pinned during
+	 * configfs_register_item() and must be released.
+	 */
+	if (subsys->su_group.cg_item.ci_type)
+		subsys_owner = subsys->su_group.cg_item.ci_type->ct_owner;
+	if (item->ci_type)
+		item_owner = item->ci_type->ct_owner;
+
+	/* Mark fragment as dead */
+	down_write(&frag->frag_sem);
+	frag->frag_dead = true;
+	up_write(&frag->frag_sem);
+
+	inode_lock_nested(d_inode(parent), I_MUTEX_PARENT);
+	/*
+	 * Take configfs_symlink_mutex to prevent racing with symlink
+	 * creation/removal, matching the locking in configfs_rmdir().
+	 */
+	mutex_lock(&configfs_symlink_mutex);
+	spin_lock(&configfs_dirent_lock);
+	configfs_detach_prep(dentry, NULL);
+	spin_unlock(&configfs_dirent_lock);
+	mutex_unlock(&configfs_symlink_mutex);
+
+	configfs_detach_item(item);
+	d_inode(dentry)->i_flags |= S_DEAD;
+	dont_mount(dentry);
+	d_drop(dentry);
+	fsnotify_rmdir(d_inode(parent), dentry);
+	dput(dentry);
+	inode_unlock(d_inode(parent));
+
+	mutex_lock(&subsys->su_mutex);
+	unlink_obj(item);
+	mutex_unlock(&subsys->su_mutex);
+
+	put_fragment(frag);
+
+	/*
+	 * Release module references that were acquired during registration.
+	 * This mirrors the cleanup in configfs_rmdir().
+	 */
+	module_put(item_owner);
+	module_put(subsys_owner);
+}
+EXPORT_SYMBOL(configfs_unregister_item);
+
 int configfs_register_subsystem(struct configfs_subsystem *subsys)
 {
 	int err;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 698520b1bfdb..70f2d113b4b3 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -244,6 +244,10 @@ int configfs_register_group(struct config_group *parent_group,
 			    struct config_group *group);
 void configfs_unregister_group(struct config_group *group);
 
+int configfs_register_item(struct config_group *parent_group,
+			   struct config_item *item);
+void configfs_unregister_item(struct config_item *item);
+
 void configfs_remove_default_groups(struct config_group *group);
 
 struct config_group *

[PATCH RFC 2/2] netconsole: Plug to dynamic configfs item

[Breno Leitao]

Convert netconsole to use the new configfs kernel-space item
registration API for command-line configured targets.

Previously, netconsole created boot-time targets by searching for them
when userspace tried to create an item with the a special name. This
approach was fragile and hard for users to deal with.

This change refactors netconsole to:
  - Call configfs_register_item() directly from populate_configfs_item()
    to properly register boot/module parameter targets.

  - Remove the find_cmdline_target() logic and the special handling in
    make_netconsole_target() that intercepted userspace operations (aka
    the ugly workaround)

This makes the management of netconsole easier, simplifies the code
(removing ~40 lines) and properly separates kernel-created items from
userspace-created items, making the code more maintainable and robust.

Signed-off-by: Breno Leitao <leitao@debian.org>
---
 drivers/net/netconsole.c | 63 +++++++++++++++++++++------------------------------------------
 1 file changed, 21 insertions(+), 42 deletions(-)

diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index bb6e03a92956..d3c720a2f9ef 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -225,8 +225,8 @@ static void netconsole_target_put(struct netconsole_target *nt)
 {
 }
 
-static void populate_configfs_item(struct netconsole_target *nt,
-				   int cmdline_count)
+static int populate_configfs_item(struct netconsole_target *nt,
+				  int cmdline_count)
 {
 }
 #endif	/* CONFIG_NETCONSOLE_DYNAMIC */
@@ -1256,23 +1256,6 @@ static void init_target_config_group(struct netconsole_target *nt,
 	configfs_add_default_group(&nt->userdata_group, &nt->group);
 }
 
-static struct netconsole_target *find_cmdline_target(const char *name)
-{
-	struct netconsole_target *nt, *ret = NULL;
-	unsigned long flags;
-
-	spin_lock_irqsave(&target_list_lock, flags);
-	list_for_each_entry(nt, &target_list, list) {
-		if (!strcmp(nt->group.cg_item.ci_name, name)) {
-			ret = nt;
-			break;
-		}
-	}
-	spin_unlock_irqrestore(&target_list_lock, flags);
-
-	return ret;
-}
-
 /*
  * Group operations and type for netconsole_subsys.
  */
@@ -1283,19 +1266,6 @@ static struct config_group *make_netconsole_target(struct config_group *group,
 	struct netconsole_target *nt;
 	unsigned long flags;
 
-	/* Checking if a target by this name was created at boot time.  If so,
-	 * attach a configfs entry to that target.  This enables dynamic
-	 * control.
-	 */
-	if (!strncmp(name, NETCONSOLE_PARAM_TARGET_PREFIX,
-		     strlen(NETCONSOLE_PARAM_TARGET_PREFIX))) {
-		nt = find_cmdline_target(name);
-		if (nt) {
-			init_target_config_group(nt, name);
-			return &nt->group;
-		}
-	}
-
 	nt = alloc_and_init();
 	if (!nt)
 		return ERR_PTR(-ENOMEM);
@@ -1351,14 +1321,20 @@ static struct configfs_subsystem netconsole_subsys = {
 	},
 };
 
-static void populate_configfs_item(struct netconsole_target *nt,
-				   int cmdline_count)
+static int populate_configfs_item(struct netconsole_target *nt,
+				  int cmdline_count)
 {
 	char target_name[16];
+	int ret;
 
 	snprintf(target_name, sizeof(target_name), "%s%d",
 		 NETCONSOLE_PARAM_TARGET_PREFIX, cmdline_count);
+
 	init_target_config_group(nt, target_name);
+
+	ret = configfs_register_item(&netconsole_subsys.su_group,
+				     &nt->group.cg_item);
+	return ret;
 }
 
 static int sysdata_append_cpu_nr(struct netconsole_target *nt, int offset)
@@ -1899,7 +1875,9 @@ static struct netconsole_target *alloc_param_target(char *target_config,
 	} else {
 		nt->enabled = true;
 	}
-	populate_configfs_item(nt, cmdline_count);
+	err = populate_configfs_item(nt, cmdline_count);
+	if (err)
+		goto fail;
 
 	return nt;
 
@@ -1911,6 +1889,8 @@ static struct netconsole_target *alloc_param_target(char *target_config,
 /* Cleanup netpoll for given target (from boot/module param) and free it */
 static void free_param_target(struct netconsole_target *nt)
 {
+	if (nt->group.cg_item.ci_dentry)
+		configfs_unregister_item(&nt->group.cg_item);
 	netpoll_cleanup(&nt->np);
 	kfree(nt);
 }
@@ -1937,6 +1917,10 @@ static int __init init_netconsole(void)
 	char *target_config;
 	char *input = config;
 
+	err = dynamic_netconsole_init();
+	if (err)
+		goto exit;
+
 	if (strnlen(input, MAX_PARAM_LENGTH)) {
 		while ((target_config = strsep(&input, ";"))) {
 			nt = alloc_param_target(target_config, count);
@@ -1966,10 +1950,6 @@ static int __init init_netconsole(void)
 	if (err)
 		goto fail;
 
-	err = dynamic_netconsole_init();
-	if (err)
-		goto undonotifier;
-
 	if (console_type_needed & CONS_EXTENDED)
 		register_console(&netconsole_ext);
 	if (console_type_needed & CONS_BASIC)
@@ -1978,10 +1958,8 @@ static int __init init_netconsole(void)
 
 	return err;
 
-undonotifier:
-	unregister_netdevice_notifier(&netconsole_netdev_notifier);
-
 fail:
+	dynamic_netconsole_exit();
 	pr_err("cleaning up\n");
 
 	/*
@@ -1993,6 +1971,7 @@ static int __init init_netconsole(void)
 		list_del(&nt->list);
 		free_param_target(nt);
 	}
+exit:
 
 	return err;
 }

-- 
2.47.3

Re: [PATCH RFC 2/2] netconsole: Plug to dynamic configfs item

[kernel test robot]

Hi Breno,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on e538109ac71d801d26776af5f3c54f548296c29c]

url:    https://github.com/intel-lab-lkp/linux/commits/Breno-Leitao/configfs-add-kernel-space-item-registration-API/20251202-233234
base:   e538109ac71d801d26776af5f3c54f548296c29c
patch link:    https://lore.kernel.org/r/20251202-configfs_netcon-v1-2-b4738ead8ee8%40debian.org
patch subject: [PATCH RFC 2/2] netconsole: Plug to dynamic configfs item
config: hexagon-randconfig-001-20251205 (https://download.01.org/0day-ci/archive/20251205/202512052219.nHgf3wdu-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 14bf95b06a18b9b59c89601cbc0e5a6f2176b118)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251205/202512052219.nHgf3wdu-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512052219.nHgf3wdu-lkp@intel.com/

All error/warnings (new ones prefixed by >>):

>> drivers/net/netconsole.c:231:1: warning: non-void function does not return a value [-Wreturn-type]
     231 | }
         | ^
>> drivers/net/netconsole.c:1892:10: error: no member named 'group' in 'struct netconsole_target'
    1892 |         if (nt->group.cg_item.ci_dentry)
         |             ~~  ^
   drivers/net/netconsole.c:1893:33: error: no member named 'group' in 'struct netconsole_target'
    1893 |                 configfs_unregister_item(&nt->group.cg_item);
         |                                           ~~  ^
   1 warning and 2 errors generated.


vim +1892 drivers/net/netconsole.c

  1888	
  1889	/* Cleanup netpoll for given target (from boot/module param) and free it */
  1890	static void free_param_target(struct netconsole_target *nt)
  1891	{
> 1892		if (nt->group.cg_item.ci_dentry)
  1893			configfs_unregister_item(&nt->group.cg_item);
  1894		netpoll_cleanup(&nt->np);
  1895		kfree(nt);
  1896	}
  1897	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH RFC 2/2] netconsole: Plug to dynamic configfs item

[kernel test robot]

Hi Breno,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on e538109ac71d801d26776af5f3c54f548296c29c]

url:    https://github.com/intel-lab-lkp/linux/commits/Breno-Leitao/configfs-add-kernel-space-item-registration-API/20251202-233234
base:   e538109ac71d801d26776af5f3c54f548296c29c
patch link:    https://lore.kernel.org/r/20251202-configfs_netcon-v1-2-b4738ead8ee8%40debian.org
patch subject: [PATCH RFC 2/2] netconsole: Plug to dynamic configfs item
config: arc-randconfig-001-20251205 (https://download.01.org/0day-ci/archive/20251205/202512052343.v0ejaRho-lkp@intel.com/config)
compiler: arc-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251205/202512052343.v0ejaRho-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512052343.v0ejaRho-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/net/netconsole.c: In function 'populate_configfs_item':
   drivers/net/netconsole.c:231:1: warning: no return statement in function returning non-void [-Wreturn-type]
    }
    ^
   drivers/net/netconsole.c: In function 'free_param_target':
>> drivers/net/netconsole.c:1892:8: error: 'struct netconsole_target' has no member named 'group'
     if (nt->group.cg_item.ci_dentry)
           ^~
   drivers/net/netconsole.c:1893:31: error: 'struct netconsole_target' has no member named 'group'
      configfs_unregister_item(&nt->group.cg_item);
                                  ^~


vim +1892 drivers/net/netconsole.c

  1888	
  1889	/* Cleanup netpoll for given target (from boot/module param) and free it */
  1890	static void free_param_target(struct netconsole_target *nt)
  1891	{
> 1892		if (nt->group.cg_item.ci_dentry)
  1893			configfs_unregister_item(&nt->group.cg_item);
  1894		netpoll_cleanup(&nt->np);
  1895		kfree(nt);
  1896	}
  1897	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH RFC 2/2] netconsole: Plug to dynamic configfs item

[kernel test robot]

Hi Breno,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build warnings:

[auto build test WARNING on e538109ac71d801d26776af5f3c54f548296c29c]

url:    https://github.com/intel-lab-lkp/linux/commits/Breno-Leitao/configfs-add-kernel-space-item-registration-API/20251202-233234
base:   e538109ac71d801d26776af5f3c54f548296c29c
patch link:    https://lore.kernel.org/r/20251202-configfs_netcon-v1-2-b4738ead8ee8%40debian.org
patch subject: [PATCH RFC 2/2] netconsole: Plug to dynamic configfs item
config: i386-allyesconfig (https://download.01.org/0day-ci/archive/20251206/202512061018.Q68LVWTz-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251206/202512061018.Q68LVWTz-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512061018.Q68LVWTz-lkp@intel.com/

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> WARNING: modpost: vmlinux: section mismatch in reference: init_netconsole+0x309 (section: .init.text) -> dynamic_netconsole_exit (section: .exit.text)

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Andreas Hindborg]

"Breno Leitao" <leitao@debian.org> writes:

> This series introduces a new kernel-space item registration API for configfs
> to enable subsystems to programmatically create configfs items whose lifecycle
> is controlled by the kernel rather than userspace.
>
> Currently, configfs items can only be created via userspace mkdir operations,
> which limits their utility for kernel-driven configuration scenarios such as
> boot parameters or hardware auto-detection.

I thought sysfs would handle this kind of scenarios?


Best regards,
Andreas Hindborg

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Breno Leitao]

Hello Andreas,

On Fri, Dec 05, 2025 at 06:35:12PM +0100, Andreas Hindborg wrote:
> "Breno Leitao" <leitao@debian.org> writes:
> 
> > This series introduces a new kernel-space item registration API for configfs
> > to enable subsystems to programmatically create configfs items whose lifecycle
> > is controlled by the kernel rather than userspace.
> >
> > Currently, configfs items can only be created via userspace mkdir operations,
> > which limits their utility for kernel-driven configuration scenarios such as
> > boot parameters or hardware auto-detection.
> 
> I thought sysfs would handle this kind of scenarios?

sysfs has gaps as well, to manage user-create items.

Netconsole has two types of "targets". Those created dynamically
(CONFIG_NETCONSOLE_DYNAMIC), where user can create and remove as many
targets as it needs, and netconsole would send to it. This fits very
well in configfs.

  mkdir /sys/kernel/config/netconsole/mytarget
  .. manage the target using configfs items/files
  rmdir /sys/kernel/config/netconsole/mytarget

This is a perfect fit for configfs, and I don't see how it would work
with sysfs.

On top of that, there are netconsole targets that are coming from
cmdline (basically to cover while userspace is not initialized). These
are coming from cmdline and its life-cycle is managed by the kernel.
I.e, the kernel knows about them, and wants to expose it to the user
(which can even disable them later). This is the problem I this patch
addresses (exposing them easily).

It is kind of a mix of kernel and user-managed configuration items in
coexisting.

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Andreas Hindborg]

"Breno Leitao" <leitao@debian.org> writes:

> Hello Andreas,
>
> On Fri, Dec 05, 2025 at 06:35:12PM +0100, Andreas Hindborg wrote:
>> "Breno Leitao" <leitao@debian.org> writes:
>>
>> > This series introduces a new kernel-space item registration API for configfs
>> > to enable subsystems to programmatically create configfs items whose lifecycle
>> > is controlled by the kernel rather than userspace.
>> >
>> > Currently, configfs items can only be created via userspace mkdir operations,
>> > which limits their utility for kernel-driven configuration scenarios such as
>> > boot parameters or hardware auto-detection.
>>
>> I thought sysfs would handle this kind of scenarios?
>
> sysfs has gaps as well, to manage user-create items.
>
> Netconsole has two types of "targets". Those created dynamically
> (CONFIG_NETCONSOLE_DYNAMIC), where user can create and remove as many
> targets as it needs, and netconsole would send to it. This fits very
> well in configfs.
>
>   mkdir /sys/kernel/config/netconsole/mytarget
>   .. manage the target using configfs items/files
>   rmdir /sys/kernel/config/netconsole/mytarget
>
> This is a perfect fit for configfs, and I don't see how it would work
> with sysfs.

Right, these go in configfs, we are on the same page about that.

>
> On top of that, there are netconsole targets that are coming from
> cmdline (basically to cover while userspace is not initialized). These
> are coming from cmdline and its life-cycle is managed by the kernel.
> I.e, the kernel knows about them, and wants to expose it to the user
> (which can even disable them later). This is the problem I this patch
> addresses (exposing them easily).

I wonder if these entries could be exposed via sysfs? You could create
the same directory structure as you have in configfs for the user
created devices, so the only thing user space has to do is to point at a
different directory.


Best regards,
Andreas Hindborg

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Matthew Wood]

Hi Breno and Andreas,

I'm in favor of this RFC as I think the current flow of needing to
create the cmdline0 dir in the netconsole configfs (when DYNAMIC config
is enabled) prior to modifying the values is not ideal.

I think there are good points shared about sysfs vs. configfs being used
for the cmdline target modification and wanted to add my thoughts.

On Fri, Dec 05, 2025 at 08:29:04PM +0100, Andreas Hindborg wrote:
> "Breno Leitao" <leitao@debian.org> writes:
> 
> > Hello Andreas,
> >
> > On Fri, Dec 05, 2025 at 06:35:12PM +0100, Andreas Hindborg wrote:
> >> "Breno Leitao" <leitao@debian.org> writes:
> >>
> >> > This series introduces a new kernel-space item registration API for configfs
> >> > to enable subsystems to programmatically create configfs items whose lifecycle
> >> > is controlled by the kernel rather than userspace.
> >> >
> >> > Currently, configfs items can only be created via userspace mkdir operations,
> >> > which limits their utility for kernel-driven configuration scenarios such as
> >> > boot parameters or hardware auto-detection.
> >>
> >> I thought sysfs would handle this kind of scenarios?
> >
> > sysfs has gaps as well, to manage user-create items.
> >
> > Netconsole has two types of "targets". Those created dynamically
> > (CONFIG_NETCONSOLE_DYNAMIC), where user can create and remove as many
> > targets as it needs, and netconsole would send to it. This fits very
> > well in configfs.
> >
> >   mkdir /sys/kernel/config/netconsole/mytarget
> >   .. manage the target using configfs items/files
> >   rmdir /sys/kernel/config/netconsole/mytarget
> >
> > This is a perfect fit for configfs, and I don't see how it would work
> > with sysfs.
> 
> Right, these go in configfs, we are on the same page about that.
> 
> >
> > On top of that, there are netconsole targets that are coming from
> > cmdline (basically to cover while userspace is not initialized). These
> > are coming from cmdline and its life-cycle is managed by the kernel.
> > I.e, the kernel knows about them, and wants to expose it to the user
> > (which can even disable them later). This is the problem I this patch
> > addresses (exposing them easily).
> 
> I wonder if these entries could be exposed via sysfs? You could create
> the same directory structure as you have in configfs for the user
> created devices, so the only thing user space has to do is to point at a
> different directory.
> 
Although technically feasible, this approach leads to an inconsistent
and confusing management of the netconsole targets. A configfs path for
user-space created targets and a sysfs path for the cmdline initiated
target that can also be modified from userspace (e.g. to update
remote_ip or userdata fields).

I think Breno's approach sets up for the most intuitive user experience.
The cmdline config for netconsole is also user-provided, so it seems
like it should behave as a pre-populated configfs target that happens to
pass from cmdline through netconsole module init to the current configfs
interface. The initial values are not determined by the kernel itself.

> 
> Best regards,
> Andreas Hindborg
> 
> 
> 

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Andreas Hindborg]

"Matthew Wood" <thepacketgeek@gmail.com> writes:

> Hi Breno and Andreas,
>
> I'm in favor of this RFC as I think the current flow of needing to
> create the cmdline0 dir in the netconsole configfs (when DYNAMIC config
> is enabled) prior to modifying the values is not ideal.
>
> I think there are good points shared about sysfs vs. configfs being used
> for the cmdline target modification and wanted to add my thoughts.

Thanks, I appreciate it.

>
> On Fri, Dec 05, 2025 at 08:29:04PM +0100, Andreas Hindborg wrote:
>> "Breno Leitao" <leitao@debian.org> writes:
>>
>> > Hello Andreas,
>> >
>> > On Fri, Dec 05, 2025 at 06:35:12PM +0100, Andreas Hindborg wrote:
>> >> "Breno Leitao" <leitao@debian.org> writes:
>> >>
>> >> > This series introduces a new kernel-space item registration API for configfs
>> >> > to enable subsystems to programmatically create configfs items whose lifecycle
>> >> > is controlled by the kernel rather than userspace.
>> >> >
>> >> > Currently, configfs items can only be created via userspace mkdir operations,
>> >> > which limits their utility for kernel-driven configuration scenarios such as
>> >> > boot parameters or hardware auto-detection.
>> >>
>> >> I thought sysfs would handle this kind of scenarios?
>> >
>> > sysfs has gaps as well, to manage user-create items.
>> >
>> > Netconsole has two types of "targets". Those created dynamically
>> > (CONFIG_NETCONSOLE_DYNAMIC), where user can create and remove as many
>> > targets as it needs, and netconsole would send to it. This fits very
>> > well in configfs.
>> >
>> >   mkdir /sys/kernel/config/netconsole/mytarget
>> >   .. manage the target using configfs items/files
>> >   rmdir /sys/kernel/config/netconsole/mytarget
>> >
>> > This is a perfect fit for configfs, and I don't see how it would work
>> > with sysfs.
>>
>> Right, these go in configfs, we are on the same page about that.
>>
>> >
>> > On top of that, there are netconsole targets that are coming from
>> > cmdline (basically to cover while userspace is not initialized). These
>> > are coming from cmdline and its life-cycle is managed by the kernel.
>> > I.e, the kernel knows about them, and wants to expose it to the user
>> > (which can even disable them later). This is the problem I this patch
>> > addresses (exposing them easily).
>>
>> I wonder if these entries could be exposed via sysfs? You could create
>> the same directory structure as you have in configfs for the user
>> created devices, so the only thing user space has to do is to point at a
>> different directory.
>>
> Although technically feasible, this approach leads to an inconsistent
> and confusing management of the netconsole targets. A configfs path for
> user-space created targets and a sysfs path for the cmdline initiated
> target that can also be modified from userspace (e.g. to update
> remote_ip or userdata fields).
>
> I think Breno's approach sets up for the most intuitive user experience.
> The cmdline config for netconsole is also user-provided, so it seems
> like it should behave as a pre-populated configfs target that happens to
> pass from cmdline through netconsole module init to the current configfs
> interface. The initial values are not determined by the kernel itself.

How about using default groups for this, would that not be feasible?

While I understand the use case for this patch, I don't think it is a
good solution. It changes the fundamental assumptions of configfs. So if
we are going to go down this route I would like more people to review
the patches and weigh in with their opinion.

Perhaps we should discuss this at a venue where we can get some more
people together? LPC or LSF maybe?


Best regards,
Andreas Hindborg

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Breno Leitao]

On Mon, Feb 09, 2026 at 11:58:22AM +0100, Andreas Hindborg wrote:
> Perhaps we should discuss this at a venue where we can get some more
> people together? LPC or LSF maybe?

Certainly, I agree. I’ve submitted my subscription to LSFMMBPF with the main
goal to discuss this topic. I wasn’t planning to present it this, given it was
a "overkill"?, but I’m happy to do so if that is the right direction.

Thanks
--breno

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Joel Becker]

On Mon, Feb 09, 2026 at 05:56:34AM -0800, Breno Leitao wrote:
> On Mon, Feb 09, 2026 at 11:58:22AM +0100, Andreas Hindborg wrote:
> > Perhaps we should discuss this at a venue where we can get some more
> > people together? LPC or LSF maybe?
> 
> Certainly, I agree. I’ve submitted my subscription to LSFMMBPF with the main
> goal to discuss this topic. I wasn’t planning to present it this, given it was
> a "overkill"?, but I’m happy to do so if that is the right direction.

Sadly, I won't be able to make LSF or similar.  I do have strong
opinions on this (you can find previous threads where Breno and I
discussed the topic).

I think the usability issue is real.  It's worth talking about how to
close the experience gap.  But like Andreas, I also have a strong
concern about changing the fundamental paradigm of configfs.  Open it up
to solve this one "can't do it any other way" case, and watch all the
"we can do it with userspace, but it's simpler to just code it with this
kernel hook" followers appear.

Since the problem is entirely about pre-userspace timing, perhaps that's
where we can focus?  Could this be done in initfs?  I suspect for
netconsole that initfs is too late; command line arguments are
necessary.  What about, rather than create a generic "kernelspace API
for configfs item creation" could we just write a "command line
arguments that represent what a userspace mkdir would do" hook?  This
could be private to configfs, and maybe even limited to when in the
kernel startup it can be used.

I can imagine a netconsole argument like:

  linux netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2

could become a general form like:

  linux configfs=netconsole/newtarget:local_port=4444&local_ip=10.0.0.1&dev_name=eth1&remote_port=9353&remote_ip=10.0.0.2

A legacy driver like netconsole could even take its legacy string and
convert it to the configfs form and pass it along, as long as its within
the module_init/boot scope.

Just a thought.  I haven't evaluated the practicalities.

-- 

"War doesn't determine who's right; war determines who's left."

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

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Andreas Hindborg]

Breno Leitao <leitao@debian.org> writes:

> On Mon, Feb 09, 2026 at 11:58:22AM +0100, Andreas Hindborg wrote:
>> Perhaps we should discuss this at a venue where we can get some more
>> people together? LPC or LSF maybe?
>
> Certainly, I agree. I’ve submitted my subscription to LSFMMBPF with the main
> goal to discuss this topic. I wasn’t planning to present it this, given it was
> a "overkill"?, but I’m happy to do so if that is the right direction.

I'd appreciate if we can get some people in a room and force them to
think about this. I think it is a good idea if you submit a topic. If we
don't get a slot, we can see what we can do in the hallway, and if that
does not work out we are forced to make a decision between the 4 of us
participating on list. At least nobody can say we did not try to collect
input and opinions then.


Best regards,
Andreas Hindborg

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Breno Leitao]

On Wed, Feb 11, 2026 at 08:53:12AM +0100, Andreas Hindborg wrote:
> Breno Leitao <leitao@debian.org> writes:
> 
> > On Mon, Feb 09, 2026 at 11:58:22AM +0100, Andreas Hindborg wrote:
> >> Perhaps we should discuss this at a venue where we can get some more
> >> people together? LPC or LSF maybe?
> >
> > Certainly, I agree. I’ve submitted my subscription to LSFMMBPF with the main
> > goal to discuss this topic. I wasn’t planning to present it this, given it was
> > a "overkill"?, but I’m happy to do so if that is the right direction.
> 
> I'd appreciate if we can get some people in a room and force them to
> think about this. I think it is a good idea if you submit a topic. If we
> don't get a slot, we can see what we can do in the hallway, and if that
> does not work out we are forced to make a decision between the 4 of us
> participating on list. At least nobody can say we did not try to collect
> input and opinions then.

That is an excellent follow-up and direction, let me submit a topic in there.

--breno

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Andreas Hindborg]

Hi Breno,

Breno Leitao <leitao@debian.org> writes:

> On Wed, Feb 11, 2026 at 08:53:12AM +0100, Andreas Hindborg wrote:
>> Breno Leitao <leitao@debian.org> writes:
>> 
>> > On Mon, Feb 09, 2026 at 11:58:22AM +0100, Andreas Hindborg wrote:
>> >> Perhaps we should discuss this at a venue where we can get some more
>> >> people together? LPC or LSF maybe?
>> >
>> > Certainly, I agree. I’ve submitted my subscription to LSFMMBPF with the main
>> > goal to discuss this topic. I wasn’t planning to present it this, given it was
>> > a "overkill"?, but I’m happy to do so if that is the right direction.
>> 
>> I'd appreciate if we can get some people in a room and force them to
>> think about this. I think it is a good idea if you submit a topic. If we
>> don't get a slot, we can see what we can do in the hallway, and if that
>> does not work out we are forced to make a decision between the 4 of us
>> participating on list. At least nobody can say we did not try to collect
>> input and opinions then.
>
> That is an excellent follow-up and direction, let me submit a topic in there.

I did not see a topic on list, did you submit?

At any rate, I did not receive an invitation for LSF this year, so I
will not be able to meet up in that venue.


Best regards,
Andreas Hindborg

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Breno Leitao]

Hello Andreas,

On Fri, Mar 20, 2026 at 12:29:58PM +0100, Andreas Hindborg wrote:
>
> Hi Breno,
>
> Breno Leitao <leitao@debian.org> writes:
>
> > On Wed, Feb 11, 2026 at 08:53:12AM +0100, Andreas Hindborg wrote:
> >> Breno Leitao <leitao@debian.org> writes:
> >>
> >> > On Mon, Feb 09, 2026 at 11:58:22AM +0100, Andreas Hindborg wrote:
> >> >> Perhaps we should discuss this at a venue where we can get some more
> >> >> people together? LPC or LSF maybe?
> >> >
> >> > Certainly, I agree. I've submitted my subscription to LSFMMBPF with the main
> >> > goal to discuss this topic. I wasn't planning to present it this, given it was
> >> > a "overkill"?, but I'm happy to do so if that is the right direction.
> >>
> >> I'd appreciate if we can get some people in a room and force them to
> >> think about this. I think it is a good idea if you submit a topic. If we
> >> don't get a slot, we can see what we can do in the hallway, and if that
> >> does not work out we are forced to make a decision between the 4 of us
> >> participating on list. At least nobody can say we did not try to collect
> >> input and opinions then.
> >
> > That is an excellent follow-up and direction, let me submit a topic in there.
>
> I did not see a topic on list, did you submit?

Unfortunately, I haven't submitted a topic and won't be able to attend.
My daughter is due around the same time as the conference, and I didn't
realize the conflict until recently. :-|

> At any rate, I did not receive an invitation for LSF this year, so I
> will not be able to meet up in that venue.

Perhaps it would be best to continue the discussion on the mailing list?