[lttng-dev] URCU background threads vs signalfd

[Eric Wong]

Mathieu Desnoyers <mathieu.desnoyers at efficios.com> wrote:
> On 2022-09-23 13:55, Eric Wong wrote:
> > Mathieu Desnoyers <mathieu.desnoyers at efficios.com> wrote:
> > > On 2022-09-22 05:15, Eric Wong via lttng-dev wrote:
> > > > Hello, I'm using urcu-bp + rculfhash + call_rcu to implement
> > > > malloc instrumentation (via LD_PRELOAD) on an existing
> > > > single-threaded Perl codebase which uses Linux signalfd.
> > > > 
> > > > signalfd depends on signals being blocked in all threads
> > > > of the process, otherwise threads with unblocked signals
> > > > can receive them and starve the signalfd.
> > > > 
> > > > While some threads in URCU do block signals (e.g. workqueue
> > > > worker for rculfhash), the call_rcu thread and rculfhash
> > > > partition_resize_helper threads do not...
> > > > 
> > > > Should all threads URCU creates block signals (aside from SIGRCU)?
> > > 
> > > Yes, I think you are right. The SIGRCU signal is only needed for the
> > > urcu-signal flavor though.
> > > 
> > > Would you like to submit a patch ?
> > 
> > Sure.
> > 
> > Is there a way to detect at runtime when urcu-signal is in use
> > so SIGRCU (SIGUSR1) doesn't get unblocked when using other flavors?
> > 
> > I actually use SIGUSR1 in my signalfd-using codebase.
> > 
> > I also want to remove cds_lfht_worker_init entirely since it's racy.
> > Signal blocking needs to be done in the parent before pthread_create
> > to avoid a window where the child has unblocked signals.
> > 
> > Thanks.  Anyways, this is my work-in-progress:
> > 
> 
> Perhaps with this on top of your wip patch ? The idea is to always block all
> signals before creating threads, and only unblock SIGRCU when registering a
> urcu-signal thread. (compile-tested only)

Thanks, that makes sense.  It passes: make check short_bench

My original signalfd + urcu-bp case works well, too, with my
constructor workarounds reverted. (I ported our patches ported to
to 0.10.2 for Debian buster (oldstable)).

I don't know if the existing test coverage is sufficient,
though.  Waiting on regtest...