[lkml]   [2017]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call
----- On Oct 17, 2017, at 12:41 PM, Ben Maurer 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.


> 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.



Mathieu Desnoyers
EfficiOS Inc.

 \ /
  Last update: 2017-10-17 19:46    [W:0.057 / U:0.272 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site