From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC528C3713A for ; Mon, 21 Jan 2019 20:40:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B690B2089F for ; Mon, 21 Jan 2019 20:40:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727014AbfAUUkU (ORCPT ); Mon, 21 Jan 2019 15:40:20 -0500 Received: from mail-qt1-f194.google.com ([209.85.160.194]:40807 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726244AbfAUUkU (ORCPT ); Mon, 21 Jan 2019 15:40:20 -0500 Received: by mail-qt1-f194.google.com with SMTP id k12so25000217qtf.7; Mon, 21 Jan 2019 12:40:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dkvN5kxF5ScgcD3pJdfvtsR7PQS22YCBaQenUgPUi4M=; b=WxIbvVFxTx0suXOVY5LfjO8lIw0TcCbFhtasyWeTACtU9Rd0rCx9k0eylQMgWCXgdz S0iTVwiLW8cU3cPWBDQEHhT2/9NyhuRvx1oFfd6R8rwDFxjrjHWgJmY0x8FsLQlbWMOB xgJTTueMBUTkhWTCS/3cmwPN1ZZnyA9JlP7mnzwlhrJGrkX1OvBvLz2e3VZWyfg5Jhi8 F+W6T0PjHCKtEj9zVh+Mh5BAGS8+dlPFidGUI2/h5ZV5ySJmVbhKMags2M2zO8uEzyL/ Jrwvs9hZGOOg6Ydk44MjI1TWIf5xlrrXu83fBVjN61IIodAq1pqMwrLTa80la9AnFzGE VAag== X-Gm-Message-State: AJcUukcx0EZGJ8H4hV3AAcPKqP+AZd52MhJMpZxCDf8NYpPmKK/sASWX yDOH1rIX2NWgENIKUWCBA6AiHzj+sXZ9mPFXPPM= X-Google-Smtp-Source: ALg8bN6NJA3JpmMy0Rnw4UHCeBwdUwtaoF1faqE/rX9S/LB1A3Pp1thWOe1j9+1qk4H6TfQ6cwy2yDs31Lm4Qgs2hsM= X-Received: by 2002:a05:6214:1087:: with SMTP id o7mr27413754qvr.115.1548103218172; Mon, 21 Jan 2019 12:40:18 -0800 (PST) MIME-Version: 1.0 References: <20190118161835.2259170-1-arnd@arndb.de> <20190118161835.2259170-30-arnd@arndb.de> <20190119142852.cntdihah4mpa3lgx@e5254000004ec.dyn.armlinux.org.uk> In-Reply-To: From: Arnd Bergmann Date: Mon, 21 Jan 2019 21:40:01 +0100 Message-ID: Subject: Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures To: Geert Uytterhoeven Cc: Russell King - ARM Linux admin , Andy Lutomirski , y2038 Mailman List , Linux API , LKML , linux-arch , Matt Turner , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Michal Simek , Paul Burton , Helge Deller , Benjamin Herrenschmidt , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , X86 ML , Max Filippov , Andrew Morton , Deepa Dinamani , "Eric W. Biederman" , Firoz Khan , alpha , linux-arm-kernel , "linux-ia64@vger.kernel.org" , linux-m68k , linux-mips@vger.kernel.org, Parisc List , linuxppc-dev , linux-s390 , Linux-sh list , sparclinux , Network Development , Linux FS Devel Content-Type: text/plain; charset="UTF-8" Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org On Mon, Jan 21, 2019 at 6:08 PM Arnd Bergmann wrote: > On Mon, Jan 21, 2019 at 9:19 AM Geert Uytterhoeven wrote: > > Regardless, I'm wondering what to do with the holes marked "room for > > arch specific calls". > > When is a syscall really arch-specific, and can it be added there, and > > when does it turn out (later) that it isn't, breaking the > > synchronization again? > > We've had a bit of that already, with cacheflush(), which exists on > a couple of architectures, including some that use the first > 'arch specific' slot (244) of the asm-generic table. I think this > will be rare enough that we can figure out a solution when we > get there. > > > The pkey syscalls may be a bad example, as AFAIU they can be implemented > > on some architectures, but not on some others. Still, I had skipped them > > when adding new syscalls to m68k. > > > > Perhaps we should get rid of the notion of "arch-specific syscalls", and > > reserve a slot everywhere anyway? > > I don't mind calling the hole something else if that helps. Out of > principle I would already assume that anything we add for x86 > or the generic table should be added everywhere, but we can > make it broader than that. Applying this fixup below, ARnd diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl index d9c2d2eea044..955ab6a3b61f 100644 --- a/arch/x86/entry/syscalls/syscall_32.tbl +++ b/arch/x86/entry/syscalls/syscall_32.tbl @@ -398,7 +398,7 @@ 384 i386 arch_prctl sys_arch_prctl __ia32_compat_sys_arch_prctl 385 i386 io_pgetevents sys_io_pgetevents_time32 __ia32_compat_sys_io_pgetevents 386 i386 rseq sys_rseq __ia32_sys_rseq -# room for arch specific syscalls +# don't use numbers 387 through 392, add new calls at the end 393 i386 semget sys_semget __ia32_sys_semget 394 i386 semctl sys_semctl __ia32_compat_sys_semctl 395 i386 shmget sys_shmget __ia32_sys_shmget diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl index 43a622aec07e..2ae92fddb6d5 100644 --- a/arch/x86/entry/syscalls/syscall_64.tbl +++ b/arch/x86/entry/syscalls/syscall_64.tbl @@ -343,6 +343,8 @@ 332 common statx __x64_sys_statx 333 common io_pgetevents __x64_sys_io_pgetevents 334 common rseq __x64_sys_rseq +# don't use numbers 387 through 423, add new calls after the last +# 'common' entry # # x32-specific system call numbers start at 512 to avoid cache impact diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index 53831e4a4c86..acf9a07ab2ff 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -740,7 +740,7 @@ __SC_COMP_3264(__NR_io_pgetevents, sys_io_pgetevents_time32, sys_io_pgetevents, __SYSCALL(__NR_rseq, sys_rseq) #define __NR_kexec_file_load 294 __SYSCALL(__NR_kexec_file_load, sys_kexec_file_load) -/* 295 through 402 are unassigned to sync up with generic numbers */ +/* 295 through 402 are unassigned to sync up with generic numbers, don't use */ #if __BITS_PER_LONG == 32 #define __NR_clock_gettime64 403 __SYSCALL(__NR_clock_gettime64, sys_clock_gettime)