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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 52B24ECE58E for ; Thu, 17 Oct 2019 09:21:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2FDAE21835 for ; Thu, 17 Oct 2019 09:21:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2408473AbfJQJV2 (ORCPT ); Thu, 17 Oct 2019 05:21:28 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:52407 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731152AbfJQJV1 (ORCPT ); Thu, 17 Oct 2019 05:21:27 -0400 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iL1xv-0004OU-Aq; Thu, 17 Oct 2019 11:21:03 +0200 Date: Thu, 17 Oct 2019 11:20:56 +0200 (CEST) From: Thomas Gleixner To: Andrei Vagin cc: Vincenzo Frascino , Dmitry Safonov , linux-kernel@vger.kernel.org, Dmitry Safonov <0x7f454c46@gmail.com>, Andrei Vagin , Adrian Reber , Andy Lutomirski , Arnd Bergmann , Christian Brauner , Cyrill Gorcunov , "Eric W. Biederman" , "H. Peter Anvin" , Ingo Molnar , Jann Horn , Jeff Dike , Oleg Nesterov , Pavel Emelyanov , Shuah Khan , containers@lists.linux-foundation.org, criu@openvz.org, linux-api@vger.kernel.org, x86@kernel.org Subject: Re: [PATCHv7 01/33] ns: Introduce Time Namespace In-Reply-To: <20191016233342.GA3075@gmail.com> Message-ID: References: <20191011012341.846266-1-dima@arista.com> <20191011012341.846266-2-dima@arista.com> <80af93da-d497-81de-2a2a-179bb3bc852d@arm.com> <20191016233342.GA3075@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andrei! On Wed, 16 Oct 2019, Andrei Vagin wrote: > On Wed, Oct 16, 2019 at 12:39:11PM +0200, Thomas Gleixner wrote: > > Nah. > > > > config TIME_NS > > bool "TIME namespace" > > depends on GENERIC_VDSO_TIME_NS > > I was thinking to fix this by the same way with a small difference. > > If GENERIC_GETTIMEOFDAY isn't set, it should be safe to allow enabling > TIME_NS. In this case, clock_gettime works via system call and we don't > have arch-specific code in this case. Does this sound reasonable? > > depends on (!GENERIC_GETTIMEOFDAY || GENERIC_VDSO_TIME_NS) No, that's wrong. If GENERIC_GETTIMEOFDAY is not set, then the architecture still might have its own VDSO implementation and we agreed in Vancouver a year ago that we are not going to support per architecture time namespace VDSO implementations. So if at all then you want: depends on HAVE_GENERIC_VDSO && (!GENERIC_GETTIMEOFDAY || GENERIC_VDSO_TIME_NS) But that's crap, really. The reason why HAVE_GENERIC_VDSO and GENERIC_GETTIMEOFDAY exist as separate config items is not a functional issue. It's there to ease the migration to the generic VDSO implementation. Having generic VDSO in production without implementing GENERIC_GETTIMEOFDAY does not make any sense at all. The architectures which implement VDSO are: arm, arm64, mips, nds32, powerpc, riscv, s390, sparc, x86, um arm64, mips, x86 use the generic VDSO. Patches for arm are floating around. UM is special as it just traps into the syscalls. No idea about the rest. Vincenzo might know. The bad news is that we have no information (except on arm which has a config switch for VDSO) whether an architecture provides VDSO support or not. So unless you add something like config HAS_VDSO bool which is selected by all architectures which provide VDSO support, the only sane solution is to depend on GENERIC_VDSO_TIME_NS. TBH, I would not even bother. The architectures which matter and are going to use time namespaces already support VDSO and they need to move to the generic implementation anyway as we discussed and agreed on in Vancouver. Providing time name spaces for the non VDSO archs is a purely academic exercise. Thanks, tglx