All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
Cc: linux-rt-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] locking/ww_mutex/test: Time an ABBA with both owners running
Date: Sat, 07 Nov 2026 00:11:45 +0000	[thread overview]
Message-ID: <sashiko-outbox-202413@kernel.org> (raw)
In-Reply-To: <20261106235931.1478800-6-mathieu.desnoyers@efficios.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] locking/ww_mutex/test: missing stage ordering in
  test_abba_spin()
--

commit a75841edff4ce8ecc91baad12d6e7f770d7d72f7
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

locking/ww_mutex/test: Time an ABBA with both owners running

This commit adds a wound-wait test case to test-ww_mutex where two
SCHED_FIFO threads on separate CPUs create an ABBA contention while both
owners remain running.

> diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
> index 838d631544ed2..1bf3a91adfec5 100644
> --- a/kernel/locking/test-ww_mutex.c
> +++ b/kernel/locking/test-ww_mutex.c
[ ... ]
> @@ -279,6 +281,213 @@ static int test_abba(struct ww_class *class, bool trylock, bool resolve)
>  	return ret;
>  }
>  
[ ... ]
> +static bool abba_spin_until(struct test_abba_spin *s, int stage)
> +{
> +	u64 end = ktime_get_ns() + 5ULL * NSEC_PER_SEC;
> +
> +	while (atomic_read(&s->stage) < stage) {
> +		if (ktime_get_ns() > end)
> +			return false;
> +		cpu_relax();
> +	}
> +	return true;
> +}
[ ... ]
> +static int abba_spin_old(void *arg)
> +{
> +	struct test_abba_spin *s = arg;
> +	struct ww_acquire_ctx ctx;
> +	u64 t, end;
> +	int err = -ETIMEDOUT;
> +
> +	sched_set_fifo_low(current);
> +	wait_for_completion(&s->start);
> +	ww_acquire_init_noinject(&ctx, s->class);
> +	atomic_set(&s->stage, 1);
[ ... ]
> +static int abba_spin_young(void *arg)
> +{
> +	struct test_abba_spin *s = arg;
> +	struct ww_acquire_ctx ctx;
> +	int err = -ETIMEDOUT;
> +
> +	sched_set_fifo_low(current);
> +	wait_for_completion(&s->start);
> +	if (!abba_spin_until(s, 1))
> +		goto out;
> +	ww_acquire_init_noinject(&ctx, s->class);

[Severity: Low]
Can abba_spin_young() obtain a smaller ctx.stamp than abba_spin_old() on
weakly-ordered architectures?

ww_acquire_init() allocates ctx->stamp with
atomic_long_inc_return_relaxed(&ww_class->stamp), and s->stage is updated
and polled with relaxed atomic_set() and atomic_read():

CPU0 (abba_spin_old)              CPU1 (abba_spin_young)
ww_acquire_init_noinject()
  atomic_long_inc_return_relaxed(&s->class->stamp) [reordered]
atomic_set(&s->stage, 1)
                                  abba_spin_until(s, 1)
                                    atomic_read(&s->stage) == 1
                                  ww_acquire_init_noinject()
                                    atomic_long_inc_return_relaxed(...)
  [stamp increment executes here]  <-- young gets the older stamp

If abba_spin_young() receives the smaller stamp, it wounds
abba_spin_old() when blocking on s->a_mutex, causing abba_spin_old()'s
ww_mutex_lock(&s->b_mutex, &ctx) to fail with -EDEADLK.  Using
atomic_set_release() and atomic_read_acquire() on s->stage would order
the stamp allocations.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106235931.1478800-1-mathieu.desnoyers@efficios.com?part=5

  reply	other threads:[~2026-11-07  0:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 23:59 [PATCH 0/5] locking/rtmutex: priority inheritance fixes and tests Mathieu Desnoyers
2026-11-06 23:59 ` [PATCH 1/5] locking/rtmutex: Stop spinning on the owner when the waiter is woken Mathieu Desnoyers
2026-11-07  5:29   ` Steven Rostedt
2026-11-07 10:43     ` Peter Zijlstra
2026-11-07 12:29       ` Mathieu Desnoyers
2026-11-07 17:36         ` Steven Rostedt
2026-11-07 19:34           ` Mathieu Desnoyers
2026-11-07 22:18             ` Steven Rostedt
2026-11-08 13:23               ` Mathieu Desnoyers
2026-11-06 23:59 ` [PATCH 2/5] locking/rtmutex: Initialize the ww_mutex context of a waiter Mathieu Desnoyers
2026-11-06 23:59 ` [PATCH 3/5] locking/rtmutex: Clone a waiter's sort keys as it enters pi_waiters Mathieu Desnoyers
2026-11-07 10:57   ` Peter Zijlstra
2026-11-07 14:19     ` Mathieu Desnoyers
2026-11-06 23:59 ` [PATCH 4/5] selftests/futex: Test priority inheritance on PI futexes Mathieu Desnoyers
2026-11-06 23:59 ` [PATCH 5/5] locking/ww_mutex/test: Time an ABBA with both owners running Mathieu Desnoyers
2026-11-07  0:11   ` sashiko-bot [this message]
2026-11-07  0:27     ` Mathieu Desnoyers

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=sashiko-outbox-202413@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.