Re: [PATCH] list: Add safe entry iterators without an explicit n cursor

[Andrew Morton]

On Fri, 29 May 2026 16:21:49 +0800 Kaitao Cheng <kaitao.cheng@xxxxxxxxx> wrote:

> The list_for_each_entry_safe*() helpers are useful for loops which may
> remove the current entry, but they require callers to provide a second
> cursor named by convention as n. Some users do not need to inspect or
> reset that cursor; they only need the iterator to keep the next entry
> available while the current entry may be removed.
> 
> Add entry iterators which hide that temporary next cursor while otherwise
> following the traversal pattern of the corresponding
> list_for_each_entry_safe*() helpers.
> 
> Do not fold this behavior into list_for_each_entry(). That iterator
> advances from pos after the loop body, and a few existing callers rely
> on that semantics to observe list changes made during the body. For
> example, stress_reorder_work() in kernel/locking/test-ww_mutex.c moves
> the current entry to the list head with list_move(&ll->link, &locks) and
> documents that this restarts iteration. If list_for_each_entry() cached
> the next entry before running the body, the loop would continue from the
> stale saved next entry instead of honoring the modified list order.

Oh boy, this is a whole bunch of inscrutable macro magic and AI review
(https://sashiko.dev/#/patchset/20260529082149.76764-1-kaitao.cheng@xxxxxxxxx)
is suggesting that it become even moreso.

I suggest that some patches which _use_ these macros would help to
demonstrate the value.  And perhaps use of a clever regexp which tells
us how many sites might benefit.