[PATCH v7] linux: Add support for getrandom vDSO

[Adhemerval Zanella Netto]

On 27/09/24 11:57, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 26/09/24 14:22, Adhemerval Zanella Netto wrote:
>>
>>>
>>>>
>>>>> +      /* Atomically replace the old state, so if a fork happens the child
>>>>> +	 process will see a consistent free state buffer.  The size might
>>>>> +	 not be updated, but it does not really matter since the buffer is
>>>>> +	 always increased.  */
>>>>> +      atomic_store_relaxed (&grnd_alloc.states, states);
>>>>
>>>> The comment is good, but I think it means you should use release MO
>>>> here.
>>>
>>> Ack, I was not really sure about it but it make sense (the NPTL stack
>>> cache is not clear about the memory semantic it uses for fork synchronization).
>>
>> So Jason pointed out that release does not make much sense without pairing
>> all other 'states' access to acquire memory semantic.  The 'state' is really
>> change only with the lock taken (the thread release only change an index).
>> So I am not sure about this change.
> 
> Doesn't fork do the equivalent of an acquire load?
> > We need some sort of barrier so that the allocated size is at least as
> large as the specified size.  Without the barrier, even the compiler can
> reorder the pointer update and the capacity field update.

I am not sure which memory ordering fork() guarantee, however nptl-stack.c
uses atomic_write_barrier() for every write on the global list:

static inline void
list_add (list_t *newp, list_t *head)
{
  newp->next = head->next;
  newp->prev = head;
  head->next->prev = newp;
  atomic_write_barrier ();
  head->next = newp;
}

void
__nptl_stack_list_add (list_t *elem, list_t *list)
{
  GL (dl_in_flight_stack) = (uintptr_t) elem | 1;

  atomic_write_barrier ();

  list_add (elem, list);

  atomic_write_barrier ();

  GL (dl_in_flight_stack) = 0;
}

Maybe we should do the same here.