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]
Message-ID: <875xw44fxk.fsf@oldenburg.str.redhat.com>
Date: Fri, 26 Apr 2024 11:43:51 +0200
From: Florian Weimer <fweimer@...hat.com>
To: André Almeida <andrealmeid@...lia.com>
Cc: 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,  "Christian
 Brauner" <brauner@...nel.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

* André Almeida:

> With FUTEX2_SPIN flag set during a futex_wait(), the futex value is
> expected to be the PID of the lock owner. Then, the kernel gets the
> task_struct of the corresponding PID, and checks if it's running. It
> spins until the futex is awaken, the task is scheduled out or if a
> timeout happens.  If the lock owner is scheduled out at any time, then
> the syscall follows the normal path of sleeping as usual.

PID or TID?

I think we'd like to have at least one, possibly more, bits for free
use, so the kernel ID comparison should at least mask off the MSB,
possibly more.

I haven't really thought about the proposed locking protocol, sorry.

Thanks,
Florian


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ