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=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 99ACFC433E0 for ; Tue, 2 Feb 2021 19:25:06 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 51ACF64E49 for ; Tue, 2 Feb 2021 19:25:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 51ACF64E49 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=4dntO5z238aBDbRta2jKPA3ULnbIBEPEBZeazQoS2Oo=; b=SEb4f+3aU4ka22Yp3QrM87SOW C/fCNjdGMBQw4uW846vd/wRsyr13DNgzVsb3x67goHHReXSthO1jo5iOLvPACdwPEiKHpJ7FyQ1vz rkWzPMQ1VagJNvw+Bm23U14ua3NEmTX5TNJowxCbVDM1pqMEGB9yoraphCN/s1gooewLOg15/5//q +rkoESRpeujZTYwuoo+/s6PHvReAxy2qBRTPv//0PEDT2Nt4uZNRJ63hSeVT1lxR/9Xq7zhngUnW1 JU0ZE78W71NMM19zzuLK49zNvMWnWdzc7N0J3M304qjU1eJeuAtc+5MZNCeljQZSEZpJJed3s1E21 zOF+upG0Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l71HD-00031m-P4; Tue, 02 Feb 2021 19:23:51 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l71H9-00030l-Sa for linux-arm-kernel@lists.infradead.org; Tue, 02 Feb 2021 19:23:49 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CA3A8ED1; Tue, 2 Feb 2021 11:23:41 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.49.77]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A7AA23F73B; Tue, 2 Feb 2021 11:23:34 -0800 (PST) Date: Tue, 2 Feb 2021 19:23:31 +0000 From: Mark Rutland To: sonicadvance1@gmail.com Subject: Re: [PATCH] [RFC] arm64: Exposes support for 32bit syscalls Message-ID: <20210202192331.GF67187@C02TD0UTHF1T.local> References: <20210202165437.334515-1-Sonicadvance1@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210202165437.334515-1-Sonicadvance1@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210202_142348_036481_6269C8A6 X-CRM114-Status: GOOD ( 26.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Gavin Shan , Catalin Marinas , linux-kernel@vger.kernel.org, Julien Grall , Matteo Croce , Amit Daniel Kachhap , Vincenzo Frascino , Will Deacon , Ard Biesheuvel , Jean-Philippe Brucker , Marc Zyngier , Qais Yousef , Steven Price , Sami Tolvanen , David Brazdil , Dave Martin , Kees Cook , Anshuman Khandual , Frederic Weisbecker , Kristina Martsenko , Mark Brown , Al Viro , Thomas Gleixner , Peter Collingbourne , linux-arm-kernel@lists.infradead.org, Jens Axboe , Kevin Hao , Jason Yan , Oleg Nesterov , Tian Tao , Andrew Morton , Mike Rapoport Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Tue, Feb 02, 2021 at 08:54:23AM -0800, sonicadvance1@gmail.com wrote: > From: Ryan Houdek > > This is a continuation of https://lkml.org/lkml/2021/1/6/47 > This patch is currently based against a 5.10 kernel but rebasing against > latest HEAD is trivial > > Specifically Amanieu pointed out a couple of problem spaces that would > show up around memory management and various other bits. > > This convinced me that the previous path of only having an ioctl32 > syscall is only a bandage on a much larger problem. > > This takes a patch from the Tango support tree and modifies it a bit to > not rely on a Tango specific quirk. > > Original patch: > https://github.com/Amanieu/linux/commit/b4783002afb027ae702da8f56e43e45c7332d226 Please reconsider the presentation of this commit message, because as it stands it's practically unreviewable, and for the vast majority of people CC'd this is noise. You need to write this such that someone can read this from start to finish and understand each step without jumping back-and-forth, without the reader having to read external links. Introduce the big picture first (what problem are you trying to solve? Who does this matter to?), then context (There's a constraint ..., someone previously tried this but there was a specific problem ...), then give an overview and justification for the code, with any caveats that reviewers may need to take into account. As-is, this commit message doesn't follow that flow, and that places a burden on reviewers to expend significant effort to reverse-engineer and extract the information they need. You'll find it's much easier to make progress if you optimize for the reviewers. Please look at the general way commits in the Linux source tree are written, and try to follow that approach. > This patch changes the KSTK_EIP and KSTK_ESP helpers to only fall to > Tango specific behaviour once a "Tango" syscall has been invoked. At this point the reader has no idea what a "Tango" syscall is, nor why this should affect KSTK_EIP or KSTK_ESP. What is a "Tango" syscall? Who is this useful for? Why does this matter to the upstream kernel? > I'm working on a backwards compatibility project that is unrelated to > Tango, but it would be nice to have a solution that works for both of > us. Since we are both working on projects that run 32bit applications > inside of a 64bit process for compatibility purposes. Only here do reviewers discover this something to do with running 32-bit applications somehow, when really that should be in the first couple of sentences. Generally, I have significant misgivings about exposing a new syscall interface (or exposing an existing interface to different callers). It's a maintainability nightmare, and since it's liable to violate implicit assumptions made in syscall implementations there's huge scope for error including bugs and exploitable behaviour. So without significant justification, my view is to NAK this sort of change. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel