linux-kernel - Re: [RFC v3 1/1] fpga-region: Introduce ConfigFS interface for runtime FPGA configuration

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: <aG4KTuLExZCMw8rC@yilunxu-OptiPlex-7050>
Date: Wed, 9 Jul 2025 14:21:02 +0800
From: Xu Yilun <yilun.xu@...ux.intel.com>
To: "Manne, Nava kishore" <nava.kishore.manne@....com>
Cc: "mdf@...nel.org" <mdf@...nel.org>,
	"hao.wu@...el.com" <hao.wu@...el.com>,
	"yilun.xu@...el.com" <yilun.xu@...el.com>,
	"trix@...hat.com" <trix@...hat.com>,
	"robh@...nel.org" <robh@...nel.org>,
	"saravanak@...gle.com" <saravanak@...gle.com>,
	"linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"git (AMD-Xilinx)" <git@....com>
Subject: Re: [RFC v3 1/1] fpga-region: Introduce ConfigFS interface for
 runtime FPGA configuration

> I’ve implemented the FPGA Region ConfigFS interface with the following hierarchy:
> 
> /configfs
> └── fpga_regions             ← Registered via configfs_register_subsystem()
>       └── region0                ← Added using configfs_add_default_group()
>            └── my_image      ← Created via mkdir from userspace
>                 ├── firmware    ← Write firmware name here
>                 └── config        ← Trigger programming/unloading

Yes this is good to me.

> Observation:
> If configfs is not mounted before configfs_add_default_group() is invoked
> (e.g., when regions are registered early via base DTB), the path
> /configfs/fpga_regions/region0 does not appear in userspace,
> even though it’s properly initialized in the kernel.
> 
> This appears to be due to how default groups function.
> they require the configfs filesystem to be mounted prior to the group
> addition in order to be visible. As a result, the mount order becomes
> a strict dependency, which may affect or break early-boot FPGA flows
> where regions are created before configfs is available.

I don't have answer here. But IIUC you are describing some generic
problem of configfs_add_default_group(). According to configfs.rst,
subsystem is also a config_group so it doesn't make sense to me a
subsystem works but a default subgroup can't. Unless configfs people
have proper justification, your observation is a bug and should try to
fix it.

> 
> Proposal:
> Use configfs_register_subsystem(&region->cfg_subsys) for each FPGA region
> instead of relying on configfs_add_default_group().

This seems a workaround. I don't prefer we give up on it so early...

Thanks,
Yilun

> 
> This approach places each FPGA region directly under /configfs/region0,
> avoiding the timing issues associated with default groups.
> The interface becomes available as soon as configfs is mounted.
> regardless of when the region was registered
> (boot time via base DTB or dynamically via overlays).
> 
> New user hierarchy:
> /configfs
> └── region0              ← Region appears as its own root node
>       └── my_image   ← Created via mkdir from userspace
>            ├── firmware ← Write firmware name here
>            └── config     ← Trigger programming/unloading
> 
> Would like to know if this approach looks good, or if there are better
> suggestions to handle this scenario?
> 
> Regards,
> Navakishore.