Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3571391imu; Fri, 18 Jan 2019 12:46:34 -0800 (PST) X-Google-Smtp-Source: ALg8bN4yIVCn6PSwJO3lq4s4EhTsAu9zELvIZQNG0Q5cQxda0wYWnyKPwjcFCllt4Gb++4p0jx6o X-Received: by 2002:a63:f615:: with SMTP id m21mr19568649pgh.428.1547844394499; Fri, 18 Jan 2019 12:46:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547844394; cv=none; d=google.com; s=arc-20160816; b=JYlBGXWNfTxaXbJjxjrWBJc2jOPX3oouUF66KSjzKaSoDRdfyiFuD8l1CN4e+gTrbc CIT7HDtb/I03765i8e9gPUUMJ91alyrDP/APhqna5JnV6nUMgTEGqk7bbqQSDnNdUZ0a NC4usO/gLUgSlMpx1tIP7INNnBmOxADlR7269TCsXzh1v9J3o3cXA0eZh1ZbluAKWDDW Vd+YxlUvxhbB0OQasru2Lh5YsL8hBhhfD1CHLsRqYPzviROonLtsomxMRnQXPEYoHFml KkRrWI5cDzy7DdVQ1rxQDRhoHz+DjCupBjouDahtTqWf3XeA5rYz10M4WT1cRZgQopXC Cq6g== 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; bh=ORQ5TPnixziDIHsuvdhJc04sEDyDC/r90DJmiSnzeTU=; b=IeI6U1WhWSGzW3Epc/fnfiVcX3jisJtRChHUgEe1Y39SLO17E+QeeH4YDyvPcX0IwY U5F+hqIKNf4jU7f1hDyYO/L3ON2TYRu7K6mzQm2gO5O19kYk5N6sq31LUi4I1gp9rfha 4x4Vsaqqo2TpaZXkvP+WpBzk4E4TfbRiypj/98OWxqLe+CeamvM8nBgF74H2h7vBVQ/I Xr7Q+VwPS57Av/3WMwUz3b/VnwsevSmvPehIMIsYSh1DpQ5b1XE6FlVv6XAo2gAqoRrK bVt/ghE9cKTJFAygC9gXcvKNLU/n0Y5JiSQiL9LpI09NXxNUUsrPFWHHCLFdQx8g5Rgl zkNQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j39si5303916plb.272.2019.01.18.12.46.18; Fri, 18 Jan 2019 12:46:34 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729595AbfARUog (ORCPT + 99 others); Fri, 18 Jan 2019 15:44:36 -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-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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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