From: Thomas Gleixner <tglx@kernel.org>
To: Usama Arif <usama.arif@linux.dev>,
lkmm@lists.linux.dev, joelagnelf@nvidia.com,
linux-kernel@vger.kernel.org, marco.crivellari@suse.com,
paulmck@kernel.org, rafael.j.wysocki@intel.com,
rdunlap@infradead.org, riel@surriel.com, sshegde@linux.ibm.com,
ulfh@kernel.org, usama.arif@linux.dev, yury.norov@gmail.com,
rcu@vger.kernel.org
Cc: shakeel.butt@linux.dev, hannes@cmpxchg.org, kernel-team@meta.com
Subject: Re: [PATCH v2] smp: Use release stores for csd_lock_record() state
Date: Fri, 26 Jun 2026 21:25:03 +0200 [thread overview]
Message-ID: <874iiphzow.ffs@fw13> (raw)
In-Reply-To: <20260622163807.4187558-1-usama.arif@linux.dev>
On Mon, Jun 22 2026 at 09:38, Usama Arif wrote:
> __csd_lock_record() publishes per-CPU CSD debug state that is read by
> csd_lock_wait_toolong() on another CPU. The remote side first reads
> cur_csd with smp_load_acquire() and, when non-NULL, may then read the
> matching cur_csd_func and cur_csd_info fields.
That's not how a change log should look like. See
https://docs.kernel.org/process/maintainer-tip.html#changelog
When I use that template of context, problem, solution, then I clearly
have to assume that the above paragraph describes the current state,
which is not the case.
So in the first paragraph you want to explain that the code uses
smp_mb() to protect against foo.
The second paragraph explains the problem, i.e. that smp_mb() is a big
hammer.
The third paragraph explains how this can be replaced and why the
replacement is correct.
prev parent reply other threads:[~2026-06-26 19:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 16:38 [PATCH v2] smp: Use release stores for csd_lock_record() state Usama Arif
2026-06-24 14:15 ` Kunwu Chan
2026-06-24 15:27 ` Usama Arif
2026-06-25 14:42 ` Dmitry Ilvokhin
2026-06-26 16:30 ` Usama Arif
2026-06-26 16:45 ` Dmitry Ilvokhin
2026-06-26 19:20 ` Thomas Gleixner
2026-06-26 19:25 ` Thomas Gleixner [this message]
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=874iiphzow.ffs@fw13 \
--to=tglx@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=joelagnelf@nvidia.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkmm@lists.linux.dev \
--cc=marco.crivellari@suse.com \
--cc=paulmck@kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rcu@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=riel@surriel.com \
--cc=shakeel.butt@linux.dev \
--cc=sshegde@linux.ibm.com \
--cc=ulfh@kernel.org \
--cc=usama.arif@linux.dev \
--cc=yury.norov@gmail.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 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.