From: Florian Weimer <fweimer@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>, Darren Hart <darren@dvhart.com>,
Yi Wang <wang.yi59@zte.com.cn>, Yang Tao <yang.tao172@zte.com.cn>,
Oleg Nesterov <oleg@redhat.com>,
Carlos O'Donell <carlos@redhat.com>,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [patch 00/12] futex: Cure robust/PI futex exit races
Date: Fri, 08 Nov 2019 11:17:16 +0100 [thread overview]
Message-ID: <87o8xm65ar.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1911080912520.27903@nanos.tec.linutronix.de> (Thomas Gleixner's message of "Fri, 8 Nov 2019 10:18:08 +0100 (CET)")
* Thomas Gleixner:
> On Fri, 8 Nov 2019, Florian Weimer wrote:
>> * Florian Weimer:
>> > * Florian Weimer:
>> >> I ran the glibc upstream test suite (which has some robust futex tests)
>> >> against b21be7e942b49168ee15a75cbc49fbfdeb1e6a97 on x86-64, both native
>> >> and 32-bit/i386 compat mode.
>> >>
>> >> compat mode seems broken, nptl/tst-thread-affinity-pthread fails. This
>> >> is probably *not* due to
>> >> <https://bugzilla.kernel.org/show_bug.cgi?id=154011> because the failure
>> >> is non-sporadic, but reliable fails for thread 253:
>> >>
>> >> info: Detected CPU set size (in bits): 225
>> >> info: Maximum test CPU: 255
>> >> error: pthread_create for thread 253 failed: Resource temporarily unavailable
>> >>
>> >> I'm running this on a large box as root, so ulimits etc. do not apply.
>> >>
>> >> I did not see this failure with the x86-64 test.
>> >>
>> >> You should be able to reproduce with (assuming you've got a multilib gcc):
>> >>
>> >> git clone git://sourceware.org/git/glibc.git git
>> >> mkdir build
>> >> cd build
>> >> ../git/configure --prefix=/usr CC="gcc -m32" CXX="g++ -m32" --build=i686-linux
>> >> make -j`nproc`
>> >> make test t=nptl/tst-thread-affinity-pthread
>> >
>> > Sorry, I realized that I didn't actually verify that this is a
>> > regression caused by your patches. Maybe I can do that tomorrow.
>>
>> Confirmed as a regression caused by the patches. Depending on the
>> nature of the bug, you need a machine which has or pretends to have many
>> CPUs (this one has 256 CPUs).
>
> Sure I can do that, but I completely fail to see how that's a
> regression.
>
> Unpatched 5.4-rc6:
>
> FAIL: nptl/tst-thread-affinity-pthread
> original exit status 1
> info: Detected CPU set size (in bits): 225
> info: Maximum test CPU: 255
> error: pthread_create for thread 253 failed: Resource temporarily unavailable
Huh. Reverting your patches (at commit 26bc672134241a080a83b2ab9aa8abede8d30e1c)
fixes the test for me.
> TBH, the futex changes have absolutely nothing to do with that resource
> fail.
I suspect that there are some changes to task exit latency, which
triggers the latent resource management bug.
Thanks,
Florian
next prev parent reply other threads:[~2019-11-08 10:17 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-06 21:55 [patch 00/12] futex: Cure robust/PI futex exit races Thomas Gleixner
2019-11-06 21:55 ` [patch 01/12] futex: Prevent robust futex exit race Thomas Gleixner
2019-11-06 21:55 ` [patch 02/12] futex: Move futex exit handling into futex code Thomas Gleixner
2019-11-07 9:24 ` Peter Zijlstra
2019-11-07 9:38 ` Thomas Gleixner
2019-11-15 18:19 ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2019-11-16 20:53 ` Borislav Petkov
2019-11-20 9:38 ` tip-bot2 for Thomas Gleixner
2019-11-06 21:55 ` [patch 03/12] futex: Replace PF_EXITPIDONE with a state Thomas Gleixner
2019-11-15 18:19 ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2019-11-20 9:38 ` tip-bot2 for Thomas Gleixner
2019-11-06 21:55 ` [patch 04/12] exit/exec: Seperate mm_release() Thomas Gleixner
2019-11-15 18:19 ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2019-11-20 9:38 ` tip-bot2 for Thomas Gleixner
2019-11-06 21:55 ` [patch 05/12] futex: Split futex_mm_release() for exit/exec Thomas Gleixner
2019-11-15 18:19 ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2019-11-20 9:38 ` tip-bot2 for Thomas Gleixner
2019-11-06 21:55 ` [patch 06/12] futex: Set task::futex state to DEAD right after handling futex exit Thomas Gleixner
2019-11-15 18:19 ` [tip: locking/core] futex: Set task::futex_state " tip-bot2 for Thomas Gleixner
2019-11-20 9:38 ` tip-bot2 for Thomas Gleixner
2019-11-06 21:55 ` [patch 07/12] futex: Mark the begin of futex exit explicitly Thomas Gleixner
2019-11-15 18:19 ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2019-11-20 9:38 ` tip-bot2 for Thomas Gleixner
2019-11-06 21:55 ` [patch 08/12] futex: Sanitize exit state handling Thomas Gleixner
2019-11-07 9:38 ` Peter Zijlstra
2019-11-15 18:19 ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2019-11-20 9:38 ` tip-bot2 for Thomas Gleixner
2019-11-06 21:55 ` [patch 09/12] futex: Provide state handling for exec() as well Thomas Gleixner
2019-11-07 9:49 ` Peter Zijlstra
2019-11-07 9:54 ` Thomas Gleixner
2019-11-15 18:19 ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2019-11-20 9:38 ` tip-bot2 for Thomas Gleixner
2019-11-06 21:55 ` [patch 10/12] futex: Add mutex around futex exit Thomas Gleixner
2019-11-15 18:19 ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2019-11-20 9:38 ` tip-bot2 for Thomas Gleixner
2019-11-06 21:55 ` [patch 11/12] futex: Provide distinct return value when owner is exiting Thomas Gleixner
2019-11-15 18:19 ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2019-11-20 9:38 ` tip-bot2 for Thomas Gleixner
2019-11-06 21:55 ` [patch 12/12] futex: Prevent exit livelock Thomas Gleixner
2019-11-15 18:19 ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2019-11-20 9:38 ` tip-bot2 for Thomas Gleixner
2019-11-07 8:29 ` [patch 00/12] futex: Cure robust/PI futex exit races Ingo Molnar
2019-11-07 8:41 ` Ingo Molnar
2019-11-07 9:40 ` Peter Zijlstra
2019-11-07 15:03 ` Oleg Nesterov
2019-11-07 22:29 ` Florian Weimer
2019-11-07 22:40 ` Florian Weimer
2019-11-08 7:38 ` Florian Weimer
2019-11-08 9:18 ` Thomas Gleixner
2019-11-08 10:17 ` Florian Weimer [this message]
2019-11-08 10:37 ` Thomas Gleixner
2019-11-08 11:51 ` Thomas Gleixner
2019-11-11 9:48 ` Florian Weimer
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=87o8xm65ar.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=carlos@redhat.com \
--cc=darren@dvhart.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=wang.yi59@zte.com.cn \
--cc=yang.tao172@zte.com.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).