All of lore.kernel.org
 help / color / mirror / Atom feed
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


  reply	other threads:[~2019-11-08 10:17 UTC|newest]

Thread overview: 54+ 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-09 23:57   ` kbuild test robot
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 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.