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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 BDC93C433DF for ; Wed, 8 Jul 2020 16:36:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A4BF420663 for ; Wed, 8 Jul 2020 16:36:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730481AbgGHQgM (ORCPT ); Wed, 8 Jul 2020 12:36:12 -0400 Received: from albireo.enyo.de ([37.24.231.21]:57546 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730445AbgGHQgM (ORCPT ); Wed, 8 Jul 2020 12:36:12 -0400 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jtD3D-0003zF-QC; Wed, 08 Jul 2020 16:36:03 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jtD3D-0002Vp-NX; Wed, 08 Jul 2020 18:36:03 +0200 From: Florian Weimer To: Christian Brauner Cc: Mathieu Desnoyers , Linus Torvalds , carlos , Thomas Gleixner , linux-kernel , Peter Zijlstra , paulmck , Boqun Feng , "H. Peter Anvin" , Paul Turner , linux-api , Dmitry Vyukov , Neel Natu Subject: Re: [RFC PATCH for 5.8 3/4] rseq: Introduce RSEQ_FLAG_RELIABLE_CPU_ID References: <20200706204913.20347-1-mathieu.desnoyers@efficios.com> <20200706204913.20347-4-mathieu.desnoyers@efficios.com> <87fta3zstr.fsf@mid.deneb.enyo.de> <2088331919.943.1594118895344.JavaMail.zimbra@efficios.com> <874kqjzhkb.fsf@mid.deneb.enyo.de> <378862525.1039.1594123580789.JavaMail.zimbra@efficios.com> <87zh8bw158.fsf@mid.deneb.enyo.de> <1448906726.3717.1594222431276.JavaMail.zimbra@efficios.com> <20200708162247.txdleelcalxkrfjy@wittgenstein> Date: Wed, 08 Jul 2020 18:36:03 +0200 In-Reply-To: <20200708162247.txdleelcalxkrfjy@wittgenstein> (Christian Brauner's message of "Wed, 8 Jul 2020 18:22:47 +0200") Message-ID: <87zh8aufpo.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Christian Brauner: > I've been following this a little bit. The kernel version itself doesn't > really mean anything and the kernel version is imho not at all > interesting to userspace applications. Especially for cross-distro > programs. We can't go around and ask Red Hat, SUSE, Ubuntu, Archlinux, > openSUSE and god knows who what other distro what their fixed kernel > version is. And Red Hat Enterprise Linux only has a dozen or two kernel branches under active maintenance, each with their own succession of version numbers. It's just not feasible. Even figuring out the branch based on the kernel version can be tricky! > (Also, as a side-note. I see that you're passing struct rseq *rseq with > a length argument but you are not versioning by size. Is that > intentional? That basically somewhat locks you to the current struct > rseq layout and means users might run into problems when you extend > struct rseq in the future as they can't pass the new struct down to > older kernels. The way we deal with this is now - rseq might preceed > this - is copy_struct_from_user() The kernel retains the pointer after the system call returns. Basically, ownership of the memory area is transferred to the kernel. It's like set_robust_list in this regard.