Received-SPF: pass (google.com: domain of linux-kernel+bounces-166332-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: Florian Weimer <fweimer@redhat.com>
To: Christian Brauner <brauner@kernel.org>
Cc: =?utf-8?Q?Andr=C3=A9?= Almeida <andrealmeid@igalia.com>,  Mathieu
 Desnoyers
 <mathieu.desnoyers@efficios.com>,  Peter Zijlstra <peterz@infradead.org>,
  Thomas Gleixner <tglx@linutronix.de>,  linux-kernel@vger.kernel.org,
  "Paul E . McKenney" <paulmck@kernel.org>,  Boqun Feng
 <boqun.feng@gmail.com>,  "H . Peter Anvin" <hpa@zytor.com>,  Paul Turner
 <pjt@google.com>,  linux-api@vger.kernel.org,  David.Laight@aculab.com,
  carlos@redhat.com,  Peter Oskolkov <posk@posk.io>,  Alexander Mikhalitsyn
 <alexander@mihalicyn.com>,  Chris Kennelly <ckennelly@google.com>,  Ingo
 Molnar <mingo@redhat.com>,  Darren Hart <dvhart@infradead.org>,  Davidlohr
 Bueso <dave@stgolabs.net>,  libc-alpha@sourceware.org,  Steven Rostedt
 <rostedt@goodmis.org>,  Jonathan Corbet <corbet@lwn.net>,  Noah Goldstein
 <goldstein.w.n@gmail.com>,  Daniel Colascione <dancol@google.com>,
  longman@redhat.com,  kernel-dev@igalia.com
Subject: Re: [RFC PATCH 0/1] Add FUTEX_SPIN operation
In-Reply-To: <20240502-sporen-pirschen-039688cd9efe@brauner> (Christian
	Brauner's message of "Thu, 2 May 2024 12:14:11 +0200")
References: <20240425204332.221162-1-andrealmeid@igalia.com>
	<20240426-gaumen-zweibeinig-3490b06e86c2@brauner>
	<f052ff72-72c9-4b83-9285-2cd9d52e5f72@igalia.com>
	<20240502-gezeichnet-besonderen-d277879cd669@brauner>
	<8734r0o81v.fsf@oldenburg.str.redhat.com>
	<20240502-sporen-pirschen-039688cd9efe@brauner>
Date: Thu, 02 May 2024 12:39:34 +0200
Message-ID: <871q6kmra1.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

* Christian Brauner:

>> From a glibc perspective, we typically cannot use long-term file
>> descriptors (that are kept open across function calls) because some
>> applications do not expect them, or even close them behind our back.
>
> Yeah, good point. Note, I suggested it as an extension not as a
> replacement for the TID. I still think it would be a useful extension in
> general.

Applications will need a way to determine when it is safe to close the
pidfd, though.  If we automate this in glibc (in the same way we handle
thread stack deallocation for example), I think we are essentially back
to square one, except that pidfd collisions are much more likely than
TID collisions, especially on systems that have adjusted kernel.pid_max.
(File descriptor allocation is designed to maximize collisions, after
all.)

Thanks,
Florian