From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by sourceware.org (Postfix) with ESMTPS id 47B193858D34 for ; Thu, 2 May 2024 10:14:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 47B193858D34 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 47B193858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2604:1380:40e1:4800::1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714644867; cv=none; b=Q+h+IBxOs0d1KZircDk26Ke+iM0XQIMs47MAN+BRPBRkB7ckF9gEI2X/6t9GJZChMmDkEEJGCa5/8vcJTbdRray+AQRgPEsL91Q1ncFVAUFcqWUhN7ze2UPQciq6JedA8vJvTnsPdnmp4faBP8XlNxyEEk9h/n7fj+2uZFLaxwg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714644867; c=relaxed/simple; bh=5XpWbWIhxFUZI/YCKfXjNwyTyIzy1sdtf9OuMyUXKNY=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=mvucD5HJkaWTfU2AYex72M2hA5KioQDj01uX3Phez2lTzWE6qPB1ixfedLe0qAnLDbkYYtaV3S6kNbM5VTXOVFB3+1baBRA9RIbMrTTx28gSxm2csjRHxTZs49g+p7dWe8tZAuA5BFr1xhJue/eh8JwnUK1BrQ4N7l8askFBi+s= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id ACFAACE12F2; Thu, 2 May 2024 10:14:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 290F8C113CC; Thu, 2 May 2024 10:14:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1714644859; bh=5XpWbWIhxFUZI/YCKfXjNwyTyIzy1sdtf9OuMyUXKNY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mzJP+SvApqEh+wRHM9AtEb1PD89Ml3thOfiV8TuA71LR2uH2KNRxvLPrLflCMUb5b JzNnWDxxRvti2MDR6oB4cVjVmkKSMDpEVKxRSS3gJf5GK8H30ogjUbYmxEQx+OdIGD d5px0xzWddXxYLLDdCY8h3Kw+n1+gaBeoqDRJwrlQ0ZcbGpRHlatNh7nE4Vt4CxjGZ cFbBAGrG3T4z/vlpQhD+gY4lgZ0QAFk3uXdaX9tcg2+OLTRCe2Z1nRTiVGpL1EgCiQ LdwGB9C/74k7Nj/Plgc8kLynok/JPXDAR6cZEt+RgNmZOjUh2KssQytwbuR368qeB3 gQtxGkXg9Bvrg== Date: Thu, 2 May 2024 12:14:11 +0200 From: Christian Brauner To: Florian Weimer Cc: =?utf-8?B?QW5kcsOp?= Almeida , Mathieu Desnoyers , Peter Zijlstra , Thomas Gleixner , linux-kernel@vger.kernel.org, "Paul E . McKenney" , Boqun Feng , "H . Peter Anvin" , Paul Turner , linux-api@vger.kernel.org, David.Laight@aculab.com, carlos@redhat.com, Peter Oskolkov , Alexander Mikhalitsyn , Chris Kennelly , Ingo Molnar , Darren Hart , Davidlohr Bueso , libc-alpha@sourceware.org, Steven Rostedt , Jonathan Corbet , Noah Goldstein , Daniel Colascione , longman@redhat.com, kernel-dev@igalia.com Subject: Re: [RFC PATCH 0/1] Add FUTEX_SPIN operation Message-ID: <20240502-sporen-pirschen-039688cd9efe@brauner> References: <20240425204332.221162-1-andrealmeid@igalia.com> <20240426-gaumen-zweibeinig-3490b06e86c2@brauner> <20240502-gezeichnet-besonderen-d277879cd669@brauner> <8734r0o81v.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8734r0o81v.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, May 02, 2024 at 11:51:56AM +0200, Florian Weimer wrote: > * Christian Brauner: > > > Unless I'm missing something the question here is PID (as in TGID aka > > thread-group leader id gotten via getpid()) vs TID (thread specific id > > gotten via gettid()). You want the thread-specific id as you want to > > interact with the futex state of a specific thread not the thread-group > > leader. > > > > Aside from that TIDs are subject to the same race conditions that PIDs > > are. They are allocated from the same pool (see alloc_pid()). > > For most mutex types (but not robust mutexes), it is undefined in > userspace if a thread exits while it has locked a mutex. Such a usage > condition would ensure that the race doesn't happen, I believe. The argument is a bit shaky imho because the race not being able to happen is predicated on no one being careless enough to exit with a mutex held. That doesn't do anything against someone doing it on purpose. > > 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.