Re: [PATCH 3/5] Linux: Use rseq to accelerate sched_getcpu

[Florian Weimer <fweimer@redhat.com>]

* Szabolcs Nagy:

> The 12/06/2021 14:46, Florian Weimer via Libc-alpha wrote:
>> Co-Authored-By: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> ---
>>  sysdeps/unix/sysv/linux/sched_getcpu.c | 19 +++++++++++++++++--
>>  1 file changed, 17 insertions(+), 2 deletions(-)
>> 
>> diff --git a/sysdeps/unix/sysv/linux/sched_getcpu.c b/sysdeps/unix/sysv/linux/sched_getcpu.c
>> index c41e986f2c..91250f9d0c 100644
>> --- a/sysdeps/unix/sysv/linux/sched_getcpu.c
>> +++ b/sysdeps/unix/sysv/linux/sched_getcpu.c
>> @@ -20,8 +20,8 @@
>>  #include <sysdep.h>
>>  #include <sysdep-vdso.h>
>>  
>> -int
>> -sched_getcpu (void)
>> +static int
>> +vsyscall_sched_getcpu (void)
>>  {
>>    unsigned int cpu;
>>    int r = -1;
>> @@ -32,3 +32,18 @@ sched_getcpu (void)
>>  #endif
>>    return r == -1 ? r : cpu;
>>  }
>> +
>> +#ifdef RSEQ_SIG
>> +int
>> +sched_getcpu (void)
>> +{
>> +  int cpu_id = THREAD_GETMEM (THREAD_SELF, rseq_area.cpu_id);
>> +  return __glibc_likely (cpu_id >= 0) ? cpu_id : vsyscall_sched_getcpu ();
>> +}
>
> i think there is a formal memory model issue here since
> tp->rseq_area.cpu_id can be modified by the kernel asynchronously
> but we don't use volatile or relaxed_mo atomic access.
> (assuming THREAD_GETMEM is defined as a normal access)

The kernel only modifies cpu_id if the user code is not running on the
thread, so I don't think this doesn't matter.

> i think this is fine here (unlikely to cause miscompilation),
> but may be worth a note?

The kernel doesn't use the C memory model, so using that terminology in
the kernel context would only be more confusing.

Thanks,
Florian