From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3EAEC43603 for ; Fri, 20 Dec 2019 20:54:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 764A820866 for ; Fri, 20 Dec 2019 20:54:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="DTA6eZsG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727473AbfLTUyQ (ORCPT ); Fri, 20 Dec 2019 15:54:16 -0500 Received: from mail.efficios.com ([167.114.142.138]:56160 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727402AbfLTUyP (ORCPT ); Fri, 20 Dec 2019 15:54:15 -0500 Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id 292C568FA4B; Fri, 20 Dec 2019 15:54:14 -0500 (EST) Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id Tm2CvV_XYdmJ; Fri, 20 Dec 2019 15:54:13 -0500 (EST) Received: from localhost (ip6-localhost [IPv6:::1]) by mail.efficios.com (Postfix) with ESMTP id 9CBDF68FA48; Fri, 20 Dec 2019 15:54:13 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 9CBDF68FA48 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1576875253; bh=ETinDr1CVgC3p7TD6XfvCrnRXYlKlrPDMZgCwRtUlNY=; h=Date:From:To:Message-ID:MIME-Version; b=DTA6eZsGHQo50solOTM9RLt0dPzlA9oZPFTBIDUKqQqAS8vEK0+x3z6t73nGx0zTB 29b8dC5cze6KjdwqHRIX2PPYzlafNgygFxHSiJz0v0YLXFl9ibwjVHcfCDeXrRqsFG kMT2owxr4HcGwEM4kwJdsAhAFivj8I9G2q3MiUQzogeB9Q8hqLFSAo37y7qQRuhAlO Rvz40HcCzMmV6puNE+82qOJ8dH4/rf/O9fIr0DNKtD43r3XOgzaaFRLiyfcVBbAJoJ szYEPDqayewpCUBMGOn7L/sue4dj0qi24lGSken+3t+TUz/VvJaaDWiqGycKVJWoyW gnPWFGdXG+fPQ== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([IPv6:::1]) by localhost (mail02.efficios.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id 1ww5H04DdUF8; Fri, 20 Dec 2019 15:54:13 -0500 (EST) Received: from mail02.efficios.com (mail02.efficios.com [167.114.142.138]) by mail.efficios.com (Postfix) with ESMTP id 83BF568FA32; Fri, 20 Dec 2019 15:54:13 -0500 (EST) Date: Fri, 20 Dec 2019 15:54:13 -0500 (EST) From: Mathieu Desnoyers To: Florian Weimer Cc: Thomas Gleixner , linux-kernel , Peter Zijlstra , paulmck , Boqun Feng , "H. Peter Anvin" , Paul Turner , linux-api , stable , Dmitry Vyukov , Neel Natu Message-ID: <173832695.14381.1576875253374.JavaMail.zimbra@efficios.com> In-Reply-To: <87imman36g.fsf@mid.deneb.enyo.de> References: <20191220201207.17389-1-mathieu.desnoyers@efficios.com> <87imman36g.fsf@mid.deneb.enyo.de> Subject: Re: [PATCH for 5.5 1/2] rseq: Fix: Clarify rseq.h UAPI rseq_cs memory reclaim requirements MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.142.138] X-Mailer: Zimbra 8.8.15_GA_3888 (ZimbraWebClient - FF71 (Linux)/8.8.15_GA_3890) Thread-Topic: rseq: Fix: Clarify rseq.h UAPI rseq_cs memory reclaim requirements Thread-Index: yDR6ZuRNLoc+9BIlwZu3JhxAJn1lkg== Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org ----- On Dec 20, 2019, at 3:37 PM, Florian Weimer fw@deneb.enyo.de wrote: > * Mathieu Desnoyers: > >> diff --git a/include/uapi/linux/rseq.h b/include/uapi/linux/rseq.h >> index 9a402fdb60e9..6f26b0b148a6 100644 >> --- a/include/uapi/linux/rseq.h >> +++ b/include/uapi/linux/rseq.h >> @@ -100,7 +100,9 @@ struct rseq { >> * instruction sequence block, as well as when the kernel detects that >> * it is preempting or delivering a signal outside of the range >> * targeted by the rseq_cs. Also needs to be set to NULL by user-space >> - * before reclaiming memory that contains the targeted struct rseq_cs. >> + * before reclaiming memory that contains the targeted struct rseq_cs >> + * or reclaiming memory that contains the code refered to by the >> + * start_ip and post_commit_offset fields of struct rseq_cs. > > Maybe mention that it's good practice to clear rseq_cs before > returning from a function that contains a restartable sequence? Unfortunately, clearing it is not free. Considering that rseq is meant to be used in very hot code paths, it would be preferable that applications clear it in the very infrequent case where the rseq_cs or code will vanish (e.g. dlclose or JIT reclaim), and not require it to be cleared after each critical section. I am therefore reluctant to document the behavior you describe as a "good practice" for rseq. > That will deal with the dlclose issue because even if the function > calls dlclose itself, unmapping something on call stack for dlclose is > already undefined. It would, but at the cost of adding an extra NULL store on pretty much every use of rseq (think memory allocator fast-path for instance). Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com