lttng-dev Archive mirror
 help / color / mirror / Atom feed
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: Eric Wong <normalperson@yhbt.net>
Cc: lttng-dev@lists.lttng.org, paulmck <paulmck@kernel.org>
Subject: Re: [lttng-dev] URCU background threads vs signalfd
Date: Mon, 26 Sep 2022 16:12:45 -0400	[thread overview]
Message-ID: <10d760d3-7622-2b6d-ea98-39534e2a1c8f@efficios.com> (raw)
In-Reply-To: <20220926195829.GA10587@dcvr>

On 2022-09-26 15:58, Eric Wong wrote:
> Mathieu Desnoyers <mathieu.desnoyers@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

      reply	other threads:[~2022-09-26 20:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22  9:15 [lttng-dev] URCU background threads vs signalfd Eric Wong via lttng-dev
2022-09-23 15:57 ` Mathieu Desnoyers via lttng-dev
2022-09-23 17:55   ` Eric Wong via lttng-dev
2022-09-23 18:24     ` Mathieu Desnoyers via lttng-dev
2022-09-23 22:05       ` Eric Wong via lttng-dev
2022-09-26 12:51         ` Mathieu Desnoyers via lttng-dev
2022-09-26 19:58           ` Eric Wong via lttng-dev
2022-09-26 20:12             ` Mathieu Desnoyers via lttng-dev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10d760d3-7622-2b6d-ea98-39534e2a1c8f@efficios.com \
    --to=lttng-dev@lists.lttng.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=normalperson@yhbt.net \
    --cc=paulmck@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).