Linux Sound subsystem development
 help / color / mirror / Atom feed
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

             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