Re: [PATCH] debugfs: serialize debugfs_create_str() writers

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Aug 04, 2026 at 01:50:56PM +0800, Yichong Chen wrote:
> Hi Greg,
> 
> I tried the direction you suggested and converted the SoundWire
> firmware_file debugfs entry away from debugfs_create_str().
> 
> The draft diff below does two things:
> 
>   1. debugfs_create_str() becomes read-only only.  It drops write
>      permission bits from the requested mode.  If the caller passed only
>      write bits, it creates an owner-readable file instead of a 0000 file.

If the caller passes write bits, the function should fail to create the
file at all, to make it easy to determine what just went wrong :)

>   2. drivers/soundwire/debugfs.c uses debugfs_create_file() with a small
>      local write-only file operation for firmware_file.

Great!

> The SoundWire command path copies firmware_file under a mutex before using
> it for request_firmware(), so a later debugfs write can replace the global
> string without invalidating the name being used by the command.

As this is debugging only, and root only, and loading firmware files
which better only be done by a developer on their own, this should be
fine and not really an issue at all (i.e. if it breaks, they get to keep
the pieces of their broken system...)

> I tested the generic debugfs_create_str() mode handling with a small test
> module:
> 
>   0444 -> 0444, readable, write fails
>   0600 -> 0400, readable, write fails
>   0200 -> 0400, readable, write fails
> 
> I do not have SoundWire hardware in my test VM, so I could only build that
> part.
> 
> Does this match the direction you had in mind?  If so, I can finish the
> conversion for the interconnect writable string users as well and send a
> proper v2.

Sure, but it should be a patch series, first convert the existing write
string usages to local copies, and then change the debugfs code to
refuse to handle writing strings.

thanks,

greg k-h