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 Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B4769ECAAA1 for ; Mon, 31 Oct 2022 19:39:47 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4N1NlP6ZBrz3cCZ for ; Tue, 1 Nov 2022 06:39:45 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=arndb.de header.i=@arndb.de header.a=rsa-sha256 header.s=fm3 header.b=GYtvJSOq; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm3 header.b=rmsf3ZPz; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arndb.de (client-ip=66.111.4.27; helo=out3-smtp.messagingengine.com; envelope-from=arnd@arndb.de; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=arndb.de header.i=@arndb.de header.a=rsa-sha256 header.s=fm3 header.b=GYtvJSOq; dkim=pass (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm3 header.b=rmsf3ZPz; dkim-atps=neutral Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4N1NkH1ZmRz3bjk for ; Tue, 1 Nov 2022 06:38:45 +1100 (AEDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id ACBA65C0112; Mon, 31 Oct 2022 15:38:41 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Mon, 31 Oct 2022 15:38:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1667245121; x=1667331521; bh=MgNMSe6Xf7 10RuzoxZeq3x7szaWx6N8myLp+SDNFSe8=; b=GYtvJSOquCisowS7lMj95XRnai HXhceTK3YeqChDQxWMmfvKqmsNUIOJN2Hwn7x6TtsXG5RYUmqU0sStkVRaLvdHwN I/WCrBX3c1n55wKIgUkFlyZ130JTu25RP/1MxMGxV8RmLx1HHOZGbFCcMDURq5WB 5F8J0PKKE57fGuSs3ZI+MT6jZQk04cpxJIyi2HEIdJ43Q/Zad76KqXUcAPfRS/WV 0luwVG7oANO2s7S0oWoOiHRhp16utRJ5Hx3mJ9LvcK4aU3xEU4C4X7s6alWeEVQL Gx4O2k6njR31+cBbFKZ9yvwcUfvJO1RXGNWFTkk9+JtO/d0OS5U0sSnCMR0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1667245121; x=1667331521; bh=MgNMSe6Xf710RuzoxZeq3x7szaWx 6N8myLp+SDNFSe8=; b=rmsf3ZPzcjqZKd1HK7MlVqEAF/NKNl+tM5BbR81HmEiZ hq6zixE7SIVXsKVdz6wyRFM59O/s7tYPO5rAB8PP9eifqzRShuaUV/urGeClfNdv ie2lDEANpo94Fgt2Kce+8An1Hmi4JD9Iis8S3+x4YW0dLS/G0+eOoR1RiK60s+eB /IpA9vSl8o2F1b7doP31xFc9Bq7ENxDM18HqFVZHBKEh2HEzZ2ldQB3YQwZryMBo ZA8moK8kDabfCUc3ZYe0Lm+dQXm8nafpN6hnD8jHs1rYMbwduP89c45WavYm9+Xl bNaNGZxKxoNJaTZxhKJWLMD2sBPHtqTwRcxuJpK/DA== X-ME-Sender:

X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrudefgdduvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepffehueegteeihfegtefhjefgtdeugfegjeelheejueethfefgeeghfektdek teffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhgusegrrhhnuggsrdguvg X-ME-Proxy:

Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0C1BCB60089; Mon, 31 Oct 2022 15:38:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1087-g968661d8e1-fm-20221021.001-g968661d8 Mime-Version: 1.0 Message-Id: <8c0317c2-1175-4feb-8d3f-d1d2e94b577b@app.fastmail.com> In-Reply-To: <87mt9cxd6g.fsf_-_@igel.home> References: <20220921065605.1051927-1-rmclure@linux.ibm.com> <20220921065605.1051927-22-rmclure@linux.ibm.com> <87mt9cxd6g.fsf_-_@igel.home> Date: Mon, 31 Oct 2022 20:37:49 +0100 From: "Arnd Bergmann" To: "Andreas Schwab" , "Rohan McLure" Subject: Re: [PATCH] powerpc/32: fix syscall wrappers with 64-bit arguments Content-Type: text/plain X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linuxppc-dev@lists.ozlabs.org, Andrew Donnellan Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Oct 31, 2022, at 15:47, Andreas Schwab wrote: > With the introducion of syscall wrappers all wrappers for syscalls with > 64-bit arguments must be handled specially, not only those that have > unaligned 64-bit arguments. This left out the fallocate and > sync_file_range2 syscalls. > > Fixes: 7e92e01b7245 ("powerpc: Provide syscall wrapper") > Fixes: e23750623835 ("powerpc/32: fix syscall wrappers with 64-bit > arguments of unaligned register-pairs") > Signed-off-by: Andreas Schwab This looks correct as a minmal bugfix to be backported. I have cross-checked the syscalls with 64-bit arguments that have special handlers on powerpc against the list from x86 to make sure there are no other obvious ones that need a similar fix. Reviewed-by: Arnd Bergmann > + > +#ifdef CONFIG_PPC32 > +SYSCALL_DEFINE6(ppc_fallocate, > + int, fd, int, mode, > + u32, offset1, u32, offset2, u32, len1, u32, len2) > +{ > + return ksys_fallocate(fd, mode, > + merge_64(offset1, offset2), > + merge_64(len1, len2)); > +} > +#endif This is identical to compat_sys_fallocate() and to (an andian-corrected) sys_ia32_fallocate(), right? I still think we should eventually generalize this further and make all these handlers architecture independent to prevent the same bug from happening on additional architectures, but that should probably be done separately. Arnd