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: <98b3dcb0-8b64-45a5-9531-16aeb010c052@igalia.com>
Date: Tue, 8 Oct 2024 12:38:11 -0300
From: André Almeida <andrealmeid@...lia.com>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
 Darren Hart <dvhart@...radead.org>, Davidlohr Bueso <dave@...olabs.net>,
 LKML <linux-kernel@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>,
 linux-rt-users <linux-rt-users@...r.kernel.org>,
 Valentin Schneider <vschneid@...hat.com>, Waiman Long <longman@...hat.com>,
 Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: Futex hash_bucket lock can break isolation and cause priority
 inversion on RT

Hi Juri,

Em 08/10/2024 12:22, Juri Lelli escreveu:

[...]

> Now, of course by making the latency sensitive application tasks use a
> higher priority than anything on housekeeping CPUs we could avoid the
> issue, but the fact that an implicit in-kernel link between otherwise
> unrelated tasks might cause priority inversion is probably not ideal?
> Thus this email.
> 
> Does this report make any sense? If it does, has this issue ever been
> reported and possibly discussed? I guess it’s kind of a corner case, but
> I wonder if anybody has suggestions already on how to possibly try to
> tackle it from a kernel perspective.
> 

That's right, unrelated apps can share the same futex bucket, causing 
those side effects. The bucket is determined by futex_hash() and then 
tasks get the hash bucket lock at futex_q_lock(), and none of those 
functions have awareness of priorities.

There's this work from Thomas that aims to solve corner cases like this, 
by giving apps the option to instead of using the global hash table, to 
have their own allocated wait queue: 
https://lore.kernel.org/lkml/20160402095108.894519835@linutronix.de/

"Collisions on that hash can lead to performance degradation
and on real-time enabled kernels to unbound priority inversions."


> Thanks!
> Juri
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ