From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 08ED53851C1A for ; Wed, 25 Nov 2020 20:38:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 08ED53851C1A Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-477-O7Z5ndOeM6q4_3MWGe8kww-1; Wed, 25 Nov 2020 15:37:58 -0500 X-MC-Unique: O7Z5ndOeM6q4_3MWGe8kww-1 Received: by mail-qk1-f199.google.com with SMTP id q25so3295034qkm.17 for ; Wed, 25 Nov 2020 12:37:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=IJcBHUa5q245able4He9GSxvMxFj8YT9oIgh1BWou6g=; b=EUaDEFA7MsmhTJvpS6FDHEwpnMoIz/aaIzUJZ9FioJ2Hg/kz4t8kqWfkZRXADYZfyX uwnw5EvMkpk6FaNL8qoDwxbgIemuDofvnkK+tvHSoERBzhr4eN9qEFzlFFsbd2HZSFZh nLFVzvbbVTnf+6Z6QWAmA+LC9OYAr6aMEfavDPaEi4x97APjxhFIewaWYXwdZENK9qHu DspweKVkjQH9iDSDU1w0VBS/6lDLzhcqTtj4JsGUYqFPqlf65ZGQtWks6Ye9Vna/jE5j wV+vqwKpfRuSj3eBQUYxqArrnoLxMXSEdIiNDb2ddtlCNVrR3D1YDsgsG3/7B4AzPRs/ rNIQ== X-Gm-Message-State: AOAM532k4r8sQtpWpndHuY0xidAur6YVYKFQELJEcMnCduPUv42AMALN /mUvTUpZH6aFaIIgE/ERk3vB5+5Z7F3iCk/X3qEBYYNCDmZxgcO7+H5bk+259cg5y+mzAUNbrDe mZvqSJEWeAwVgvob3ukt1 X-Received: by 2002:a05:620a:632:: with SMTP id 18mr726710qkv.173.1606336677400; Wed, 25 Nov 2020 12:37:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJzPfz+fhdZGh/lgK1kAs5zgS5US+ZNzvHwy9bybWAsRBZme/uyVy4vkWuJx2sq5cLUKbWfhRQ== X-Received: by 2002:a05:620a:632:: with SMTP id 18mr726690qkv.173.1606336677144; Wed, 25 Nov 2020 12:37:57 -0800 (PST) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id i7sm427129qkl.94.2020.11.25.12.37.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 12:37:56 -0800 (PST) Subject: Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces To: Thomas Gleixner , Zack Weinberg , Cyril Hrubis Cc: Dmitry Safonov , Andrei Vagin , GNU C Library , Linux Kernel Mailing List , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= References: <20201030110229.43f0773b@jawa> <20201030135816.GA1790@yuki.lan> <87sg9vn40t.fsf@nanos.tec.linutronix.de> <72bbb207-b041-7710-98ad-b08579fe17e4@redhat.com> <87h7qbmqc3.fsf@nanos.tec.linutronix.de> <7bb5837f-1ff6-2b2c-089e-e2441d31ddb2@redhat.com> <87k0v7kwdc.fsf@nanos.tec.linutronix.de> <7a4d7b14-1f0b-4c40-2bd1-2582d8b71868@redhat.com> <87y2jej8mp.fsf@nanos.tec.linutronix.de> <87wnygopen.fsf@nanos.tec.linutronix.de> From: Carlos O'Donell Organization: Red Hat Message-ID: <5c382ef4-c505-5629-a85c-abae67c05c7c@redhat.com> Date: Wed, 25 Nov 2020 15:37:54 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <87wnygopen.fsf@nanos.tec.linutronix.de> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 20:38:01 -0000 On 11/19/20 7:14 PM, Thomas Gleixner wrote: > I hope you are aware that the time namespace offsets have to be set > _before_ the process starts and can't be changed afterwards, > i.e. settime() is not an option. I not interested in settime(). I saw Petr's request and forwarded it on here to further the educational conversation about CLOCK_REALTIME and cement a consensus around this issue. I'm happy to evangelize that we won't support settime() for the specific reasons you call out and that way I can give architectural guidance to setup systems in a particular way to use CRIU or VM+container if needed. > That might limit the usability for your use case and this can't be > changed at all because there might be armed timers and other time > related things which would start to go into full confusion mode. The use of time in these cases, from first principles, seems to degenerate into: * Verify a time-dependent action is correct. In glibc's case: * Verify various APIs after y2038. In Petr's case he could split the test into two such tests but he would have to reproduce the system state for the second test and I expect he wants to avoid that. In that case I think Petr has to use CRIU to start the container, stop it, advance time, and restart. That should work perfectly in that use case and solve all the problems by relying on the work done by CRIU. > The supported use case is container life migration and that _is_ very > careful about restoring time and armed timers and if their user space > tools screw it up then they can keep the bits and pieces. Agreed. > So in order to utilize that you'd have to checkpoint the container, > manipulate the offsets and restore it. Or use the same mechanisms CRIU uses. I can't rely on CRIU because I have to bootstrap a toolchain and userspace. We should be able to write a thin veneer into our own testing wrapper and emulate whatever CRIU does. We know apriori that our test framework starts the test without anything having been executed yet. So we have that benefit. Currently we unshare() for NEWUSER/NEWPID/NEWNS, but I expect that will get a little more advanced. Already having these namespaces helps immensely when adding fs-related tests. > Aside of this, there are other things, e.g. file times, packet > timestamps etc. which are based on CLOCK_REALTIME. What to do about > them? Translate these to/from name space time or not? There is a long > list of other horrors which are related to that. We haven't even started testing for the upcoming negative leap second ;-) > So _you_ might say, that you don't care about file times, RTC, timers > expiring at the wrong time, packet timestamps and whatever. I do care about them, but only given certain contexts. > But then the next test dude comes around and want's to test exactly > these interfaces and we have to slap the time namespace conversions for > REALTIME and TAI all over the place because we already support the > minimal thing. That's a decision you need to make when asked those questions. > Can you see why this is a slippery slope and why I'm extremly reluctant > to even provide the minimal 'distort realtime when the namespace starts' > support? I would argue this is a slippery slope fallacy. If and when we get better vm+container support we just tear all this code out and tell people to start using those frameworks. The vm+container frameworks have independent reasons to exist and so will continue to improve for security isolation purposes and end up solving time testing issues by allowing us complete control over the VMs time. >> Hopefully this ilustrates that real time name space is not "request for >> ponny" :-) > > I can understand your pain and why you want to distort time, but please > understand that timekeeping is complex. The primary focus must be > correctness, scalability and maintainability which is already hard > enough to achieve. Just for the perspective: It took us only 8 years to > get the kernel halfways 2038 ready (filesystems still outstanding). I agree. The upstream glibc community has been working on y2038 since 2018; not as long as the kernel. > So from my point of view asking for distorted time still _is_ a request > for ponies. I'm happy if you say it's more work than the value it provides. > The fixed offsets for clock MONOTONIC/BOOTTIME are straight forward, > absolutely make sense and they have a limited scope of exposure. clock > REALTIME/TAI are very different beasts which entail a slew of horrors. > Adding settime() to the mix makes it exponentially harder. Right. -- Cheers, Carlos.