[lttng-dev] URCU background threads vs signalfd

[Mathieu Desnoyers]

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 ?

Thanks,

Mathieu

> 
> There might be other places, too, I haven't looked too closely...
> 
> Anyways, I'm currently relying on this workaround to ensure
> initial calls to call_rcu and cds_lfht_resize are run with
> signals blocked:
> 
> /* error-checking omitted for brevity */
> __attribute__((constructor)) static void my_ctor(void)
> {
> 	sigset_t set, old;
> 	struct foo_hdr *h;
> 
> 	sigfillset(&set);
> 	pthread_sigmask(SIG_SETMASK, &set, &old);
> 
> 	g_tbl = cds_lfht_new(8192, 1, 0, CDS_LFHT_AUTO_RESIZE, 0);
> 
> 	h = malloc(sizeof(struct foo_hdr)));
> 	if (h) /* force call_rcu to start background thread */
> 		call_rcu(&h->as.dead, free_foo_hdr_rcu);
> 
> 	/* start more background threads before unblocking signals */
> 	cds_lfht_resize(g_tbl, 16384);
> 
> 	pthread_sigmask(SIG_SETMASK, &old, NULL);
> }
> 
> But I suspect it's better to ensure signals are blocked in all
> URCU-created threads...
> 
> Thanks.
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com