[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240116144632.cDj3SolO@linutronix.de>
Date: Tue, 16 Jan 2024 15:46:32 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Jiri Slaby <jirislaby@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Cc: linux-kernel@...r.kernel.org, boqun.feng@...il.com, bristot@...hat.com,
bsegall@...gle.com, dietmar.eggemann@....com, jstultz@...gle.com,
juri.lelli@...hat.com, longman@...hat.com, mgorman@...e.de,
mingo@...hat.com, rostedt@...dmis.org, swood@...hat.com,
vincent.guittot@...aro.org, vschneid@...hat.com, will@...nel.org
Subject: Re: [PATCH] futex: Avoid reusing outdated pi_state.
On 2024-01-16 14:08:12 [+0100], To Jiri Slaby wrote:
> --- a/kernel/futex/requeue.c
> +++ b/kernel/futex/requeue.c
> @@ -873,7 +873,7 @@ int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
> if (res)
> ret = (res < 0) ? res : 0;
>
> - futex_unqueue_pi(&q);
> + futex_unqueue_pi(&q, true);
This obviously needs the same change as futex_lock_pi() unless it is
okay to avoid the argument and remove it if it hasn't been removed. I
forgot that the requeue path has also signals & timeouts and so is
subject to the same problem.
Assuming we go that direction…
> spin_unlock(q.lock_ptr);
>
> if (ret == -EINTR) {
Sebastian
Powered by blists - more mailing lists