Linux block layer
 help / color / mirror / Atom feed
From: Kaitao Cheng <kaitao.cheng@linux.dev>
To: "Christian König" <christian.koenig@amd.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>
Cc: "Thierry Reding" <thierry.reding@kernel.org>,
	"Jonathan Hunter" <jonathanh@nvidia.com>,
	"Sowjanya Komatineni" <skomatineni@nvidia.com>,
	"Davidlohr Bueso" <dave@stgolabs.net>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	"Josh Triplett" <josh@joshtriplett.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>, "Will Deacon" <will@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Tvrtko Ursulin" <tursulin@ursulin.net>,
	"Huang Rui" <ray.huang@amd.com>,
	"Eddie James" <eajames@linux.ibm.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Laxman Dewangan" <ldewangan@nvidia.com>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Robert Foss" <rfoss@kernel.org>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Matthew Auld" <matthew.auld@intel.com>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Waiman Long" <longman@redhat.com>,
	drbd-dev@lists.linbit.com, linux-block@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	linux-spi@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-tegra@vger.kernel.org, linux-sound@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Christian Brauner" <brauner@kernel.org>,
	"David Howells" <dhowells@redhat.com>,
	"Luca Ceresoli" <luca.ceresoli@bootlin.com>,
	"Kaito Cheng" <chengkaitao@kylinos.cn>,
	"Muchun Song" <muchun.song@linux.dev>,
	"Philipp Reisner" <philipp.reisner@linbit.com>,
	"Lars Ellenberg" <lars.ellenberg@linbit.com>,
	"Christoph Böhmwalder" <christoph.boehmwalder@linbit.com>,
	"Jens Axboe" <axboe@kernel.dk>,
	"Takashi Sakamoto" <o-takashi@sakamocchi.jp>,
	"Andrzej Hajda" <andrzej.hajda@intel.com>,
	"Jaroslav Kysela" <perex@perex.cz>,
	"Takashi Iwai" <tiwai@suse.com>
Subject: Re: [PATCH v2 00/14] list: Prepare entry iterators to cache cursor state
Date: Wed, 10 Jun 2026 14:14:06 +0800	[thread overview]
Message-ID: <5152089a-2808-4fe9-b633-b03018105dd2@linux.dev> (raw)
In-Reply-To: <bd0b7393-8ccb-4d67-8bfc-18c68347122c@amd.com>

在 2026/6/9 18:33, Christian König 写道:
> On 6/9/26 08:13, Kaitao Cheng wrote:
>> From: Kaito Cheng <chengkaitao@kylinos.cn>
>>
>> This series prepares for, and then updates, the list_for_each_entry()
>> family so the common entry iterators cache their next or previous cursor
>> before the loop body runs.
> 
> Why in the world would we want to do that?
> 
> The safe and non-safe variants have very distinct use cases and that is completely intentional.
> 
> What we could improve maybe is the documentation, from my experience an astonishing large amount of people have misconceptions about the safe variants.
> 
>> The first 13 patches open-code loops that intentionally depend on the
>> old "derive the next entry from the current cursor at the end of the
>> iteration" behaviour.  These loops append work to the list being walked,
>> restart traversal after dropping a lock, skip an entry consumed by the
>> current iteration, or otherwise adjust the cursor in the loop body.
> 
> Well I have to clearly reject the changes for subsystems/components I'm maintaining, that just looks horrible to me and I clearly don't see a good reason for that.

Hi Christian and Andy Shevchenko,

Thanks for taking a look. I would like to clarify the point you raised.

The reason I started looking at this is the original motivation behind
the _safe() variants.  They exist because some users need to remove, move
or otherwise consume the current entry while walking the list.  In that
case the next cursor has to be preserved before the loop body can modify
the current entry.

The unfortunate part is that this could not be expressed with the
existing list_for_each_entry() interface without changing its calling
convention.  The _safe() variants had to grow an extra argument for the
temporary cursor, and that is why we ended up with a separate family of
macros.

But conceptually, the distinction does not have to be exposed as two
different iterator families forever.  The difference is an implementation
detail: whether the iterator keeps the next/previous cursor before the
body runs.  This series makes the common list_for_each_entry() iterators
do that internally, so the safe and non-safe forms can effectively be
folded together, or at least the need for a separate public _safe()
interface becomes much weaker.

There is also a usability issue with the current _safe() interface.  The
caller is forced to define a temporary cursor outside the macro and pass
it in, even though almost all users never use that cursor directly.  It is
just boilerplate required by the macro implementation.  I find that
redundant and awkward: the temporary cursor is an internal detail of the
iteration, but every caller has to spell it out.

With the updated list_for_each_entry() implementation, that extra cursor
can be kept inside the iterator itself.  Callers that only want to walk
the list, including callers that delete or consume the current entry, no
longer need to carry an otherwise-unused temporary variable just to make
the macro work.

>>
>> The final patch changes include/linux/list.h to keep a private cursor in
>> the common entry iterators while preserving the public macro interface.
>> The safe variants remain available when callers need the temporary
>> cursor explicitly or have stronger mutation requirements.
>>
>> Changes in v2 (Muchun Song, Andy Shevchenko):
>>  - Drop the list_for_each_entry_mutable*() helpers from v1 and make the
>>    cursor change directly in the existing list_for_each_entry*() helpers.
>>  - Open-code special list walks that rely on updating the loop cursor in
>>    the body, preserving their existing traversal semantics.
>>
>> Link to v1:
>> https://lore.kernel.org/all/20260529082149.76764-1-kaitao.cheng@linux.dev/
>>
>> Kaitao Cheng (14):
>>   drbd: Open-code transfer log list walk
>>   firewire: core: Open-code topology list walk
>>   drm/bridge: Open-code bridge chain list walks
>>   drm/i915/gt: Open-code active timeline walk
>>   drm/i915: Open-code DFS dependency list walk
>>   drm/ttm: Open-code reservation list walk
>>   spi: fsi: Open-code message transfer walk
>>   spi: stm32-ospi: Open-code message transfer walk
>>   spi: stm32-qspi: Open-code message transfer walk
>>   spi: tegra210-quad: Open-code message transfer walk
>>   locking/locktorture: Open-code ww mutex list walk
>>   locking/ww_mutex: Open-code stress reorder list walk
>>   ASoC: dapm: Open-code widget invalidation walk
>>   list: Cache cursors in entry iterators
>>
>>  drivers/block/drbd/drbd_debugfs.c      |  4 ++-
>>  drivers/firewire/core-topology.c       |  4 ++-
>>  drivers/gpu/drm/drm_bridge.c           |  7 ++--
>>  drivers/gpu/drm/i915/gt/intel_reset.c  |  4 ++-
>>  drivers/gpu/drm/i915/i915_scheduler.c  |  4 ++-
>>  drivers/gpu/drm/ttm/ttm_execbuf_util.c |  4 ++-
>>  drivers/spi/spi-fsi.c                  |  5 ++-
>>  drivers/spi/spi-stm32-ospi.c           |  4 ++-
>>  drivers/spi/spi-stm32-qspi.c           |  5 ++-
>>  drivers/spi/spi-tegra210-quad.c        |  4 ++-
>>  include/linux/list.h                   | 46 ++++++++++++++++++++------
>>  kernel/locking/locktorture.c           |  4 ++-
>>  kernel/locking/test-ww_mutex.c         |  4 ++-
>>  sound/soc/soc-dapm.c                   |  4 ++-
>>  14 files changed, 78 insertions(+), 25 deletions(-)
>>
>> --
>> 2.43.0
>>
> 

-- 
Thanks
Kaitao Cheng


  reply	other threads:[~2026-06-10  6:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-09  6:13 [PATCH v2 00/14] list: Prepare entry iterators to cache cursor state Kaitao Cheng
2026-06-09  6:13 ` [PATCH v2 01/14] drbd: Open-code transfer log list walk Kaitao Cheng
2026-06-09  6:13 ` [PATCH v2 02/14] firewire: core: Open-code topology " Kaitao Cheng
2026-06-09  6:25 ` [PATCH v2 03/14] drm/bridge: Open-code bridge chain list walks Kaitao Cheng
2026-06-09  6:25   ` [PATCH v2 04/14] drm/i915/gt: Open-code active timeline walk Kaitao Cheng
2026-06-09  7:00     ` Andy Shevchenko
2026-06-09  6:25   ` [PATCH v2 05/14] drm/i915: Open-code DFS dependency list walk Kaitao Cheng
2026-06-09  6:25   ` [PATCH v2 06/14] drm/ttm: Open-code reservation " Kaitao Cheng
2026-06-09  6:25   ` [PATCH v2 07/14] spi: fsi: Open-code message transfer walk Kaitao Cheng
2026-06-09  7:02     ` Andy Shevchenko
2026-06-09  6:25   ` [PATCH v2 08/14] spi: stm32-ospi: " Kaitao Cheng
2026-06-09  6:25   ` [PATCH v2 09/14] spi: stm32-qspi: " Kaitao Cheng
2026-06-09  6:38 ` [PATCH v2 10/14] spi: tegra210-quad: " Kaitao Cheng
2026-06-09  6:38   ` [PATCH v2 11/14] locking/locktorture: Open-code ww mutex list walk Kaitao Cheng
2026-06-09  6:38   ` [PATCH v2 12/14] locking/ww_mutex: Open-code stress reorder " Kaitao Cheng
2026-06-09  6:41 ` [PATCH v2 13/14] ASoC: dapm: Open-code widget invalidation walk Kaitao Cheng
2026-06-09  6:41   ` [PATCH v2 14/14] list: Cache cursors in entry iterators Kaitao Cheng
2026-06-09  6:47 ` [PATCH v2 00/14] list: Prepare entry iterators to cache cursor state Andy Shevchenko
2026-06-09  7:05   ` Andy Shevchenko
2026-06-09 10:33 ` Christian König
2026-06-10  6:14   ` Kaitao Cheng [this message]
2026-06-10  8:07     ` Christian König
2026-06-10  8:18       ` Kaitao Cheng
2026-06-10  9:11         ` Christian König
2026-06-10 15:02           ` Andy Shevchenko
2026-06-10 14:43     ` Andy Shevchenko

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=5152089a-2808-4fe9-b633-b03018105dd2@linux.dev \
    --to=kaitao.cheng@linux.dev \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andrzej.hajda@intel.com \
    --cc=axboe@kernel.dk \
    --cc=boqun@kernel.org \
    --cc=brauner@kernel.org \
    --cc=broonie@kernel.org \
    --cc=chengkaitao@kylinos.cn \
    --cc=christian.koenig@amd.com \
    --cc=christoph.boehmwalder@linbit.com \
    --cc=dave@stgolabs.net \
    --cc=dhowells@redhat.com \
    --cc=drbd-dev@lists.linbit.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eajames@linux.ibm.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=jonathanh@nvidia.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=josh@joshtriplett.org \
    --cc=lars.ellenberg@linbit.com \
    --cc=ldewangan@nvidia.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=longman@redhat.com \
    --cc=luca.ceresoli@bootlin.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=mingo@redhat.com \
    --cc=mripard@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=neil.armstrong@linaro.org \
    --cc=o-takashi@sakamocchi.jp \
    --cc=paulmck@kernel.org \
    --cc=perex@perex.cz \
    --cc=peterz@infradead.org \
    --cc=philipp.reisner@linbit.com \
    --cc=ray.huang@amd.com \
    --cc=rdunlap@infradead.org \
    --cc=rfoss@kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=skomatineni@nvidia.com \
    --cc=thierry.reding@kernel.org \
    --cc=tiwai@suse.com \
    --cc=tursulin@ursulin.net \
    --cc=tzimmermann@suse.de \
    --cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox