Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3502871imu; Fri, 18 Jan 2019 11:31:59 -0800 (PST) X-Google-Smtp-Source: ALg8bN7HKoEbdMgzGtQ7sMXSGZeIZZ5pAY3GnHPOM0h8VwjUgVRF8DLFV22rvsN9+3FlJzCJVnon X-Received: by 2002:a63:4456:: with SMTP id t22mr19338292pgk.0.1547839919559; Fri, 18 Jan 2019 11:31:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547839919; cv=none; d=google.com; s=arc-20160816; b=AY6c7lxXqFCcmdQsj+ZKmDTz8dGghvov92QNZSXACYp9HgLdSdRajbHhX7qbp7FcCz ycK9yEZid3j9thP1jlrRqym1ljwtmoqVvtCiQy1HRYWNmgRonoLRs0SfWiYy+3vW+ngj eSAJ9rvsTuMkJVXzwO9anXT7tKmrbI3T75mwYJ0VwZeYRzNSD72x7hDNbq59u05B8k4o S8C74ClTg0N3EIXXbaQu8mUfP+epTFeZiOSJsvR8tC5hI9wqRUl4d6So/bs+LfWB5AXU nydxnyq5uRX2NMcdR/08LvVVmKwIVhgI0wEpalqCrkeCZaM3jMjHHcJI6ffQ+hA3gkh4 bZoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=LAyYSJPcS4Ttf6JnZRQLkX+RaJQg7euT8gVDn1keJgc=; b=tD3f4OGiao9mVu6fzUod4TB/rHnUQrdgwuWYovx4QulpBrZmoO/K+/vtwEQWR/LGO2 oAZKvOru6XR60Wcif3Y2RathBUDu2cQkbR1IF0O7PkHxSCeqxCBkj53pInT+Z9tFQbS8 CJOkUkp8nMQXAAx1fWBlaZgNotFEEQUYzMlhnGZxtPIEnKWZ3FpiDL2/uw+8E9BchLgL DS/WXXwnMOJPdOd3zhsJGiipqp2p5azOKN3r222sMsULQ6+/OgkYAv+vjhG3MenbIXUy Xo30Yvw3qrflaNpxCG3FFjn6T8Osl6YsfS50uGnjwP/aIXlwqiNxTGKrLmLyFVSQf28Y uU9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=tCFAK8gh; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 68si4522850pgd.437.2019.01.18.11.31.43; Fri, 18 Jan 2019 11:31:59 -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; dkim=pass header.i=@kernel.org header.s=default header.b=tCFAK8gh; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728980AbfARSul (ORCPT + 99 others); Fri, 18 Jan 2019 13:50:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:36684 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728592AbfARSul (ORCPT ); Fri, 18 Jan 2019 13:50:41 -0500 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2647C21738 for ; Fri, 18 Jan 2019 18:50:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547837440; bh=VoFGDVLCVcIdDEcxLef2+rlsJOjPa2ebgAiYkYzOvZE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=tCFAK8gh97QDVr+fqWM0ezDHTjqy+XJu0QeHvgv68vQG0bzqd09EkJwf8q2it5ZkO +CyufkCIlWkyDFGLQOpJcf5gZUihDk8swxgtvRTWwNn6840T68JYAaNgjsMp2Nd6SG pSYCdP9AxhF5tv6127zvXShyJaA1Ml1ueTffz0aA= Received: by mail-wr1-f41.google.com with SMTP id u4so16313358wrp.3 for ; Fri, 18 Jan 2019 10:50:40 -0800 (PST) X-Gm-Message-State: AJcUukcNn1KDEwD/RFizRG8vINsgUWD7YCOl6sXrXoLPI5wxVYsRGb6D xWM0891wUasMi5ggfd5XyCG8IJJUYlJL8nfmgaG+sg== X-Received: by 2002:adf:e08c:: with SMTP id c12mr17046840wri.199.1547837438534; Fri, 18 Jan 2019 10:50:38 -0800 (PST) MIME-Version: 1.0 References: <20190118161835.2259170-1-arnd@arndb.de> <20190118161835.2259170-30-arnd@arndb.de> In-Reply-To: <20190118161835.2259170-30-arnd@arndb.de> From: Andy Lutomirski Date: Fri, 18 Jan 2019 10:50:27 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures To: Arnd Bergmann Cc: y2038@lists.linaro.org, Linux API , LKML , linux-arch , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Geert Uytterhoeven , Michal Simek , Paul Burton , Helge Deller , Benjamin Herrenschmidt , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Rich Felker , "David S. Miller" , Andrew Lutomirski , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , X86 ML , Max Filippov , Andrew Morton , deepa.kernel@gmail.com, "Eric W. Biederman" , firoz.khan@linaro.org, linux-alpha@vger.kernel.org, linux-arm-kernel , linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev , linux-s390 , linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, Network Development , Linux FS Devel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > This adds 21 new system calls on each ABI that has 32-bit time_t > today. All of these have the exact same semantics as their existing > counterparts, and the new ones all have macro names that end in 'time64' > for clarification. > > This gets us to the point of being able to safely use a C library > that has 64-bit time_t in user space. There are still a couple of > loose ends to tie up in various areas of the code, but this is the > big one, and should be entirely uncontroversial at this point. > > In particular, there are four system calls (getitimer, setitimer, > waitid, and getrusage) that don't have a 64-bit counterpart yet, > but these can all be safely implemented in the C library by wrapping > around the existing system calls because the 32-bit time_t they > pass only counts elapsed time, not time since the epoch. They > will be dealt with later. > > Signed-off-by: Arnd Bergmann > --- > The one point that still needs to be agreed on is the actual > number assignment. Following the earlier patch that added > the sysv IPC calls with common numbers where possible, I also > tried the same here, using consistent numbers on all 32-bit > architectures. > > There are a couple of minor issues with this: > > - On asm-generic, we now leave the numbers from 295 to 402 > unassigned, which wastes a small amount of kernel .data > segment. Originally I had asm-generic start at 300 and > everyone else start at 400 here, which was also not > perfect, and we have gone beyond 400 already, so I ended > up just using the same numbers as the rest here. > > - Once we get to 512, we clash with the x32 numbers (unless > we remove x32 support first), and probably have to skip > a few more. I also considered using the 512..547 space > for 32-bit-only calls (which never clash with x32), but > that also seems to add a bit of complexity. I have a patch that I'll send soon to make x32 use its own table. As far as I'm concerned, 547 is *it*. 548 is just a normal number and is not special. But let's please not reuse 512..547 for other purposes on x86 variants -- that way lies even more confusion, IMO. --Andy