Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1471716imj; Fri, 8 Feb 2019 01:58:49 -0800 (PST) X-Google-Smtp-Source: AHgI3IZyLZ/yU+aLhUa9fPTbn5BLSIvB1A7EAL//WF7f/efIdMhSPORzyBdzlZwYgfMdufGW3cOK X-Received: by 2002:a65:64d6:: with SMTP id t22mr19735794pgv.52.1549619929348; Fri, 08 Feb 2019 01:58:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549619929; cv=none; d=google.com; s=arc-20160816; b=rSmpZGoZdZzdOSpjVnuScP7K0HX/CDwlK1Wwpm4Gudwrk6WFMMk5HyroAydVi8OmuQ F7daYfu1WEFM2/zBehqnsBb5V3RpsP57P0A0MXPYhVAoS0IRzRNIuz8mRiKVesYFSHgm 2KoH9fIAkLHzUE7Chq4Jz/fUxyNHh0CQE2oQJOLASlGJoKwn1I3NmKgRXvawfBYIpokp tLUYWsHiGblHYXiNdu9xyzuv9BdjvQcTRa74MWuOeaS9tR0mLIszBgUSgsCA3CISUFj8 GetJaCZwzvmXAfXBItSuwUf3sQnlobAv8sBU01xMiwESCSQVOwVbfTwdnxRo2PusJqVV dK8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=dDvXmHeFpcYS/SXFKBe2GKAHvbyKe1hIPkluJvSN9hU=; b=iPDsJRoDzTcY0F631LWqcnevvC1eDpfnrCscOQzIKjCEsYegqTBUDdQ49UrvfZc24P 2J5IlaEQ0aYivPLcX2Wll9UWSGtkhnwZfY2XRHAkyifd8IuI+b9VrXUKQVMY0I17GJ8/ D4FCynpswcjhpBOE5C3OsYx1fdDIHjdVPh3t0y1Vpi7+kArfoa/lpbLPobVHO1MkivEd CMgtuA1f1tRJQT2N+dGKZ4RSs4HZpubTPnxfiLdmAZ7RNxj0wpdfNUtD7+UZOgAX4y/5 ahvE70TCyCJTDTK4tnG+CO2Ccq9Tvyjg11vLUv9VMambB70hGIQKvx6FUiJw9sKMcCdK w0kQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c10si1799947pga.207.2019.02.08.01.58.33; Fri, 08 Feb 2019 01:58:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727174AbfBHJ6R (ORCPT + 99 others); Fri, 8 Feb 2019 04:58:17 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:43226 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726068AbfBHJ6R (ORCPT ); Fri, 8 Feb 2019 04:58:17 -0500 Received: from p5492e0d8.dip0.t-ipconnect.de ([84.146.224.216] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gs2v0-0006To-Lj; Fri, 08 Feb 2019 10:57:58 +0100 Date: Fri, 8 Feb 2019 10:57:57 +0100 (CET) From: Thomas Gleixner To: Rasmus Villemoes cc: Dmitry Safonov , LKML , Adrian Reber , Andrei Vagin , Andrei Vagin , Andy Lutomirski , Andy Tucker , Arnd Bergmann , Christian Brauner , Cyrill Gorcunov , Dmitry Safonov <0x7f454c46@gmail.com>, "Eric W. Biederman" , "H. Peter Anvin" , Ingo Molnar , Jeff Dike , Oleg Nesterov , Pavel Emelyanov , Shuah Khan , containers@lists.linux-foundation.org, criu@openvz.org, linux-api@vger.kernel.org, x86@kernel.org, Vincenzo Frascino , Will Deacon Subject: Re: [PATCH 16/32] x86/vdso: Generate vdso{,32}-timens.lds In-Reply-To: Message-ID: References: <20190206001107.16488-1-dima@arista.com> <20190206001107.16488-17-dima@arista.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 7 Feb 2019, Rasmus Villemoes wrote: Cc: + Vincenzo, Will > On 06/02/2019 01.10, Dmitry Safonov wrote: > > As it has been discussed on timens RFC, adding a new conditional branch > > `if (inside_time_ns)` on VDSO for all processes is undesirable. > > It will add a penalty for everybody as branch predictor may mispredict > > the jump. Also there are instruction cache lines wasted on cmp/jmp. > > > > Those effects of introducing time namespace are very much unwanted > > having in mind how much work have been spent on micro-optimisation > > vdso code. > > > > Addressing those problems, there are two versions of VDSO's .so: > > for host tasks (without any penalty) and for processes inside of time > > namespace with clk_to_ns() that subtracts offsets from host's time. > > > > Unfortunately, to allow changing VDSO VMA on a running process, > > the entry points to VDSO should have the same offsets (addresses). > > That's needed as i.e. application that calls setns() may have already > > resolved VDSO symbols in GOT/PLT. > > These (14-19, if I'm reading them right) seems to add quite a lot of > complexity and fragility to the build, and other architectures would > probably have to add something similar to their vdso builds. Yes and we really want to avoid that. The VDSO implementations are pointlessly different accross the architectures and there is effort on the way to consolidate them: https://lkml.kernel.org/r/20190115135539.24762-1-vincenzo.frascino@arm.com I talked to Vincenzo earlier this week and he's working on a new version of that. The timens stuff wants to go on top of the consolidation otherwise we end up with another set of pointlessly different and differently broken VDSO variants. Thanks, tglx