From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call Date: Tue, 17 Oct 2017 17:48:04 +0000 (UTC) Message-ID: <1630038054.43152.1508262484464.JavaMail.zimbra@efficios.com> References: <20171012230326.19984-1-mathieu.desnoyers@efficios.com> <135399003.40850.1507930608890.JavaMail.zimbra@efficios.com> <165916d7-2f86-445a-9c84-f6444b5e753b@redhat.com> <20171016164600.GO2482@two.firstfloor.org> <21865534.42661.1508192263844.JavaMail.zimbra@efficios.com> <1292309161.43101.1508258000235.JavaMail.zimbra@efficios.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Ben Maurer Cc: Andi Kleen , carlos , Linus Torvalds , "Paul E. McKenney" , David Goldblatt , Qi Wang , Boqun Feng , Peter Zijlstra , Paul Turner , Andrew Hunter , Andy Lutomirski , Dave Watson , Josh Triplett , Will Deacon , linux-kernel , Thomas Gleixner , Chris Lameter , Ingo Molnar , "H. Peter Anvin" , rostedt , Andrew Morton , Russell List-Id: linux-api@vger.kernel.org ----- On Oct 17, 2017, at 12:41 PM, Ben Maurer bmaurer-b10kYP2dOMg@public.gmane.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759488AbdJQRqD convert rfc822-to-8bit (ORCPT ); Tue, 17 Oct 2017 13:46:03 -0400 Received: from mail.efficios.com ([167.114.142.141]:49532 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753905AbdJQRqB (ORCPT ); Tue, 17 Oct 2017 13:46:01 -0400 Date: Tue, 17 Oct 2017 17:48:04 +0000 (UTC) From: Mathieu Desnoyers To: Ben Maurer Cc: Andi Kleen , carlos , Linus Torvalds , "Paul E. McKenney" , David Goldblatt , Qi Wang , Boqun Feng , Peter Zijlstra , Paul Turner , Andrew Hunter , Andy Lutomirski , Dave Watson , Josh Triplett , Will Deacon , linux-kernel , Thomas Gleixner , Chris Lameter , Ingo Molnar , "H. Peter Anvin" , rostedt , Andrew Morton , Russell King , Catalin Marinas , Michael Kerrisk , Alexander Viro , linux-api Message-ID: <1630038054.43152.1508262484464.JavaMail.zimbra@efficios.com> In-Reply-To: References: <20171012230326.19984-1-mathieu.desnoyers@efficios.com> <135399003.40850.1507930608890.JavaMail.zimbra@efficios.com> <165916d7-2f86-445a-9c84-f6444b5e753b@redhat.com> <20171016164600.GO2482@two.firstfloor.org> <21865534.42661.1508192263844.JavaMail.zimbra@efficios.com> <1292309161.43101.1508258000235.JavaMail.zimbra@efficios.com> Subject: Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [167.114.142.141] X-Mailer: Zimbra 8.7.11_GA_1854 (ZimbraWebClient - FF52 (Linux)/8.7.11_GA_1854) Thread-Topic: Restartable sequences system call Thread-Index: AQHTQ6515cQ6nxXTN0eVL251OZT19KLg7yEAgACF9biAAKY9gIAAKC8AgAADOQCAAAinAIAEWisAgAALlYCAAFytgIABKXRn7qseMsSRVOsR4xUVrj+R Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Oct 17, 2017, at 12:41 PM, Ben Maurer bmaurer@fb.com 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