lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 02 May 2024 11:51:56 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Christian Brauner <brauner@...nel.org>
Cc: André Almeida <andrealmeid@...lia.com>,  Mathieu
 Desnoyers
 <mathieu.desnoyers@...icios.com>,  Peter Zijlstra <peterz@...radead.org>,
  Thomas Gleixner <tglx@...utronix.de>,  linux-kernel@...r.kernel.org,
  "Paul E . McKenney" <paulmck@...nel.org>,  Boqun Feng
 <boqun.feng@...il.com>,  "H . Peter Anvin" <hpa@...or.com>,  Paul Turner
 <pjt@...gle.com>,  linux-api@...r.kernel.org,  David.Laight@...lab.com,
  carlos@...hat.com,  Peter Oskolkov <posk@...k.io>,  Alexander Mikhalitsyn
 <alexander@...alicyn.com>,  Chris Kennelly <ckennelly@...gle.com>,  Ingo
 Molnar <mingo@...hat.com>,  Darren Hart <dvhart@...radead.org>,  Davidlohr
 Bueso <dave@...olabs.net>,  libc-alpha@...rceware.org,  Steven Rostedt
 <rostedt@...dmis.org>,  Jonathan Corbet <corbet@....net>,  Noah Goldstein
 <goldstein.w.n@...il.com>,  Daniel Colascione <dancol@...gle.com>,
  longman@...hat.com,  kernel-dev@...lia.com
Subject: Re: [RFC PATCH 0/1] Add FUTEX_SPIN operation

* 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.

>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.

Thanks,
Florian


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ