Mathieu Desnoyers wrote:
----- Original Message -----
From: "Keir Fraser"<[email protected]>
To: "Mathieu Desnoyers"<[email protected]>
Cc: [email protected], "Paul E. McKenney"<[email protected]>
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
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
_______________________________________________
lttng-dev mailing list
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
