----- On Oct 17, 2017, at 12:41 PM, Ben Maurer bmaurer@xxxxxx wrote: >> I have a use-case for keeping the reference counting in place though. It's >> use of rseq in signal handlers. > > Would this be solved by saying that the rseq api will return an error if you > register and there's already a block registered. In this case the signal > handler would register the rseq abi area just as the non-signal code is trying > to do the same. The non-signal code would see this error code and realize that > its job had been done for it and then go on it's way. Yes, that should work, as long as we return a specific error code, e.g. -EBUSY, to tell the caller that rseq has actually been registered. > > It would be unsafe for signal handler code to *unregister* the area, but I don't > think that's necessary. Right. > > Basically we'd support a refcount of either 0 or 1, but nothing else. Yep, I'll try this out. > > If a signal handler registers the ABI area, how will it ensure the ABI is > cleaned up at thread exit? I can't imagine pthread_key is signal safe. You have a very good point there. This highlights a signal-safety issue I have in liburcu-bp when used by lttng-ust. pthread_setspecific is indeed not listed as being signal-safe: it can perform on-demand memory allocation when a second level array is needed. I'll have to scratch my head a bit to fix this one. Thanks! Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
