All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.