From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760456AbdJRGWW (ORCPT ); Wed, 18 Oct 2017 02:22:22 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:52682 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759066AbdJRGWU (ORCPT ); Wed, 18 Oct 2017 02:22:20 -0400 Date: Wed, 18 Oct 2017 08:22:26 +0200 From: Greg KH To: Ben Maurer Cc: Mathieu Desnoyers , 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 Subject: Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call Message-ID: <20171018062226.GB18857@kroah.com> References: <20171012230326.19984-1-mathieu.desnoyers@efficios.com> <20171013205418.GM3521@linux.vnet.ibm.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 17, 2017 at 04:19:41PM +0000, Ben Maurer wrote: > Hey, > > > So far the restrictions I see for libraries using this symbol are: > > - They should never be unloaded, > > - They should never be loaded with dlopen RTLD_LOCAL flag. > > We talked a bit about this off-list but I wanted to state publicly > that I think this model works well for our use case. Specifically, > > (1) It reduces complexity by focusing on the common case -- long term > we expect glibc to manage the process of using this feature and > registering/deregistering threads for rseq. Unloading isn't a > challenge in these situations, so why add the complexity for it? You never install a new version of glibc on a running system, and expect everything to keep running successfully? Breaking that would not be good... thanks, greg k-h