From patchwork Fri Mar 9 18:42:49 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 131212 Delivered-To: patches@linaro.org Received: by 10.46.66.2 with SMTP id p2csp1324180lja; Fri, 9 Mar 2018 10:43:01 -0800 (PST) X-Received: by 10.101.96.5 with SMTP id m5mr25217208pgu.374.1520620981747; Fri, 09 Mar 2018 10:43:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520620981; cv=none; d=google.com; s=arc-20160816; b=NlbbytGyFhDfUBGa9mqiqFmPhKQ+V2XB5JFWnUk8Oh/skC1hOXCtVcEmy356uZG+Fb 1xfxaDD1FqglUv38ECgdG1bDtLawJk/aseAcA7HhVzx6XP/m31Tu6zvr3gygDgFJm00x AkKGMpR1mgq9kNLLLoR0nd2a9+NEiUf/uXkCYsxU6nMRlt2CtxiwDhGxol0fjDEVuv/B IdIJSuH1L+lVZL6byxjOuMmSVvJdAHaCoTDpeQWR3Vp2SDv8lIhhNuR+k99hbTti4A2D P9O0WVbcyvtCJu/jUhgQOeyaIDVqBrjhaDBxyF1M683566ENLXRwqpUz0+DMcXUStqN/ 2gAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=SqKDls5c/gElYj4F2g4Nfq0lsuUBjbvBfKSRetlNOdQ=; b=n4y4lfs6Qr6mDjPINKyMkdAKkcgVTlVF3B295qT79WZ7aSoiWNaUbZT6BQUE00MYnr ks6ufzOOtoXep+GYVvSE/HHwwH9y2nllWBhBoyDM0jOQ1CCI140+VtvTwYwha7Hnx4qc t4P9lwqj10IKW+RvccITsPpjibnldhBD0aVK2wC/xUWga4gN99SWSQLD4eWJPMsxfdov 0S8dZhI8Q69iQuRdYSE0iuaWhf782lhm8QyRX77YYPu4PGMbejjcp4EeHEFFkDcSGvCs J7n057blcB+Nj6IbcXFhHQzuEWRV+yELnMW7WBm8ijBVb8RaXlsDFY/D6n0EUiZADpXA KXvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=C/mNSeCw; spf=pass (google.com: domain of john.stultz@linaro.org designates 209.85.220.65 as permitted sender) smtp.mailfrom=john.stultz@linaro.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id 92-v6sor776750pli.109.2018.03.09.10.43.01 for (Google Transport Security); Fri, 09 Mar 2018 10:43:01 -0800 (PST) Received-SPF: pass (google.com: domain of john.stultz@linaro.org designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=C/mNSeCw; spf=pass (google.com: domain of john.stultz@linaro.org designates 209.85.220.65 as permitted sender) smtp.mailfrom=john.stultz@linaro.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=SqKDls5c/gElYj4F2g4Nfq0lsuUBjbvBfKSRetlNOdQ=; b=C/mNSeCwCVltJnOZge1aKOaPnELd4NJFR1ohwomdVy5F25RX8Y6iv/XA/93CFOCWUw XNWFqyp5T+2peJW9jcfESR4loevqDBl7JyCCPmSYGSKHW6Ga/gU35Dc3AHAnL4uM9BF9 DbqDCJEB2HFxRVOGKE+VJTv7Ex+sLfK5sB7yc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=SqKDls5c/gElYj4F2g4Nfq0lsuUBjbvBfKSRetlNOdQ=; b=CElt4LcV0/Iag9bdcWs6dQTch+/ZbGd8cYSJC+nAlyeOQjfwSy1G+8qN9qtqBE+Bbt 45CtRKZ/4k/Ru0EX30ynPky1aIlUT9gr8YmcNLd/ri6nmLQ82phbE3gbKStcp8OtJ+P4 1V1CT0NGgQ2U6L8JOW+6QkV/ixM6/joZk+Pohf0bIckhn9zGhSWTgpS57XETHeFTQdse rn+UE+8DeYQBbhZGfVWmdWkji3k2X+QhGK8ehoNecBlw/43FhIyC396soxfl6djRxC2p DWiK1mVWLYJWprCcoJHgs1/dQeroZiYSYXHDe8VfKoeJP+qawzILntGTe2TIIqKOhzOo Ilzw== X-Gm-Message-State: APf1xPDKM8gkLsBPr2Qm1k3LijQOnQ6lZuRSmRDblE6CbPvU0XX3JvXU sfSOgaJBlAFqWmrgY6eOP38G+B/0 X-Google-Smtp-Source: AG47ELsNgzbtFual4/IrEahkk3fJIYb6BOXPEybs0PKnJyEVxZ+g673J0ejmRnLYus1IZrUcr6cSXQ== X-Received: by 2002:a17:902:42e:: with SMTP id 43-v6mr29389070ple.186.1520620981186; Fri, 09 Mar 2018 10:43:01 -0800 (PST) Return-Path: Received: from localhost.localdomain ([2601:1c2:600:5100:4e72:b9ff:fe99:466a]) by smtp.gmail.com with ESMTPSA id y5sm4333162pfd.85.2018.03.09.10.42.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Mar 2018 10:43:00 -0800 (PST) From: John Stultz To: lkml Cc: Arnd Bergmann , Thomas Gleixner , Ingo Molnar , Miroslav Lichvar , Richard Cochran , Prarit Bhargava , Stephen Boyd , John Stultz Subject: [PATCH 3/4] y2038: time: Introduce struct __kernel_old_timeval Date: Fri, 9 Mar 2018 10:42:49 -0800 Message-Id: <1520620971-9567-4-git-send-email-john.stultz@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1520620971-9567-1-git-send-email-john.stultz@linaro.org> References: <1520620971-9567-1-git-send-email-john.stultz@linaro.org> From: Arnd Bergmann Dealing with 'struct timeval' users in the y2038 series is a bit tricky: We have two definitions of timeval that are visible to user space, one comes from glibc (or some other C library), the other comes from linux/time.h. The kernel copy is what we want to be used for a number of structures defined by the kernel itself, e.g. elf_prstatus (used it core dumps), sysinfo and rusage (used in system calls). These generally tend to be used for passing time intervals rather than absolute (epoch-based) times, so they do not suffer from the y2038 overflow. Some of them could be changed to use 64-bit timestamps by creating new system calls, others like the core files cannot easily be changed. An application using these interfaces likely also uses gettimeofday() or other interfaces that use absolute times, and pass 'struct timeval' pointers directly into kernel interfaces, so glibc must redefine their timeval based on a 64-bit time_t when they introduce their y2038-safe interfaces. The only reasonable way forward I see is to remove the 'timeval' definition from the kernel's uapi headers, and change the interfaces that we do not want to (or cannot) duplicate for 64-bit times to use a new __kernel_old_timeval definition instead. This type should be avoided for all new interfaces (those can use 64-bit nanoseconds, or the 64-bit version of timespec instead), and should be used with great care when converting existing interfaces from timeval, to be sure they don't suffer from the y2038 overflow, and only with consensus for the particular user that using __kernel_old_timeval is better than moving to a 64-bit based interface. The structure name is intentionally chosen to not conflict with user space types, and to be ugly enough to discourage its use. Note that ioctl based interfaces that pass a bare 'timeval' pointer cannot change to '__kernel_old_timeval' because the user space source code refers to 'timeval' instead, and we don't want to modify the user space sources if possible. However, any application that relies on a structure to contain an embedded 'timeval' (e.g. by passing a pointer to the member into a function call that expects a timeval pointer) is broken when that structure gets converted to __kernel_old_timeval. I don't see any way around that, and we have to rely on the compiler to produce a warning or compile failure that will alert users when they recompile their sources against a new libc. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Miroslav Lichvar Cc: Richard Cochran Cc: Prarit Bhargava Cc: Stephen Boyd Signed-off-by: Arnd Bergmann Signed-off-by: John Stultz --- include/linux/time32.h | 1 + include/uapi/linux/time.h | 12 ++++++++++++ kernel/time/time.c | 12 ++++++++++++ 3 files changed, 25 insertions(+) -- 2.7.4 diff --git a/include/linux/time32.h b/include/linux/time32.h index 65b1de2..3febcaf 100644 --- a/include/linux/time32.h +++ b/include/linux/time32.h @@ -217,5 +217,6 @@ static inline s64 timeval_to_ns(const struct timeval *tv) * Returns the timeval representation of the nsec parameter. */ extern struct timeval ns_to_timeval(const s64 nsec); +extern struct __kernel_old_timeval ns_to_kernel_old_timeval(const s64 nsec); #endif diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h index 53f8dd8..888da62 100644 --- a/include/uapi/linux/time.h +++ b/include/uapi/linux/time.h @@ -43,6 +43,18 @@ struct itimerval { }; /* + * legacy timeval structure, only embedded in structures that + * traditionally used 'timeval' to pass time intervals (not absolute + * times). Do not add new users. If user space fails to compile + * here, this is probably because it is not y2038 safe and needs to + * be changed to use another interface. + */ +struct __kernel_old_timeval { + __kernel_long_t tv_sec; /* seconds */ + __kernel_long_t tv_usec; /* seconds */ +}; + +/* * The IDs of the various system clocks (for POSIX.1b interval timers): */ #define CLOCK_REALTIME 0 diff --git a/kernel/time/time.c b/kernel/time/time.c index bd4e6c7..cbb3c71 100644 --- a/kernel/time/time.c +++ b/kernel/time/time.c @@ -488,6 +488,18 @@ struct timeval ns_to_timeval(const s64 nsec) } EXPORT_SYMBOL(ns_to_timeval); +struct __kernel_old_timeval ns_to_kernel_old_timeval(const s64 nsec) +{ + struct timespec64 ts = ns_to_timespec64(nsec); + struct __kernel_old_timeval tv; + + tv.tv_sec = ts.tv_sec; + tv.tv_usec = (suseconds_t) ts.tv_nsec / 1000; + + return tv; +} +EXPORT_SYMBOL(ns_to_kernel_old_timeval); + /** * set_normalized_timespec - set timespec sec and nsec parts and normalize *