[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c1064e76-70f8-4a5f-2624-95a1e2dc9d64@efficios.com>
Date: Tue, 30 May 2023 11:13:41 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Florian Weimer <fweimer@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
"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>,
André Almeida <andrealmeid@...lia.com>,
libc-alpha@...rceware.org, Steven Rostedt <rostedt@...dmis.org>,
Jonathan Corbet <corbet@....net>,
Noah Goldstein <goldstein.w.n@...il.com>, longman@...hat.com,
Olivier Dion <odion@...icios.com>
Subject: Re: [RFC PATCH v2 1/4] rseq: Add sched_state field to struct rseq
On 5/30/23 10:25, Mathieu Desnoyers wrote:
> On 5/30/23 04:20, Florian Weimer wrote:
[...]
>>
>> The challenge is that once we put stuff at fixed offsets, we can't
>> transparently fix it later. It would need more auxv entries with
>> further offsets, or accessing this data through some indirection,
>> perhaps via vDSO helpers.
>
> Perhaps this is more flexibility/complexity than we really need. One
> possible approach would be to split struct rseq into sub-structures, e.g.:
>
> rseq_len = overall size of all sub-structures.
> auxv AT_RSEQ_ALIGN = 256
>
> auxv AT_RSEQ_FEATURE_SIZE = size of first portion of struct rseq,
> at most 256 bytes, meant to contain fields
> stored/loaded from the thread doing the
> registration.
> auxv AT_RSEQ_SHARED_FEATURE_SIZE =
> size of 2nd portion of struct rseq,
> starts at offset 256, at most 256 bytes,
> meant to contain fields stored/loaded by
> any thread.
>
> Then we have this layout:
>
> struct rseq {
> struct rseq_local {
> /* Fields accessed from local thread. */
>
> } __attribute__((aligned((256));
> struct rseq_shared {
> /* Shared fields. */
>
> } __attribute__((aligned(256));
> } __attribute__((aligned(256));
>
> And if someday AT_RSEQ_FEATURE_SIZE needs to grow over 256 bytes
> (32 * u64), we can still extend with a new auxv entry after the "shared"
> features.
Actually, after giving it some more thoughts, I think we can do better:
- Add a sys_rseq() rseq_flag RSEQ_FLAG_SHARED, which changes the
behavior of sys_rseq() to expect an additional "struct rseq_shared *"
argument.
- Introduce auxv AT_RSEQ_SHARED_FEATURE_SIZE.
This way, it's up to the libc to decide how to allocate its private vs
shared rseq structures.
The auxv "AT_RSEQ_ALIGN" would dictate the minimal alignment required
for both private and shared rseq structures.
I don't think we need to express the size of the rseq_shared memory area
allocated by libc because we know that it needs to be large enough to
handle the shared feature size.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
Powered by blists - more mailing lists