From patchwork Wed Mar 27 08:52:03 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lukasz Majewski X-Patchwork-Id: 1066739 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=sourceware.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=libc-alpha-return-100904-incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="uGr0ZoO/"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 44Thbg5wt7z9sSh for ; Wed, 27 Mar 2019 19:53:03 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id; q=dns; s= default; b=xNn0mfmj1J0hewFxWkKtrKWlF4V/dGq/HMYaQxq9vo/QFpIm4A9UF BlJ+DU2qFsyIWNvGrMfmdYcg9Zsyj05o/V6yrOmYT9+KjA3vjcpUysCya71UOSoM 8G6o+45q0hGXJaBNcxm0T9S4geLJ2upJMBh3jKWsn0CpaVbMQyklKA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id; s=default; bh=otiAXrZpTaeRy78Nlz+vSH+fob8=; b=uGr0ZoO/E8u6C1lQj4yEFHM4N+6n qNScbXtkkXd03l+qVKIvUqdfPn0juDOAfM3MFBjRpi5JZkZd5XnnYv09VxQo9qZj qAmv0/pw1SZ6ZERMukOpmpJXUYi3d0pQAaSn6w1Jmnprg4bzQ3cZ4kQgN4OJ6Q1F YLoV8MaWfXClqAI= Received: (qmail 16305 invoked by alias); 27 Mar 2019 08:52:37 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 16231 invoked by uid 89); 27 Mar 2019 08:52:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_SHORT, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=UD:features.h, proceeding, features.h, featuresh X-HELO: mail-out.m-online.net From: Lukasz Majewski To: libc-alpha@sourceware.org, Joseph Myers Cc: Paul Eggert , Zack Weinberg , Lukasz Majewski Subject: [RFC 0/7] y2038: clock_settime rework to be Y2038 safe on 32bit systems Date: Wed, 27 Mar 2019 09:52:03 +0100 Message-Id: <20190327085210.22019-1-lukma@denx.de> This patch set is a RFC to present the conversion and support of clock_settime to be Y2038 safe. This work is based on a previous development/patches: https://libc-alpha.sourceware.narkive.com/zniMOWui/rfc-patch-00-52-make-glibc-y2038-proof#post68 And shall be applied on top of: https://github.com/lmajewski/y2038_glibc/commits/mktime_v3_fixes Github repository: https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-__clock_settime64_v1-27-03-2019 Shall be used with provided meta-y2038 for development and testing: https://github.com/lmajewski/meta-y2038 I've used guidelines from: https://www.gnu.org/software/libc/manual/html_mono/libc.html "D.2.1 64-bit time symbol handling in the GNU C Library" to convert *clock_settime*. - The clock_settime() has been choosen as a relatively easy syscall for conversion (i.e. no VDO) - The idea for proceeding: convert a single syscall (clock_settime) or related group of syscalls (clock_gettime, clock_nanosleep,clock_getres, clock_settime) - to keep the number of changes manageable - The explicit 64 bit time related syscalls (Y2038 safe) have been already accepted to mainline Linux kernel (5.1-rc2): https://elixir.bootlin.com/linux/v5.1-rc2/source/arch/arm/tools/syscall.tbl#L420 - Test(s) for Y2038 (with using clock_settime) would be added to glibc after the pair of clock_settime/clock_gettime is accepted/reviewed - Last two patches of this series shows the way how the Y2038 support is going to be added to glibc. - The important question about enabling Y2038 support in glibc: -- If a well tested group of functions/syscalls (like clock_*) is accepted with the Y2038 support enabled (_TIME_BITS passed to user program enables 64 bit time) or -- The Y2038 support is enabled only when _ALL_ syscalls/functions are Y2038 ready - I've read that clock_* functions were moved from librt to glibc - what was the motivation behind this move? Why to we have compatibility code in the rt/* for clock_settime() if the _real_ support is in time/* ? Comments are more than welcome. Lukasz Majewski (7): y2038: Introduce struct __timespec64 y2038: Provide conversion helpers for struct __timespec64 y2038: clock_settime: Provide __clock_settime64 implementation for linux y2038: rt: clock_settime: Convert __clock_settime to __clock_settime64 y2038: clock_settime: implementation for Unix generic y2038: Support for Y2038 safe time on 32 bit systems (generic code) y2038: Introduce support for clock_settime() being Y2038 safe include/features.h | 19 +++++++ include/time.h | 97 ++++++++++++++++++++++++++++++++- manual/creature.texi | 28 ++++++++++ rt/Versions | 2 +- rt/clock-compat.c | 3 - rt/clock_settime.c | 4 +- sysdeps/unix/clock_settime.c | 23 ++++++-- sysdeps/unix/sysv/linux/clock_settime.c | 51 +++++++++++++---- time/Makefile | 2 +- time/bits/types/struct___timespec64.h | 39 +++++++++++++ time/bits/types/struct_timespec.h | 8 +++ time/bits/types/time_t.h | 4 ++ time/time.h | 9 +++ 13 files changed, 265 insertions(+), 24 deletions(-) create mode 100644 time/bits/types/struct___timespec64.h