Re: [PATCH] debugfs: serialize debugfs_create_str() writers
From: Greg KH
Date: Wed Aug 05 2026 - 04:04:20 EST
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