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;
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
References: <20191106215534.241796846@linutronix.de>
        <87zhh78gnf.fsf@oldenburg2.str.redhat.com>
        <87v9rv8g44.fsf@oldenburg2.str.redhat.com>
        <87o8xm95rt.fsf@oldenburg2.str.redhat.com>
        <alpine.DEB.2.21.1911080912520.27903@nanos.tec.linutronix.de>
        <87o8xm65ar.fsf@oldenburg2.str.redhat.com>
        <alpine.DEB.2.21.1911081136450.26566@nanos.tec.linutronix.de>
        <alpine.DEB.2.21.1911081223110.26566@nanos.tec.linutronix.de>
Date:   Mon, 11 Nov 2019 10:48:53 +0100
In-Reply-To: <alpine.DEB.2.21.1911081223110.26566@nanos.tec.linutronix.de>
        (Thomas Gleixner's message of "Fri, 8 Nov 2019 12:51:53 +0100 (CET)")
Message-ID: <87woc6yc8q.fsf@oldenburg2.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

* Thomas Gleixner:

> pthread_create() returns EAGAIN while the underlying problem is ENOMEM
> which causes this bonkers output:
>
>   error: pthread_create for thread 253 failed: Resource temporarily unava=
ilable
>
> There is nothing temporarily. The process has its address space exhausted=
.

Thanks for analyzing the failure.  I thought we had already covered
that.  I've fixed the test locally and will submit the changes.  The
fixed test passes, as expected.

I expected that we've fixed all such occurrences of per-CPU thread
creation, but apparently not. 8-(

> That test's output is anyway strange:
>
>  info: Detected CPU set size (in bits): 225
>  info: Maximum test CPU: 255
>
> Interesting how it fits 256 CPUs into a cpuset with a size of 225 bits.

That's an unfortunate side effect of how the CPU set allocation works in
userspace.  The allocation uses a size meaured in bits (which are
rounded up, out of necessity), but the kernel interface is byte-based.
The kernel does not not know that some bits are padding, and happily
writes result data there.  So we get bits back for which no space had
been allocated explicitly.

I hesitated to clean this up because the story on the kernel side was
equally mystifying.  getaffinity requires space in the mask for CPUs
that are currently not present and whose affinity bits are not set.  Due
to firmware bugs, this means that we can cross the magic 1024 bits
boundary (corresponding to the 128 byte legacy mask size), and some
applications will refuse to start. 8-( There was considerable
controversy on the kernel side the last time this came up IIRC.

Thanks,
Florian