[lttng-dev] [PATCH liburcu] Fix pthread_atfork() behaviour

[Keir Fraser]

Mathieu Desnoyers wrote:
> ----- Original Message -----
>> From: "Keir Fraser"<keir at cohodata.com>
>> To: "Mathieu Desnoyers"<mathieu.desnoyers at efficios.com>
>> Cc: lttng-dev at lists.lttng.org, "Paul E. McKenney"<paulmck at linux.vnet.ibm.com>
>> Sent: Thursday, April 17, 2014 12:15:27 PM
>> Subject: Re: [lttng-dev] [PATCH liburcu] Fix pthread_atfork() behaviour
>>
>> Mathieu Desnoyers wrote:
>>
>> Basically I will have to switch to bp flavour or carry this patch.
>> Actually de-registering and re-registering every thread is really
>> untenable. So I strongly urge to consider giving the callers of this
>> atfork() mechanism a break on this one. ;)
>
> I'm perfectly fine with adding a nicer way to handle pthread atfork in
> RCU flavors besides urcu-bp. I just wanted to share with you the current
> state of what is supported, so we can agree that this would come as a new
> feature into master, and eventually be released in a urcu 0.9. Since it's a
> new feature, there won't be any associated bug entry, nor backports to 0.7
> and 0.8 stable branches.

Okay, that makes sense, thanks.

>> By the way, I also have a valgrind failure on rcu_barrier() due to
>> uninitialised variable/field condition.futex. It gets decremented and
>> passed to futex() syscall, but never actually initialised to zero in the
>> first place. I believe. I haven't yet rolled a patch for that one but
>> I'm sure you don't need one from me anyhow :) However I will send a
>> separate email/patch to the list for this issue very soon unless you
>> tell me that is not necessary.
>
> Urgh, yes. That's a very nice catch!! I'm preparing a fix right away.
> It will be tracked by: http://bugs.lttng.org/issues/787

Worse, while reading the rcu_barrier() code I found a more subtle bug. 
rcu_barrier() can return as soon as completion.barrier_count==0, which 
frees the completion struct along with the rest of its stack frame. But 
its call_rcu callbacks may yet try to read and write completion.futex 
via the wake_up function.

The completion struct should be calloc()ed, reference-counted, and freed 
by the thread that decs the count to 0, imo. I will be cooking up a 
patch to do just that.

There are other places in liburcu which protect a futex variable from 
premature freeing by the waiter polling a teardown flag, but I think 
refcounting is nicer :)

  Regards,
  Keir

> Thanks!
>
> Mathieu
>
>>    Regards,
>>    Keir
>>
>>> Mathieu
>>>
>>>> Thanks,
>>>>
>>>> Mathieu
>>>>
>>>>> Thanks!
>>>>>
>>>>> Mathieu
>>>>>
>>>>>>     Regards,
>>>>>>     Keir Fraser
>>>>>>
>>>>>> _______________________________________________
>>>>>> lttng-dev mailing list
>>>>>> lttng-dev at lists.lttng.org
>>>>>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>>>>>>
>>>>> --
>>>>> Mathieu Desnoyers
>>>>> EfficiOS Inc.
>>>>> http://www.efficios.com
>>>>>
>>>>> _______________________________________________
>>>>> lttng-dev mailing list
>>>>> lttng-dev at lists.lttng.org
>>>>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>>>>>
>>>> --
>>>> Mathieu Desnoyers
>>>> EfficiOS Inc.
>>>> http://www.efficios.com
>>>>
>>>> _______________________________________________
>>>> lttng-dev mailing list
>>>> lttng-dev at lists.lttng.org
>>>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>>>>
>