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

[Muchun Song]

> On May 29, 2026, at 16:21, Kaitao Cheng <kaitao.cheng@xxxxxxxxx> wrote:
> 
> From: Kaitao Cheng <chengkaitao@xxxxxxxxxx>
> 
> 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

On the contrary, it might be better to modify list_for_each_entry() itself.
This prevents us from introducing multiple new interfaces, which could be
overwhelming and confusing for new users.

If we do this, almost most callers of list_for_each_entry_safe() can be
replaced by list_for_each_entry(), as the new modification enables it to
properly handle the removal of the current loop cursor. As you'd expect,
this would simplify usage to some extent by eliminating the need to pass
a temporary variable.

> 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.

I used an AI to scan the entire repository, and the results are as follows
(analyzed based on commit e98d21c170b0):

There are 9,925 list_for_each_entry() call sites in total. Among them,
9,919 do not require any adaptation, and only 6 need to be refactored:

    • sound/soc/soc-dapm.c:258
    • drivers/firewire/core-topology.c:275
    • drivers/gpu/drm/i915/i915_scheduler.c:193
    • drivers/gpu/drm/ttm/ttm_execbuf_util.c:89
    • kernel/locking/locktorture.c:647
    • kernel/locking/test-ww_mutex.c:522

As for list_for_each_entry_safe(), there are 4,572 callers. 4,550 of them
can be directly replaced by the new list_for_each_entry(), while 22 cannot
be replaced:

    • drivers/gpio/gpiolib.c:527
    • drivers/gpu/drm/i915/gem/i915_gem_context.c:1437
    • drivers/gpu/drm/i915/gem/i915_gem_object.c:249
    • drivers/gpu/drm/i915/gt/intel_gt_requests.c:143
    • drivers/gpu/drm/i915/gt/intel_timeline.c:423
    • drivers/gpu/drm/i915/i915_perf.c:2715
    • drivers/gpu/drm/i915/pxp/intel_pxp.c:501
    • drivers/gpu/drm/ttm/ttm_execbuf_util.c:90
    • drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7762
    • drivers/net/wireless/marvell/mwifiex/init.c:559
    • drivers/net/wireless/mediatek/mt76/mt7915/mac.c:2195
    • drivers/net/wireless/mediatek/mt76/mt7996/mac.c:3066
    • drivers/scsi/lpfc/lpfc_hbadisc.c:2574
    • drivers/target/iscsi/iscsi_target.c:4693
    • drivers/usb/c67x00/c67x00-sched.c:985
    • drivers/usb/isp1760/isp1760-hcd.c:1060
    • fs/btrfs/extent-tree.c:4666
    • kernel/locking/locktorture.c:647
    • kernel/locking/test-ww_mutex.c:522
    • kernel/rcu/tasks.h:1059
    • mm/page_reporting.c:183
    • mm/shmem.c:1552"

During the AI's retrieval process, I noticed that it writes a script to
perform a simple syntax analysis. This script filters out call sites within
loops that don't involve any modifications to the list being iterated over
(such as add, del, or move). In fact, this already eliminates the vast
majority of call sites. As a result, there are very few instances that
require manual or AI verification, which significantly improves the
reliability of the AI's analysis.

"Of course, the results above are just for reference, and there's no
guarantee that the AI won't miss something. My suggestion is to have the
AI write the script first. Once we human-verify that the script is correct,
we can run it to collect the remaining call sites that need manual review.
After that, the AI can assist us in analyzing those remaining sites to
minimize the risk of introducing new issues.

Muchun
Thanks