From: Yichong Chen <chenyichong@uniontech.com>
To: gregkh@linuxfoundation.org
Cc: rafael@kernel.org, dakr@kernel.org, djakov@kernel.org,
quic_mdtipton@quicinc.com, vkoul@kernel.org,
yung-chuan.liao@linux.intel.com, pierre-louis.bossart@linux.dev,
driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, linux-sound@vger.kernel.org,
Yichong Chen <chenyichong@uniontech.com>
Subject: [PATCH v3 0/3] debugfs: make debugfs_create_str() read-only
Date: Fri, 7 Aug 2026 18:00:50 +0800 [thread overview]
Message-ID: <20260807100053.1089834-1-chenyichong@uniontech.com> (raw)
debugfs_create_str() has a generic write implementation that replaces the
backing string. Concurrent writers can race and free the same old string
twice.
Instead of adding more locking to the generic helper, convert the existing
writable in-tree users to local file operations and make
debugfs_create_str() read-only.
Changes since v2:
- Use scoped mutex guards in the interconnect and SoundWire conversions.
- Clarify why GFP_KERNEL is safe in the interconnect conversion after the
RCU read-side critical section is removed.
- Drop the unnecessary firmware_file = NULL assignment in the SoundWire
exit path.
- Use WARN() instead of WARN_ONCE() so each writable debugfs_create_str()
caller can be reported.
Changes since v1:
- Follow Greg's suggestion to avoid adding locking to the generic
debugfs_create_str() write path.
- Convert the existing writable in-tree users to local file operations.
- Make debugfs_create_str() read-only and refuse writable modes.
- Split the change into a 3-patch series.
Yichong Chen (3):
interconnect: debugfs: replace writable string helper
soundwire: debugfs: replace writable string helper
debugfs: make debugfs_create_str() read-only
drivers/interconnect/debugfs-client.c | 81 +++++++++++++++++++++------
drivers/soundwire/debugfs.c | 63 ++++++++++++++++++---
fs/debugfs/file.c | 81 ++++-----------------------
3 files changed, 129 insertions(+), 96 deletions(-)
--
2.51.0
next reply other threads:[~2026-08-07 10:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 10:00 Yichong Chen [this message]
2026-08-07 10:00 ` [PATCH v3 1/3] interconnect: debugfs: replace writable string helper Yichong Chen
2026-08-07 10:00 ` [PATCH v3 2/3] soundwire: " Yichong Chen
2026-08-07 10:00 ` [PATCH v3 3/3] debugfs: make debugfs_create_str() read-only Yichong Chen
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=20260807100053.1089834-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=linux-pm@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=pierre-louis.bossart@linux.dev \
--cc=quic_mdtipton@quicinc.com \
--cc=rafael@kernel.org \
--cc=vkoul@kernel.org \
--cc=yung-chuan.liao@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox