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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 2C9A4C1B0FD for ; Fri, 18 Jan 2019 20:44:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F299C2086D for ; Fri, 18 Jan 2019 20:44:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729575AbfARUof (ORCPT ); Fri, 18 Jan 2019 15:44:35 -0500 Received: from mail-qt1-f195.google.com ([209.85.160.195]:34307 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729569AbfARUof (ORCPT ); Fri, 18 Jan 2019 15:44:35 -0500 Received: by mail-qt1-f195.google.com with SMTP id r14so16787244qtp.1; Fri, 18 Jan 2019 12:44:33 -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=ORQ5TPnixziDIHsuvdhJc04sEDyDC/r90DJmiSnzeTU=; b=mT5Fq8haOw39l3SAJ+CmF45vyC9jpJwSF4//CAyZ2N67+F2rfBYOlb1s6uICMn22Xa GDpkJaIvPEFvUYYgFDTYlTD9BWzSaSZk2Q67fjt4Chx1n4/cZvZfwfwrwKJ+sHE7q4u8 1nxN+0/5k+au8ihqPtf+s7NS8eKz/08My0DL7Nv3Dek9ObBsdBNGE1LzoMtNoRCOpNpM dAlBCaWI4RwQx4NdTnZL+OnHel/RhYiwP/Xro7Je4MQCPa0Mg1inRcYaXwjsVfW8gd49 +1WWujpsrJny6GPdicKQ5MFd6LVOm7oIOj4KUW/mJLC/xS2VCIlQwLLzpQuVZtNt30IZ b5zA== X-Gm-Message-State: AJcUukfiNmnSf1eEa3alHL+65BvLTEoP3fU70HFcxW1m/yBS8T/ZItSI kAzp3K6dUfi38UOhezhIaY3gZ12GTBYfbw0U2Rw= X-Google-Smtp-Source: ALg8bN4ggcJ9u9iUb42HjHwnUQYctSfqKH3E3MdNfQhsEyd2ovYbbCJ8aRRYCcgq2HtqlmRxO9eWK6dWZp4WMFrZjzM= X-Received: by 2002:a0c:d992:: with SMTP id y18mr17616058qvj.161.1547844273008; Fri, 18 Jan 2019 12:44:33 -0800 (PST) MIME-Version: 1.0 References: <20190118161835.2259170-1-arnd@arndb.de> <20190118161835.2259170-30-arnd@arndb.de> In-Reply-To: From: Arnd Bergmann Date: Fri, 18 Jan 2019 21:44:16 +0100 Message-ID: Subject: Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures To: Andy Lutomirski Cc: y2038 Mailman List , 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" , 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-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Fri, Jan 18, 2019 at 8:53 PM Andy Lutomirski wrote: > I think we have two issues if we reuse those numbers for new syscalls. > First, I'd really like to see new syscalls be numbered consistently > everywhere, or at least on all x86 variants, and we can't on x32 > because they mean something else. Perhaps more importantly, due to > what is arguably a rather severe bug, issuing a native x86_64 syscall > (x32 bit clear) with nr in the range 512..547 does *not* return > -ENOSYS on a kernel with x32 enabled. Instead it does something that > is somewhat arbitrary. With my patch applied, it will return -ENOSYS, > but old kernels will still exist, and this will break syscall probing. > > Can we perhaps just start the consistent numbers above 547 or maybe > block out 512..547 in the new regime? I'm definitely fine with not reusing them ever, and jumping from 511 to 548 when we get there on all architectures, if you think that helps. While we could also jump to 548 *now*, I think that would be a bit wasteful. Syscall numbers are fairly cheap, but not entirely free, especially when you consider architectures like mips that have an upper bound of 1000 syscalls before they have to get inventive. Arnd