From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fhigh1-smtp.messagingengine.com (fhigh1-smtp.messagingengine.com [103.168.172.152]) by sourceware.org (Postfix) with ESMTPS id 16AB63898384 for ; Fri, 21 Jun 2024 09:42:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 16AB63898384 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arndb.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 16AB63898384 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=103.168.172.152 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718962963; cv=none; b=hXceVadj5/ZEJWI2B9ioFnJsvjsKvd0uDFGxmNla6z126Wj/pRQd8BwFdpmcvvlC+rmAjLY9+C+r3lIveha1O54TEz/SDK0VcES4dSKecpakW2iipYFktxJLze7ghmTPvePn/ef0QV6unqW/I+UyPWED875APcnP7faRT/fWnBc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718962963; c=relaxed/simple; bh=I6t6ZNrhm5J8olmFqMz7UqaHFBnlVaXvJq+5xRhx/EY=; h=DKIM-Signature:DKIM-Signature:MIME-Version:Message-Id:Date:From: To:Subject; b=sG8LzhuTHVny2kAELvyIbWQphwtT2Bt0dy++RAIFpr9+oUVPHE7hUpPopAV2ajVcLYo9wD8g/uBmc+WklN0tOXnpSoLLY7BC1/tnIo40YpXdMWC8C2/w9goJZfN7WF6jIv60Voq5A6rVnMxrcn0U2MlzZ3RWh0GVEjG9WsIEjKA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfhigh.nyi.internal (Postfix) with ESMTP id D8CC711401FF; Fri, 21 Jun 2024 05:42:41 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute5.internal (MEProxy); Fri, 21 Jun 2024 05:42:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1718962961; x=1719049361; bh=lJXqjdPTQI taFSDd10WfQGJxSki8+9Ze2rE4p5l7G8Y=; b=kSi1J5v8ppTJzytghvi1egT/Ia 9+ldYodLYyQldPhXZRr0j1nxE8kP4yF9rHPsPspfJ841d5Q5ViQCWPuzmJZYJhT0 fIPEcp9V5qyFi7AEspKXJAcZ8Qnrpck3uIjdg9iw88FiJ2Wo2LaQWYbgwGImcW7C SpIcDx9Toe1sQYoHixkBqQoDzyIS5FDmxlQhwooSdNQAdklgoz+seVjqfk4aHoHW A4nhpIj6RE6BQA1UWJz+o6XPMovw6j7YWgktwR2q22qomJ85HYJ9k056LTXLoiRz WD9ilToyXgKaO9cFbF1gMcl7y3CNzrqtd1tPSWbkBskpZg5jBtQcCdYH8f0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1718962961; x=1719049361; bh=lJXqjdPTQItaFSDd10WfQGJxSki8 +9Ze2rE4p5l7G8Y=; b=pA/sp92CHnJRaYFltnW5QQm7YBjn/jr/ORskiDkKKzJl es2qBBGdWZliar0A5Kt0UJqrpEU4HfKnpliN/sw1rbQRc8GZN17uqvH62Xdp65aO HH4ZKtJaiUAEtH7SeW0V3fTHziEaAELtfXcAj6AnMTZ3k0lepGRrxJCxl9OSjxhO lrVQJp4nYJovgRwRBg3lJyy+XhTf+vZxUn0FaYa+EL1F28QKT9bkP7mjgvvecyX2 rx/x7rRF+kOUWLCm+uckYztrfeWrqKylwbWptaWMLC7rcnOXK0JF9wcYkrUL02Ld uvsGXTrQA/s11hPdfq45FwQ1U6lT/5DWR0yPsQsVig== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeefgedgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepffehueegteeihfegtefhjefgtdeugfegjeelheejueethfefgeeghfektdek teffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id B4DADB6008D; Fri, 21 Jun 2024 05:42:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-522-ga39cca1d5-fm-20240610.002-ga39cca1d MIME-Version: 1.0 Message-Id: <9d4ba5e5-bb7f-432e-9354-47cc84eaa9e1@app.fastmail.com> In-Reply-To: <366548c1a0d9749e42c0d0c993414a353c9b0b02.camel@physik.fu-berlin.de> References: <20240620162316.3674955-1-arnd@kernel.org> <20240620162316.3674955-10-arnd@kernel.org> <366548c1a0d9749e42c0d0c993414a353c9b0b02.camel@physik.fu-berlin.de> Date: Fri, 21 Jun 2024 11:41:43 +0200 From: "Arnd Bergmann" To: "John Paul Adrian Glaubitz" , "Arnd Bergmann" , Linux-Arch , linux-kernel@vger.kernel.org Cc: "Rich Felker" , "Andreas Larsson" , guoren , "Christophe Leroy" , "H. Peter Anvin" , sparclinux@vger.kernel.org, linux-s390@vger.kernel.org, "Helge Deller" , linux-sh@vger.kernel.org, "linux-csky@vger.kernel.org" , "Naveen N. Rao" , "Heiko Carstens" , "musl@lists.openwall.com" , "Nicholas Piggin" , "Alexander Viro" , "LTP List" , "Brian Cain" , "Christian Brauner" , "Thomas Bogendoerfer" , "Xi Ruoyao" , linux-parisc@vger.kernel.org, linux-mips@vger.kernel.org, stable@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-fsdevel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, "David S . Miller" Subject: Re: [PATCH 09/15] sh: rework sync_file_range ABI Content-Type: text/plain X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Jun 21, 2024, at 10:44, John Paul Adrian Glaubitz wrote: > On Thu, 2024-06-20 at 18:23 +0200, Arnd Bergmann wrote: >> From: Arnd Bergmann >> >> The unusual function calling conventions on superh ended up causing > ^^^^^^ > It's spelled SuperH Fixed now. >> diff --git a/arch/sh/kernel/sys_sh32.c b/arch/sh/kernel/sys_sh32.c >> index 9dca568509a5..d5a4f7c697d8 100644 >> --- a/arch/sh/kernel/sys_sh32.c >> +++ b/arch/sh/kernel/sys_sh32.c >> @@ -59,3 +59,14 @@ asmlinkage int sys_fadvise64_64_wrapper(int fd, u32 offset0, u32 offset1, >> (u64)len0 << 32 | len1, advice); >> #endif >> } >> + >> +/* >> + * swap the arguments the way that libc wants it instead of > > I think "swap the arguments to the order that libc wants them" would > be easier to understand here. Done >> diff --git a/arch/sh/kernel/syscalls/syscall.tbl b/arch/sh/kernel/syscalls/syscall.tbl >> index bbf83a2db986..c55fd7696d40 100644 >> --- a/arch/sh/kernel/syscalls/syscall.tbl >> +++ b/arch/sh/kernel/syscalls/syscall.tbl >> @@ -321,7 +321,7 @@ >> 311 common set_robust_list sys_set_robust_list >> 312 common get_robust_list sys_get_robust_list >> 313 common splice sys_splice >> -314 common sync_file_range sys_sync_file_range >> +314 common sync_file_range sys_sh_sync_file_range6 > ^^^^^^ > Why the suffix 6 here? In a later part of my cleanup, I'm consolidating all the copies of this function (arm64, mips, parisc, powerpc, s390, sh, sparc, x86) and picked the name sys_sync_file_range6() for common implementation. I end up with four entry points here, so the naming is a bit confusing: - sys_sync_file_range() is only used on 64-bit architectures, on x32 and on mips-n32. This uses four arguments, including two 64-bit wide ones. - sys_sync_file_range2() continues to be used on arm, powerpc, xtensa and now on sh, hexagon and csky. I change the implementation to take six 32-bit arguments, but the ABI remains the same as before, with the flags before offset. - sys_sync_file_range6() is used for most other 32-bit ABIs: arc, m68k, microblaze, nios2, openrisc, parisc, s390, sh, sparc and x86. This also has six 32-bit arguments but in the default order (fd, offset, nbytes, flags). - sys_sync_file_range7() is exclusive to mips-o32, this one has an unused argument and is otherwise the same as sys_sync_file_range6(). My plan is to then have some infrastructure to ensure userspace tools (libc, strace, qemu, rust, ...) use the same calling conventions as the kernel. I'm doing the same thing for all other syscalls that have architecture specific calling conventions, so far I'm using fadvise64_64_7 fanotify_mark6 truncate3 truncate4 ftruncate3 ftruncate4 fallocate6 pread5 pread6 pwrite5 pwrite6 preadv5 preadv6 pwritev5 pwritev6 sync_file_range6 fadvise64_64_2 fadvise64_64_6 fadvise64_5 fadvise64_6 readahead4 readahead5 The last number here is usually the number of 32-bit arguments, except for fadvise64_64_2 that uses the same argument reordering trick as sync_file_range2. I'm not too happy with the naming but couldn't come up with anything clearer either, so let me know if you have any ideas there. >> 315 common tee sys_tee >> 316 common vmsplice sys_vmsplice >> 317 common move_pages sys_move_pages >> @@ -395,6 +395,7 @@ >> 385 common pkey_alloc sys_pkey_alloc >> 386 common pkey_free sys_pkey_free >> 387 common rseq sys_rseq >> +388 common sync_file_range2 sys_sync_file_range2 >> # room for arch specific syscalls >> 393 common semget sys_semget >> 394 common semctl sys_semctl > > I wonder how you discovered this bug. Did you look up the calling > convention on SuperH > and compare the argument order for the sys_sync_file_range system call > documented there > with the order in the kernel? I had to categorize all architectures based on their calling conventions to see if 64-bit arguments need aligned pairs or not, so I wrote a set of simple C files that I compiled for all architectures to see in which cases they insert unused arguments or swap the order of the upper and lower halves. SuperH, parisc and s390 are each slightly different from all the others here, so I ended up reading the ELF psABI docs and/or the compiler sources to be sure. I also a lot of git history. > Did you also check what order libc uses? I would expect libc on SuperH > misordering the > arguments as well unless I am missing something. Or do we know that the > code is actually > currently broken? Yes, I checked glibc, musl and uclibc-ng for all the cases in which the ABI made no sense, as well as to check that my analysis of the kernel sources matches the expectations of the libc. Arnd