From: Florian Weimer <fw@deneb.enyo.de>
To: Rich Felker <dalias@libc.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
linux-man@vger.kernel.org,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Subject: Re: futex_cmpxchg_enabled breakage
Date: Sun, 16 Sep 2018 14:16:25 +0200 [thread overview]
Message-ID: <87fty9hc2u.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <20180829222221.GA22017@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 29 Aug 2018 18:22:21 -0400")
* Rich Felker:
> I just spent a number of hours helping someone track down a bug that
> looks like it's some kind of futex_cmpxchg_enabled detection error on
> powerpc64 (still not sure of the root cause; set_robust_list producing
> -ENOSYS), and a while back I hit the same problem on sh2 due to lack
> of EFAULT on nommu, leading to commit 72cc564f16ca. I think the test
> (introduced way back in commit a0c1e9073ef7) is fundamentally buggy;
> if anything, it should be checking for !=-ENOSYS, not ==-EFAULT.
> Presumably it could also fail to produce -EFAULT if mmap_min_addr is 0
> and page 0 is mapped (a bad idea, but maybe someone does it...). And
> of course other nommu archs are possibly still broken.
Maybe it was related to this (“Kernel 4.15 lost set_robust_list
support on POWER 9”):
<https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-February/168570.html>
The Kconfig change you suggest was explicitly rejected as the fix.
I believe the expected userspace interface is that you probe support
with set_robust_list first, and then start using the relevant futex
interfaces only if that call succeeded. If you do that, most parts of
a typical system will work as expected even if the kernel support is
not there, which is a bit surprising. It definitely makes the root
cause harder to spot.
WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fw@deneb.enyo.de>
To: Rich Felker <dalias@libc.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
linux-man@vger.kernel.org,
"Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>
Subject: Re: futex_cmpxchg_enabled breakage
Date: Sun, 16 Sep 2018 14:16:25 +0200 [thread overview]
Message-ID: <87fty9hc2u.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <20180829222221.GA22017@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 29 Aug 2018 18:22:21 -0400")
* Rich Felker:
> I just spent a number of hours helping someone track down a bug that
> looks like it's some kind of futex_cmpxchg_enabled detection error on
> powerpc64 (still not sure of the root cause; set_robust_list producing
> -ENOSYS), and a while back I hit the same problem on sh2 due to lack
> of EFAULT on nommu, leading to commit 72cc564f16ca. I think the test
> (introduced way back in commit a0c1e9073ef7) is fundamentally buggy;
> if anything, it should be checking for !=-ENOSYS, not ==-EFAULT.
> Presumably it could also fail to produce -EFAULT if mmap_min_addr is 0
> and page 0 is mapped (a bad idea, but maybe someone does it...). And
> of course other nommu archs are possibly still broken.
Maybe it was related to this (“Kernel 4.15 lost set_robust_list
support on POWER 9”):
<https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-February/168570.html>
The Kconfig change you suggest was explicitly rejected as the fix.
I believe the expected userspace interface is that you probe support
with set_robust_list first, and then start using the relevant futex
interfaces only if that call succeeded. If you do that, most parts of
a typical system will work as expected even if the kernel support is
not there, which is a bit surprising. It definitely makes the root
cause harder to spot.
next prev parent reply other threads:[~2018-09-16 12:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-29 22:22 futex_cmpxchg_enabled breakage Rich Felker
2018-08-30 9:19 ` Thomas Gleixner
2018-08-30 13:55 ` Rich Felker
2018-09-15 15:34 ` Thomas Gleixner
2018-09-15 16:15 ` Rich Felker
2018-09-15 16:58 ` Rich Felker
2018-09-15 18:39 ` Thomas Gleixner
2018-08-30 10:39 ` Peter Zijlstra
2018-09-16 12:16 ` Florian Weimer [this message]
2018-09-16 12:16 ` Florian Weimer
2018-09-16 13:16 ` Rich Felker
2018-09-16 13:38 ` Florian Weimer
2018-09-16 13:38 ` Florian Weimer
2018-09-17 16:51 ` Rich Felker
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=87fty9hc2u.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=dalias@libc.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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.