Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3453914imu; Wed, 7 Nov 2018 10:32:35 -0800 (PST) X-Google-Smtp-Source: AJdET5cMs3c08lmoEvjzbqGPTGtXJOKPkzlCyZR1XULvQD8Vmma3TO+9JWL/waaJflhOKrISYY9E X-Received: by 2002:a63:151f:: with SMTP id v31mr1115040pgl.34.1541615555278; Wed, 07 Nov 2018 10:32:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541615555; cv=none; d=google.com; s=arc-20160816; b=fStFT0vEYWdQrsgRrarQbGNZcdCPel1m8Sod/7NXd4S0KsaKgYyN3gX1bjzil4pnyk KppHkr1Qz1Dh98Q/6VH4byCBCrmq9hED580l54XnWU4sxKRanEeIV3xdTXMuCjiozzR0 Px4n3cK8sSA0FC2DzXXWAoe9IshG1X8oLndRVAdyjS4oxcOaCJpORxZtNO7arBwEiAeX VGqNB26r1aRXCi3n9Ef+5JEJzbjqG/1Dy+G/CZ1mtgYy0esoGBkkGd42ZK9pc2+WfMoG tXGx2DIS7LHjkRXfl/8pC+bO4cqEctyaRlq6yWEMw5dbiBaxla/2faDE305pWsc6aHOm 3pnw== 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=Qir1mi0hHMJAP7Lw3MalCFm49tn0u4t4BKJWHobqbRU=; b=rsdj/jAKF9Byev6Tnlb8OZwaVAjIUotqrCfWB+qm37xR38ye94JL0YuokiVvHk6/6Y sJf9sRbeXWtN9x3wNreyQAJ4mMcNBmofVj5xCxzXmoBDop1PelgqNPldt0awDrRw6XQo 5qCMLlMdgE+ZZ4SHS2kqSGT8LJgwh2XUF9XUFKTIhaPGjmFyv7Aypt0WPzURjd2y0ESW gHAEb9CXS4eXDPsy0U7GGpmVu72EkeqOEYLUQvltZzoJ0+pGf0KarKctmhKLsPqddGBX D6uHenH5nakUpTFmsEOGQ45ng2/Oll0nbvepVtX6v9gDN7L5cNfakq0NXv/lb9Ju69R3 3vtQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tf63N5w6; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3-v6si1399070plm.136.2018.11.07.10.32.20; Wed, 07 Nov 2018 10: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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tf63N5w6; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728252AbeKHEBz (ORCPT + 99 others); Wed, 7 Nov 2018 23:01:55 -0500 Received: from mail-ot1-f65.google.com ([209.85.210.65]:33358 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726726AbeKHEBz (ORCPT ); Wed, 7 Nov 2018 23:01:55 -0500 Received: by mail-ot1-f65.google.com with SMTP id q1so15724352otk.0 for ; Wed, 07 Nov 2018 10:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qir1mi0hHMJAP7Lw3MalCFm49tn0u4t4BKJWHobqbRU=; b=tf63N5w6VuBPxQ5zlL67xSUas37DgpssM1ymwWH8FHvyqVEyDKUi07Bl/GuhLFwUgg GVUpy8VcxftGvoxCFgW79pwkbwNDdeAiVqnaaXrwjHCOksE2K86wrnJX5D3Ho3ltSDmC 4/HMLfwUBlYzWBbdYcWV4yxcYny40OA9FQjJHK5SBFoWI9EjM8Li/Hjt+2tY1uqaLtZE 29SGGSWyk1INmti7hgzlczMdLs7oOFsLUWKr48fFSIsE8eb5k8H14CEQAmjXJLPc9rJC gPzGZ+sD1ZwLz9o/3kzIHZSyXXuwID0jCt0pGLprucdiJKuQz+2g7cHulGjKtYSflwOt Tqew== 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=Qir1mi0hHMJAP7Lw3MalCFm49tn0u4t4BKJWHobqbRU=; b=cS59w1r8qMOAULSfPPoV3WFbpQ33dP2K5XCkqprM+zVxy2cgFu1CRj7GtbpCEyrAv6 qC6i52rqGDzm86OuwiCsP5GHqqlWsMIKVYPmGYY2sYZWHcUcGz95yoiZRwz+MWP/YYV5 St2FnnmYb2btG0GADCDZ5xMlOPVpGrHeeslTjqO4moyL506L4X/Z6ZT0v7tVp01k3GNT HVWWD8yt84wZOf+3nlsmYESAkobWncrxim3A1rlMPN5ZqIx72SUDorCuN6LMH6Hr24OQ vmMuH1RhmgxOUsRG+ya5EBBScd9yZSpNmAaCgIW4L2K7A3Ylh6krzuAt4X8JVtkksVaj xZ0A== X-Gm-Message-State: AGRZ1gKCHvocn67nwssLgydgwYQ+erma9LZWBPfUfXRn6EjZ2EoU67gs +CErYmnvxk9oQEC8uEcNdELNX+08prrSDZUNajw= X-Received: by 2002:a9d:2ea9:: with SMTP id w38mr756772ota.99.1541615415219; Wed, 07 Nov 2018 10:30:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Abdurachmanov Date: Wed, 7 Nov 2018 19:30:03 +0100 Message-ID: Subject: Re: [PATCH] riscv: add asm/unistd.h UAPI header To: Palmer Dabbelt Cc: Arnd Bergmann , aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Marcin Juszkiewicz , Guenter Roeck 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 Wed, Nov 7, 2018 at 1:08 AM Palmer Dabbelt wrote: > > On Mon, 05 Nov 2018 12:56:15 PST (-0800), Arnd Bergmann wrote: > > On 11/5/18, David Abdurachmanov wrote: > >> Marcin Juszkiewicz reported issues while generating syscall table for riscv > >> using 4.20-rc1. The patch refactors our unistd.h files to match some other > >> architectures. > >> > >> - Add asm/unistd.h UAPI header, which has __ARCH_WANT_NEW_STAT > >> - Remove asm/syscalls.h UAPI header and merge to asm/unistd.h > >> - Adjust kernel asm/unistd.h > >> > >> So now asm/unistd.h UAPI header should show all syscalls for riscv. > >> > >> Before this, Makefile simply put `#include ` into > >> generated asm/unistd.h UAPI header thus user didn't see: > >> > >> - __NR_riscv_flush_icache > >> - __NR_newfstatat > >> - __NR_fstat > >> > >> which are supported by riscv kernel. > >> > >> Signed-off-by: David Abdurachmanov > >> Cc: Arnd Bergmann > >> Cc: Marcin Juszkiewicz > >> Cc: Guenter Roeck > > > > Thanks for addressing this, your patch correctly fixes riscv64, and > > I should have noticed the mistake when I originally merged the > > broken patch. > > > > However, looking closer I found another problem with the original > > patch that your fix does not address: > > > > __ARCH_WANT_NEW_STAT should only be set on 64-bit > > architectures. > > > > For a 32-bit architecture, we only want __ARCH_WANT_STAT64 if > > any. For 64-bit architectures with compat mode, we still need to > > set __ARCH_WANT_STAT64 from the non-uapi file so we get > > the syscall implementation. > > > > If we don't care about the riscv32 ABI changing yet, we can > > decide to leave out __ARCH_WANT_STAT64 here, and require > > glibc to implement it using statx() like any new architecture. > > stat64 is not y2038 safe, and statx replaces it because of that. > > Thanks for pointing this out. A while ago we decided the rv32 ABI was > "slushy": it can change if it has a good reason to. Right now the only planned > changes are the y2038 changes, which I consider this a part of. For some > reason I thought we'd already done this, but since we haven't then I think it > should go in sooner rather than later -- that will help the glibc guys get > everything lined up. > > The target is still the next glibc release (Feb 1st) for a stable RV32I ABI. > That's progressing well, with one last blocking issue related to some of our > floating-point emulation routines before we can submit the port. This should > give us ample time to line up the ABIs correctly so everything works. > > So I think the correct answer here is to drop __ARCH_WANT_STAT64 from RISC-V. > Then if you agree I could do and send v2: +#ifdef __LP64__ +#define __ARCH_WANT_NEW_STAT +#endif /* __LP64__ */ Cannot use CONFIG_64BIT as in user space nothing defines it. Alternatively I could check for __riscv_xlen == 64. I found _LP64 and __LP64__ being used in kernel, incl. include/uapi/linux/rseq.h david