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

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87qzquuqsx.fsf@t14s.mail-host-address-is-not-set>
Date: Mon, 09 Feb 2026 11:58:22 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: Matthew Wood <thepacketgeek@...il.com>, Breno Leitao <leitao@...ian.org>
Cc: 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, jlbec@...lplan.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 0/2] configfs: enable kernel-space item registration

"Matthew Wood" <thepacketgeek@...il.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@...ian.org> writes:
>>
>> > Hello Andreas,
>> >
>> > On Fri, Dec 05, 2025 at 06:35:12PM +0100, Andreas Hindborg wrote:
>> >> "Breno Leitao" <leitao@...ian.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