From: Yichong Chen <chenyichong@uniontech.com>
To: gregkh@linuxfoundation.org
Cc: chenyichong@uniontech.com, dakr@kernel.org, djakov@kernel.org,
driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
quic_mdtipton@quicinc.com, rafael@kernel.org
Subject: Re: [PATCH] debugfs: serialize debugfs_create_str() writers
Date: Mon, 3 Aug 2026 16:34:01 +0800 [thread overview]
Message-ID: <20260803083401.819079-1-chenyichong@uniontech.com> (raw)
In-Reply-To: <2026080345-bucked-debunk-5b57@gregkh>
On Mon, Aug 03, 2026 at 08:19:05AM +0200, Greg KH wrote:
> Ouch, you are doing to serialize _all_ debugfs strings on one lock?
>
> This feels wrong :(
>
> Wait, why rcu if you have a lock?
>
> guard() is nicer.
>
> My larger question is, what code is broken because of this? What
> debugfs string replacements are happening? I hate the string debugfs
> code as it has had lots of issues like this over the years so maybe we
> should just drop it and force users to "roll their own" implementation
> that would be much simpler without the rcu/locking mess at all?
Thanks for the review.
The patch was trying to fix a double-free. Two concurrent writes to the same
debugfs_create_str() file can both observe the same old pointer before
either replacement is published, and then both free that old string. I
reproduced this with KASAN and got:
BUG: KASAN: double-free in debugfs_write_file_str()
I agree with your comments that the current fix is not a good direction. A
global mutex serializes unrelated debugfs string files, and mixing that with
the RCU read side makes the helper more complicated.
The directly writable in-tree users I found are:
drivers/interconnect/debugfs-client.c:
/sys/kernel/debug/interconnect/test_client/src_node, mode 0600
/sys/kernel/debug/interconnect/test_client/dst_node, mode 0600
drivers/soundwire/debugfs.c:
firmware_file, mode 0200
So the write path is reachable through in-tree debugfs users, although I
do not know whether anyone relies on concurrent writes to these files in
practice.
I can rework this in a few ways:
1. make the locking per-file instead of global, if we want to keep the
generic writable string helper;
2. drop the write support from debugfs_create_str() and convert the
writable users to their own small file operations;
3. take another direction if you have a preferred approach.
Dropping write support would avoid keeping this locking in the generic
helper, but debugfs_create_str() is exported, so that would also change
behavior for any out-of-tree users relying on writable strings.
Please let me know which direction you prefer. If none of these options
looks worthwhile for debugfs, I am also fine with dropping this patch.
Thanks,
Yichong
next prev parent reply other threads:[~2026-08-03 8:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 6:09 [PATCH] debugfs: serialize debugfs_create_str() writers Yichong Chen
2026-08-03 6:19 ` Greg KH
2026-08-03 8:34 ` Yichong Chen [this message]
2026-08-03 8:43 ` Greg KH
2026-08-04 5:50 ` Yichong Chen
2026-08-05 8:00 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260803083401.819079-1-chenyichong@uniontech.com \
--to=chenyichong@uniontech.com \
--cc=dakr@kernel.org \
--cc=djakov@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_mdtipton@quicinc.com \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.