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  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:   Tue, 5 Mar 2019 22:58:48 +0100
From:   Peter Zijlstra <>
To:     Mathieu Desnoyers <>
Cc:     Thomas Gleixner <>,
        linux-kernel <>,
        linux-api <>,
        "Paul E . McKenney" <>,
        Boqun Feng <>,
        Andy Lutomirski <>,
        Dave Watson <>, Paul Turner <>,
        Andrew Morton <>,
        Russell King <>,
        Ingo Molnar <>,
        "H. Peter Anvin" <>, Andi Kleen <>,
        Chris Lameter <>, Ben Maurer <>,
        rostedt <>,
        Josh Triplett <>,
        Linus Torvalds <>,
        Catalin Marinas <>,
        Will Deacon <>,
        Michael Kerrisk <>,
        Joel Fernandes <>,
        Carlos O'Donell <>,
        Florian Weimer <>
Subject: Re: [PATCH for 5.1 0/3] Restartable Sequences updates for 5.1

On Tue, Mar 05, 2019 at 03:18:35PM -0500, Mathieu Desnoyers wrote:
> * NUMA node ID in TLS
> Having the NUMA node ID available in a TLS variable would allow glibc to
> perform interesting NUMA performance improvements within its locking
> implementation, so I have a patch adding NUMA node ID support to rseq
> as a new rseq system call flag.

Details? There's just not much room in the futex word, and futexes
themselves are not numa aware.

Before all this spectre nonsense; tglx and me were looking at a futex2
syscall that would, among other things, cure this.

> * Adaptative mutex improvements
> I have done a prototype using rseq to implement an adaptative mutex which
> can detect preemption using a rseq critical section. This ensures the
> thread doesn't continue to busy-loop after it returns from preemption, and
> calls sys_futex() instead. This is part of a user-space prototype branch [2],
> and does not require any kernel change.

I'm still not convinced that is actually the right way to go about
things. The kernel heuristic is spin while the _owner_ runs, and we
don't get preempted, obviously.

And the only userspace spinning that makes sense is to cover the cost of
the syscall. Now Obviously PTI wrecked everything, but before that
syscalls were actually plenty fast and you didn't need many cmpxchg
cycles to amortize the syscall itself -- which could then do kernel side
adaptive spinning (when required).

Powered by blists - more mailing lists