Received: by 10.223.164.202 with SMTP id h10csp1002500wrb; Tue, 7 Nov 2017 19:32:35 -0800 (PST) X-Google-Smtp-Source: ABhQp+SeLj9w9xsSC+TrcosUtfYZpJZ7Yu+aa7pxmgBLEht6kFajFrh9IQvSpT4C7+O2RxSXwYm6 X-Received: by 10.98.29.212 with SMTP id d203mr958406pfd.226.1510111955744; Tue, 07 Nov 2017 19:32:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510111955; cv=none; d=google.com; s=arc-20160816; b=QMOHOpJwzbtVmrbgRynRXGtB3e4kbNMyvWeIykwBN9cXyyjhBsRHjpfsKFzsZtBHCx Va/iiYw8IFx5P1H7AjQb3/4bB9CljX/kzif+OWFd8yMi8baL+ajUzFkWrJpo/RBuyvY8 Wv51eru/P7N0MdbC+fBvrGYu7H9AE/aH2kWhYpiNuL3EFXV26V2Nl9TdHplZRnMVHMxo zBRVNBLuIYT1ahPGuafs0mbzySF8JNRLiybDg+gF/61QGImuVWoU+DcZsXO7YN7FWeB5 IsBJzaBBqveupc/ipigTfb0revbkEWyIH28KXZzYLaZZ44ppIdpxEZDT7mhlEEeKS73L 0oRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=gVQHAnqjDWUNKT6JTx5kkossHwA2bIFFXjWY/74BaLQ=; b=uthkGYyOO1TxYtFwThkmd7jUhm+NF7BYGobcmHeutafVNoG4Awv8hNV8U8EBPAOtNu oCF4zNtj6l8IlDNVUO4CAPC8TzJ13cElwk1A4LCI0EvYzA/eiJ06BeVYD51WlT9+w2jU B0b2OnINKK0GiTIxDEAU5YCdvYG8SESsdrmoZYrZNSk5EAI1cgFcKKWyGV+f6/2pzukQ Wq5dCqXmGIbTotCAGKwT2tVyEjHx3Oea1K0f8fbdmjblrdxKjCKJc9XC81Lb1w17+Rl6 BQ8ksOTDE7cZJvALJHNbV1tmL2LQkGoGrcvCZYoA/vtD4nenLaHc+deqhOgP5v77UBGG THFg== 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=codethink.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p6si2583707pgf.114.2017.11.07.19.32.22; Tue, 07 Nov 2017 19:32:35 -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=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933538AbdKHAWt (ORCPT + 90 others); Tue, 7 Nov 2017 19:22:49 -0500 Received: from imap1.codethink.co.uk ([176.9.8.82]:42129 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755815AbdKHAWq (ORCPT ); Tue, 7 Nov 2017 19:22:46 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126] helo=xylophone) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1eCE8g-0003XJ-O3; Wed, 08 Nov 2017 00:22:43 +0000 Message-ID: <1510100559.2465.44.camel@codethink.co.uk> Subject: Re: [Y2038] [PATCH 2/2] alpha: osf_sys.c: use timespec64 where appropriate From: Ben Hutchings To: Arnd Bergmann , Richard Henderson Cc: y2038@lists.linaro.org, linux-kernel@vger.kernel.org, Ivan Kokshaysky , Alexander Viro , linux-alpha@vger.kernel.org, Matt Turner , Deepa Dinamani Date: Wed, 08 Nov 2017 00:22:39 +0000 In-Reply-To: <20171107141029.3160278-2-arnd@arndb.de> References: <20171107141029.3160278-1-arnd@arndb.de> <20171107141029.3160278-2-arnd@arndb.de> Organization: Codethink Ltd. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-11-07 at 15:09 +0100, Arnd Bergmann wrote: > Some of the syscall helper functions (do_utimes, poll_select_set_timeout, > core_sys_select) have changed over the past year or two to use > 'timespec64' pointers rather than 'timespec'. This was fine on alpha, > since 64-bit architectures treat the two as the same type. > > However, I'd like to change that behavior and make 'timespec64' a proper > type of its own even on 64-bit architectures, and that will introduce > harmless type mismatch warnings here. > > Also, I'm trying to kill off the do_gettimeofday() helper in favor of > ktime_get() and related interfaces throughout the kernel. [...] > @@ -1004,9 +1013,10 @@ SYSCALL_DEFINE2(osf_gettimeofday, struct timeval32 __user *, tv, >   struct timezone __user *, tz) >  { >   if (tv) { > - struct timeval ktv; > - do_gettimeofday(&ktv); > - if (put_tv32(tv, &ktv)) > + struct timespec64 kts; > + > + ktime_get_ts64(&kts); [...] But this syscall is supposed to use the realtime clock, no? It seems like the correct substitute here is getnstimeofday64() (as the kernel- doc comment for do_gettimeofday() *almost* says). Ben. -- Ben Hutchings Software Developer, Codethink Ltd. From 1583449839942870191@xxx Tue Nov 07 22:57:23 +0000 2017 X-GM-THRID: 1583449839942870191 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread