Re: [PATCH v2 11/14] locking/locktorture: Open-code ww mutex list walk

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The WW mutex documentation promotes an idiomatic pattern that relies on `list_for_each_entry()` not caching the next element, which is broken by the upcoming list iterator update.
--

commit 803c4bd20ba4e9475a66f9600c81114e4079f384
Author: Kaitao Cheng <chengkaitao@kylinos.cn>

locking/locktorture: Open-code ww mutex list walk

This commit open-codes the ww mutex list walk in locktorture. It prepares
the code for an upcoming change that makes list_for_each_entry() cache the
next element before entering the loop body, which preserves the existing
dynamic traversal semantics.

> diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> index e618bcf75e2d8..0eb75e9bccaa6 100644
> --- a/kernel/locking/locktorture.c
> +++ b/kernel/locking/locktorture.c
> @@ -644,7 +644,9 @@ __acquires(torture_ww_mutex_2)
>  
>  	ww_acquire_init(ctx, &torture_ww_class);
>  
> -	list_for_each_entry(ll, &list, link) {
> +	for (ll = list_first_entry(&list, typeof(*ll), link);
> +	     !list_entry_is_head(ll, &list, link);
> +	     ll = list_next_entry(ll, link)) {
>  		int err;
>  
>  		err = ww_mutex_lock(ll->lock, ctx);

[Severity: Medium]
Since this patch updates locktorture to avoid regressions in the ww-mutex
list walk under the new list iterator semantics, does
Documentation/locking/ww-mutex-design.rst also need to be updated?

The documentation for "Method 2" explicitly encourages using
list_for_each_entry() for dynamic list reordering:

Documentation/locking/ww-mutex-design.rst:lock_objs() {
...
			/* we lost out in a seqno race, lock and retry.. */
			ww_mutex_lock_slow(&entry->obj->lock, ctx);

			/*
			 * Move buf to head of the list, this will point
			 * buf->next to the first unlocked entry,
			 * restarting the for loop.
			 */
			list_del(&entry->head);
			list_add(&entry->head, list);
...
}

If a developer follows this documented pattern with the new list iterator
semantics, moving the list entry to the head of the list will no longer
restart the loop. Instead, the loop will continue from the cached next
element, skipping over unlocked entries and silently failing to acquire
all required locks. Could leaving this unchanged cause regressions in
drivers that copy this pattern?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609064122.95825-1-kaitao.cheng@linux.dev?part=11