Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 7 Nov 2019 08:16:59 -0500 (EST)
From:   Jan Stancek <jstancek@redhat.com>
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Darren Hart <dvhart@infradead.org>, longman@redhat.com,
        LKML <linux-kernel@vger.kernel.org>
Message-ID: <524359139.10936023.1573132619485.JavaMail.zimbra@redhat.com>
In-Reply-To: <alpine.DEB.2.21.1911070009040.1869@nanos.tec.linutronix.de>
References: <9179dbc3505e1de99ee36b09b0a12995239d73c3.1573079868.git.jstancek@redhat.com> <alpine.DEB.2.21.1911070009040.1869@nanos.tec.linutronix.de>
Subject: Re: [RFC PATCH] futex: don't retry futex_wait() with stale
 uaddr/val after spurious wakeup
MIME-Version: 1.0
Thread-Topic: futex: don't retry futex_wait() with stale uaddr/val after spurious wakeup
Thread-Index: L7GrCzziNDlfxhA/K3ZluS5Mqhrymw==
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

My apologies for the 'word salad'.

> So you go great length to "fix" the spurious wakeup case, but what happen=
s if
> there is an actual signal?
>=20
> It will return to handle the signal and then run into the exactly same
> situation because it restarts the syscall with the original uaddr1/uval,
> right?

Right, I missed that.

>=20
> That means that the shortcut which was added in commit d58e6576b0de
> ("futex: Handle spurious wake up") is equivalent to the actual signal cas=
e.
>=20
> So the above churn is pretty pointless because it "fixes" not even half o=
f
> the problem and you can't fix the -ERESTARTSYS case at all.
>=20
> IIRC the uaddr1 value is supposed to change on a requeue operation so tha=
t
> a late incoming waiter goes back with -EWOULDBLOCK. And excatly the same
> would happen on the retry.
>=20
> Aside of that you are completely failing to explain in which context you
> observe this problem. Is that failing on libc, some test case or some oth=
er
> maybe experimental code?

It's test case (LTP futex_cmp_requeue01), which keeps uaddr1 value same
across requeue, and then sporadically fails to wake up some child processes=
.

>=20
> If there is an actual use case for keeping the uaddr1 value the same acro=
ss
> a requeue..

It seems both I and test author missed some hint at man page
for FUTEX_CMP_REQUEUE and assumed this was valid use case.

> But let's talk about that once you came up with a proper explanation for
> what you are trying to solve and why you think it's correct.

Thank you for the detailed response.