On 2022-09-26 15:58, Eric Wong wrote:
Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote:
Do you mind if I fold our 2 patches together with a Co-developed-by tag and
use your Signed-off-by ?
Looks good to me, thanks.
Then the question that will arise is whether this change is sufficiently
self-contained that we can push it to stable branches, or if it's master
branch material only.
It seems self-contained enough and fixes a real problem
encountered in real-world usage, so I think it's suitable for stable.
That's tricky. I try very hard not to introduce any user-observable
regressions in stable branches. I can very well imagine an application
which, for its own peculiar reasons, would expect signals to be
unblocked in call_rcu worker thread callbacks.
On the other hand, those worker threads have always had the behavior of
having signals unblocked so far, therefore an application that wants to
use signalfd() today with those liburcu worker threads already needs to
take some care about how those threads get created.
Therefore, it's not a small self-contained change: it has effects on the
blocked signal masks that are observable from the application call_rcu
callbacks. So far, applications which expect to use signalfd() in a
non-broken way need to ensure they either have the work-around in place
around thread creation, or will need to add a dependency on an upcoming
liburcu version (e.g. 0.14).
For all those reasons, I think it would be a good time to do a liburcu
0.14 release soon, and I don't think backporting this patch makes sense
for stable branches of liburcu.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
