Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5373932ybv; Mon, 17 Feb 2020 18:40:27 -0800 (PST) X-Google-Smtp-Source: APXvYqxsyRCIogZ3v7WsvpHNo4goeZic3TjLUsg6Qfv9XbnCwSoGPw+PrWM58FlGbRoKxfa/QnuH X-Received: by 2002:aca:5844:: with SMTP id m65mr1298693oib.136.1581993627308; Mon, 17 Feb 2020 18:40:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581993627; cv=none; d=google.com; s=arc-20160816; b=Rdg9apK76s6FmebbYZnZxfFhSmYEIV3NPsoLCJ7N2JnFgFdDQDJzLKCWkLkECag7wE MDK1q4HOrv9G/MDyi9c4sVuniGZQt3SSB3xHBoyay0BpBKSMMr+VK1GPGrWF/Cy/BSAw moOjrRyWQriNuWu5jf6nk6M7gjGFBDanxrPPW9HHip29XlH33Zp/X1/xZaqlquKAMhCU UHQduVhqNwzsDiWCMRwkxQDCLD9S+VT7kqhJNdDi3QXYHyViHnLFmZmua5a3lZJ5Ziwj jP0n8OCIjI4JFAvL1qKTxc+oO1NmMNdb2fvyDO//iudXjGbuQJ/eAuXiqzuokc+2fy+s TH1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from; bh=g7V7rab5Qwhp1sFaEWvpH4vg/Wxi1A3m5yQq2/uDXIw=; b=gy8a/ItYlPS1T4tudzNYX+kAYwQZH0L8jYQy2xSYkZxC+eYudAp0MQDhWIzS0NWSMf fklvrz4IWT8lnqQrQdDDRYstw2UwaTfIuJas2ydsSmb/76kiZwQhYe/iteyXT19IoZ2s ffrJ9b2kPc1XCtdbDVC3GukMfRXThgL0xypDQ25jzUxdLhFuy8ZivgTVxEXr6SHH3Qzc sAhF1Fop7Yo30d6PfTCbZEuyoXD0XiDKkhJOf8L8S42TwgCfvxvWIIM1wQW5kAR4ufQm i2cTpYrE2V+uaztFr+nd6Ma4fpUVh6TuZ8Nptco6eaXba/Ei5LIjDmk91vPEvYpMh79o PF3w== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q6si1261041otg.248.2020.02.17.18.40.14; Mon, 17 Feb 2020 18:40:27 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726261AbgBRCkB (ORCPT + 99 others); Mon, 17 Feb 2020 21:40:01 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:48680 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726171AbgBRCkA (ORCPT ); Mon, 17 Feb 2020 21:40:00 -0500 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1j3snj-0002JE-BO; Mon, 17 Feb 2020 19:39:55 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1j3sni-0005j8-H3; Mon, 17 Feb 2020 19:39:55 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Thomas Gleixner Cc: Christian Brauner , "Michael Kerrisk \(man-pages\)" , Dmitry Safonov , Andrei Vagin , Linux Kernel , Dmitry Safonov <0x7f454c46@gmail.com>, Adrian Reber , Andy Lutomirski , Arnd Bergmann , Cyrill Gorcunov , "H. Peter Anvin" , Ingo Molnar , Jann Horn , Jeff Dike , Oleg Nesterov , Pavel Emelyanov , Shuah Khan , Vincenzo Frascino , containers , criu@openvz.org, Linux API , x86@kernel.org, Andrei Vagin References: <874kvossh4.fsf@nanos.tec.linutronix.de> Date: Mon, 17 Feb 2020 20:37:55 -0600 In-Reply-To: <874kvossh4.fsf@nanos.tec.linutronix.de> (Thomas Gleixner's message of "Tue, 18 Feb 2020 00:29:27 +0100") Message-ID: <87lfp0boxo.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1j3sni-0005j8-H3;;;mid=<87lfp0boxo.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX188tyzk0ONX2b2vqwoFCe9Sq5pQxsGyBLU= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa01.xmission.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG autolearn=disabled version=3.4.2 X-Spam-Virus: No X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4995] * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Thomas Gleixner X-Spam-Relay-Country: X-Spam-Timing: total 327 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.6 (0.8%), b_tie_ro: 1.83 (0.6%), parse: 0.63 (0.2%), extract_message_metadata: 12 (3.8%), get_uri_detail_list: 1.01 (0.3%), tests_pri_-1000: 15 (4.7%), tests_pri_-950: 0.97 (0.3%), tests_pri_-900: 0.83 (0.3%), tests_pri_-90: 23 (7.0%), check_bayes: 22 (6.6%), b_tokenize: 7 (2.0%), b_tok_get_all: 8 (2.5%), b_comp_prob: 1.97 (0.6%), b_tok_touch_all: 3.2 (1.0%), b_finish: 0.62 (0.2%), tests_pri_0: 259 (79.2%), check_dkim_signature: 0.37 (0.1%), check_dkim_adsp: 2.3 (0.7%), poll_dns_idle: 0.79 (0.2%), tests_pri_10: 2.6 (0.8%), tests_pri_500: 7 (2.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: Time Namespaces: CLONE_NEWTIME and clone3()? X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thomas Gleixner writes: > Christian Brauner writes: >> On Mon, Feb 17, 2020 at 10:47:53PM +0100, Michael Kerrisk (man-pages) wrote: >>> Actually, I think the alternative you propose just here is better. I >>> imagine there are times when one will want to create multiple >>> namespaces with a single call to clone3(), including a time namespace. >>> I think this should be allowed by the API. And, otherwise, clone3() >>> becomes something of a second-class citizen for creating namespaces. >>> (I don't really get the "less invasive" argument. Implementing this is >>> just a piece of kernel to code to make user-space's life a bit simpler >>> and more consistent.) >> >> I don't particularly mind either way. If there's actual users that need >> to set it at clone3() time then we can extend it. So I'd like to hear >> what Adrian, Dmitry, and Thomas think since they are well-versed how >> this will be used in the wild. I'm weary of exposing a whole new uapi >> struct and extending clone3() without any real use-case but I'm happy to >> if there is! > > I really have no clue. I merily helped getting this in shape without > creating havoc for timekeeping and VDSO. I have to punt to the container > wizards. Short version. If you are going to do migration of a container with CRIU you want the time namespace in your container. Possibly you can avoid creating the time namespace until restore, but I don't think so. Without the time namespace you get all kinds of applications that use monotonic timers that will see their timers be ill behaved (probably going backwards) over a checkpoint-restart event. Eric