[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fsgryphl.fsf@mid.deneb.enyo.de>
Date: Fri, 16 Sep 2022 23:32:38 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Chris Kennelly <ckennelly@...gle.com>
Cc: libc-coord@...ts.openwall.com, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com>, "carlos@...hat.com"
<carlos@...hat.com>, libc-alpha <libc-alpha@...rceware.org>,
szabolcs.nagy@....com
Subject: Re: Re: RSEQ symbols: __rseq_size, __rseq_flags vs
__rseq_feature_size
* Chris Kennelly:
>> If the kernel does not currently overwrite the padding, glibc can do
>> its own per-thread initialization there to support its malloc
>> implementation (because the padding is undefined today from an
>> application perspective). That is, we would initialize these
>> invisible vCPU IDs the same way we assign arenas today. That would
>> cover this specific malloc use case only, of course.
> If a user program updates to a new kernel before glibc does, would it be
> able to easily take advantage of it?
No, as far as I understand it, there is presently no signaling from
kernel to applications that bypasses the rseq area registration. So
the only thing you could do is to unregister and re-register with a
compatible value. And that is of course quite undefined and assumes
that you can do this early enough during the life-time of each thread.
But if we have the extension handshake, I'll expect us to backport it
quite widely, after some time to verify that it works with CRIU etc.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
