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 <[email protected]> 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/[email protected]?part=11
