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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFA36EB64D8 for ; Tue, 20 Jun 2023 17:42:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 18F1B8D0002; Tue, 20 Jun 2023 13:42:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 13FAC8D0001; Tue, 20 Jun 2023 13:42:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F21DB8D0002; Tue, 20 Jun 2023 13:42:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E40688D0001 for ; Tue, 20 Jun 2023 13:42:29 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 814E0404A2 for ; Tue, 20 Jun 2023 17:42:29 +0000 (UTC) X-FDA: 80923845618.28.69E631B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 38CE214000C for ; Tue, 20 Jun 2023 17:42:27 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=s9339xQy; spf=pass (imf09.hostedemail.com: domain of luto@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687282947; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sqKIvdO7nVnlhCbqbh7S6lEAiP1IQFwOtiZgfs6HSR8=; b=NYbrBd66ZTmU1Q4cV3VDOuAUaLcl0HxH1VDdWpILzAQ+KUdkt0jIEUzu0DJyDpHFx1aMVh lWoSOQbs7PZ4eGVjyoP+pMyk6mTTLL+ur05Jeg4mB8dNRmyl1iZuDbhYapQtrkhRXOrPo0 ZYq1Vsi9Mw0OHlHtCd/LuZWWCkTvsM8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687282947; a=rsa-sha256; cv=none; b=G4rc+sNIDkJWMYoAsCbN/coI4beRudpm46t+MbLYfOz4kLH3rIVunYgallJxKvBNNjbahg ec8y951KR1RJrdcKLp/ankdltrGW+rBMIJiUp5B8T8ulFe4/KvIlLsdVD2ebo8pZO6unxi Ycyl14voXk1jbB+f7HzKifyghSDfuv0= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=s9339xQy; spf=pass (imf09.hostedemail.com: domain of luto@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3F62A61326; Tue, 20 Jun 2023 17:42:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A6E6C433C9; Tue, 20 Jun 2023 17:42:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687282945; bh=HqPSWIaowE4nj5clj2k3JH4V3AbdDov4B8Rb4Patkfo=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=s9339xQyC0XBKYSx0zEQ4dFF/ahukeax3w/RKWqvx7TT7ZJ7GRStLt1BnylGu1Gam Fw4rsznAdu1fiSViLVt+OpO2XHctAYsz1uyYa/cqpHNsuHmtwpz4dxAE/R5Sc6gyF+ hZjVpSzhbWQQ/b+f7tOJ/usvDxSj09R99gxfklRToSZPVR3w466sG7kpO7cDKT0QAT SqA41wCiDuXRb1McOCqYoz+2IFjfv5x8AsKFF0Y6oQBLQh4oIXwN6tzhIvHEEi6a8I zAspRdgqXHatVMKHs6T8ISpg90hOsS5aIaqikisTvWksXpKhoeolozwTPp1t3VX49G 6EIsTI2sFKAEA== Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 3A59727C0054; Tue, 20 Jun 2023 13:42:24 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute3.internal (MEProxy); Tue, 20 Jun 2023 13:42:24 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgeefhedgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnhepvdfhuedvtdfhudffhfekkefftefghfeltdelgeffteehueegjeff udehgfetiefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Feedback-ID: ieff94742:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id B26A831A0063; Tue, 20 Jun 2023 13:42:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-499-gf27bbf33e2-fm-20230619.001-gf27bbf33 Mime-Version: 1.0 Message-Id: <5ef2246b-9fe5-4206-acf0-0ce1f4469e6c@app.fastmail.com> In-Reply-To: <20230619191740.2qmlza3inwycljih@moria.home.lan> References: <20230509165657.1735798-1-kent.overstreet@linux.dev> <20230509165657.1735798-8-kent.overstreet@linux.dev> <20230619104717.3jvy77y3quou46u3@moria.home.lan> <20230619191740.2qmlza3inwycljih@moria.home.lan> Date: Tue, 20 Jun 2023 10:42:02 -0700 From: "Andy Lutomirski" To: "Kent Overstreet" , "Mark Rutland" Cc: "Linux Kernel Mailing List" , linux-fsdevel@vger.kernel.org, "linux-bcachefs@vger.kernel.org" , "Kent Overstreet" , "Andrew Morton" , "Uladzislau Rezki" , "hch@infradead.org" , linux-mm@kvack.org, "Kees Cook" , "the arch/x86 maintainers" Subject: Re: [PATCH 07/32] mm: Bring back vmalloc_exec Content-Type: text/plain X-Stat-Signature: 6cheh1n6ezqxunu1fpn3m69bjykf89qg X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 38CE214000C X-Rspam-User: X-HE-Tag: 1687282947-79185 X-HE-Meta: U2FsdGVkX1+5TnKwuMmxv/N48ik0NpSjA8DRkcmaC+HDjkmHkNKje2SaedJX4TzeF9K9zQt6Xf7aZN3mkr9neG0xGhEiMfpvwLzPnJd8yBka29knW4x0K9YcfGmsu1H2qM2ojX0J9mdTa5FtoEba8R8E/I9y2JEsQ4JoWCweYPBg617RNY3LMYFGhWROnyyutW+G1GBgs/+iwT7DW8jbbgxddTsXZeG58+l0QxP4YO+PtC+0JdwI5bC3RC8Hbx93JI2fduAuXqPnTqf25vsFa6IlAxNIS+xpHNeqe/8aD9wbVNe1vDD+tt/AJw7qiU7d/r8O/exRwDEXlwAsbGHAdl93T0ju0V2IJXWhWQDDfn7XczqpTxZXFfoLjPDj7Xf663bfAdf1nGIrdpbXwlC4TWBepj7kMvzl0v7uihVT8I42PXOjc8K20WpQ6CSCeosrmwlK5slYjPhy+XRahZsZu5XDo+n35jvWh2BT/vIn45Q7eIDczkfli633cJQJw6C1LrzOMobodNWz35s6ywl/OMka96lkOf+TnsfwAqVgUPsq3YQlQ0pXvH6oDI8TWYELvNX5ct08HsRqPhfzxj5WxbQrbqLle4S2WvDvTOmDlSiqM7IYdQw5cu3hPN7h0ov+/1pyxW/LiPoV/XquRXR1bGUwwG0VuVz6fgLpTWC3gCTJ+1zebUFJwtw3F2PFqW1s1hTYkjd9tw//YcTv+SghrP2my+meZHtyEXYg9nnFpibRwfnX8uCWiF26dbOlJjVB0RhVEPYHz5E36Yq71mg7WmDtFJHfT4Aa4KWjXObtYk5dUXSimnHBfek/V88Rru342Em/Yc6lrO/iNUzRgDKH3ocDSMbrqggFjVmzdJKsbx487ZBn+hmrdozuE9cC989qel+hPacdygGaWt/rKAwAp4/3rNiapBmHdzHT+1W0aX03oBq7fkN6JXJ1301qZJLukWip8Q3zinx0Zx564pP UzM8sh5C lzGatwwI6PHOZVx+SbikXQZIgoRMOQmGsJYD8SU0B5a2ClIr/w81Li70gAAfnWUZ4FU1qL6mhn375MwC/vBcJNuigEia/oKuBaQEfWTq7UAUODFSCbUEd6lDeIi2DAvhXy7ERYzNsekHJafIeNZCq87E9m0/iz6dGPbAllVI8WimXwBSewUnC2WKdGlJYriMpx3doe/Q9MyJF4IJpqrsZcpGL20Rq5BWFekKwv7HGjxvu9nlNAUoRzOt4CxNHOXh9eQZFxoqgBpv1PNv13J6jQeI+g+0aH3OswnFEtGEdN2vyneFDYSS8C/UxT+HDcgijtiG8CeMm+edKCv0o3N9FMu9DcyDmjQ8VycJtA5cnqWn6I4cAUJYaLX3NM5FB0Ii2d3XtkyES5bWxnrY85PuN4NLO2Cqeftw9e56imPdv8s/TcyFDKNBJoVXEUH7tjjpstZDApuFwx+z/azGdRpDYxHM9S4OA928ZrvtXCo933cn5au6XxGZnJVinCkBiZy2gX5kb X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jun 19, 2023, at 12:17 PM, Kent Overstreet wrote: > On Mon, Jun 19, 2023 at 01:47:18PM +0100, Mark Rutland wrote: >> Sorry, but I do have an engineering rationale here: I want to make sure that >> this actually works, on architectures that I care about, and will be >> maintanable long-term. >> >> We've had a bunch of problems with other JITs ranging from JIT-local "we got >> the encoding wrong" to major kernel infrastructure changes like tasks RCU rude >> synchronization. I'm trying to figure out whether any of those are likely to >> apply and/or whether we should be refactoring other infrastructure for use here >> (e.g. the factoring the acutal instruction generation from arch code, or >> perhaps reusing eBPF so this can be arch-neutral). >> >> I appreciate that's not clear from my initial mail, but please don't jump >> straight to assuming I'm adversarial here. > > I know you're not trying to be adversarial, but vague negative feedback > _is_ hostile, because productive technical discussions can't happen > without specifics and you're putting all the onus on the other person to > make that happen. I'm sorry, but this isn't how correct code gets written, and this isn't how at least x86 maintenance operates. Code is either correct, and comes with an explanation as to how it is correct, or it doesn't go in. Saying that something is like BPF is not an explanation as to how it's correct. Saying that someone has not come up with the chain of events that causes a mere violation of architecture rules to actual incorrect execution is not an explanation as to how something is correct. So, without intending any particular hostility: bcachefs's x86 JIT is: Nacked-by: Andy Lutomirski # for x86 This makes me sad, because I like bcachefs. But you can get it merged without worrying about my NAK by removing the x86 part. > > When you're raising an issue, try be specific - don't make people dig. > If you're unable to be specific, perhaps you're not the right person to > be raising the issue. > > I'm of course happy to answer questions that haven't already been asked. > > This code is pretty simple as JITs go. With the existing, vmalloc_exec() > based code, there aren't any fancy secondary mappings going on, so no > crazy cache coherency games, and no crazy syncronization issues to worry > about: the jit functions are protected by the per-btree-node locks. > > vmalloc_exec() isn't being upstreamed however, since people don't want > WX mappings. > > The infrastructure changes we need (and not just for bcachefs) are > - better executable memory allocation API, with support for sub-page > allocations: this is already being worked on, the prototype slab > allocator I posted is probably going to be the basis for part of this > > - an arch indepenendent version of text_poke(): we don't want user code > to be flipping page permissions to update text, text_poke() is the > proper API but it's x86 only. No one has volunteered for this yet. > text_poke() by itself is *not* the proper API, as discussed. It doesn't serialize adequately, even on x86. We have text_poke_sync() for that. --Andy