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 36117EB64D9 for ; Mon, 19 Jun 2023 19:17:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6465D8D0002; Mon, 19 Jun 2023 15:17:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F6698D0001; Mon, 19 Jun 2023 15:17:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BE618D0002; Mon, 19 Jun 2023 15:17:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3934B8D0001 for ; Mon, 19 Jun 2023 15:17:50 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DDEC7AFEEB for ; Mon, 19 Jun 2023 19:17:49 +0000 (UTC) X-FDA: 80920457058.10.93A1A73 Received: from out-42.mta1.migadu.com (out-42.mta1.migadu.com [95.215.58.42]) by imf04.hostedemail.com (Postfix) with ESMTP id E1A954001D for ; Mon, 19 Jun 2023 19:17:47 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=W7xeUfMh; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf04.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.42 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687202268; 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=kyPXfpVQ4C+B8nMExw9vaxU/T8HvIqFX6/+tZpsWRZk=; b=7q3rbtsDWJSjwizfpihewWS6fB3G3XIkT74/N3K6vBJkifkUJOiMpjOFu2pyTIgxif3AQr YHUindhxzpM85XiYAZti5SnPzN6S+V8ksOVioUWrgEAK8FVtyZbSXa+ZVQ0RX28MWF4t9a Lvpt/d6JdjODnundv8VoSNlSfC18zCo= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=W7xeUfMh; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf04.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.42 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687202268; a=rsa-sha256; cv=none; b=FjT4LZN8Ts+p6LubLkosVvFjr6DodUSFeBdx4543oXl8XO159z58UMmx1Q7/CoeFLiPsra 25TuFw2QwT8wHap/AKvajy4sxW5B8FW1cj53GVsh6yQodq1fd0UZag4qK2OeGNhQ9zP6BM Iqk7QeCOsbvDQye4OJvqgVx33qBZzjg= Date: Mon, 19 Jun 2023 15:17:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1687202265; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kyPXfpVQ4C+B8nMExw9vaxU/T8HvIqFX6/+tZpsWRZk=; b=W7xeUfMhioXlZpOSNVtKa+8xBg0rix59OVcvUz35FaQQkLVc47A7lTZtgKbJBJG24Mk9tl m35qopb39p/Ct2MnipRlyA/LcAg0HZiWjSxkZeLfnuuhcbqmaQ9YzzJ/82jSptrRvF4VG1 bjM/b2Ad03rEpWR1gMybH8+6KcYzd+M= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Mark Rutland Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-bcachefs@vger.kernel.org, Kent Overstreet , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , linux-mm@kvack.org, Kees Cook , Andy Lutomirski Subject: Re: [PATCH 07/32] mm: Bring back vmalloc_exec Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E1A954001D X-Stat-Signature: 4xxseppk53hoctcsdocebq6adbotmf44 X-HE-Tag: 1687202267-309294 X-HE-Meta: U2FsdGVkX1+Y9gjKj8aSDVGIeE5tl+3IW0b8fM/80OoI1kIA29WmBq/9Zp0JM/CqOjeZymD5ndzXoFFVcH7m+y5LCbe6TL9N0ZK1elspRv6I8T8ETcDmOdA4XIPEqy0SlEbZOr6829/z8pVeYfeJ1TDm7LhZ2qGfPj5oSyiymKd3t8kMy/DR8M2OTqbAd3T04dx2LUcIAfRI0LaHdXSww2yjgdobEQ7leGV55YpNiw3SHkJHtMlQM+vF+iiOKU7Jw3PoHASeyUakFEe+nzsOSR0GVe6e3DhmqquXcEdXj1AmmUxguaCNQ8bNe4i25jyngHwELVVlRUPw+eHheOyJfgUUZeLInh2iW0bF+l3s6Dg4iT6CM595RxmKBcNicwv5nRdmeK/bHjb+YjYiXPzlbb6LR7xHR5+TI43yhTQjjXNf2nr0rGHmt1feOy6b0V1eBljR5sq3OGloMW8TfYwt7DSSj1jtQpsxXutS0bUiVv3pZMo01tT49qEkYU/oB6V2YGTaQfX5pMgZh5Jpb2PGMFu4jnv4dtdSmxiSlmgUaL7g01mKgCdtCXjnOV8YG4klakTAdRNInIPHTbYJIpUfXcEp9af6cWDF+P+1vUXL6AbRebo+T9C57cU2aRkDK6SRclTEmrp/7BjB1+oJNoGk0DuP3NdIMoshRoGStK20F1X8dQluw875h/MmoIoV60CdN106myGKdUzTpZ5ioOnqY2xuRvFoHQMpYLUCd9DEv7DXXwFW8f+edMV6GtOr0DWCRZQFHWEyMVYQMSYjj4/EVgGa9S0yvrzcwY9gi18z3eXDA0wHOII0WMlPweznpV6aNFC2oZ8sionr9h2Ete0HpWjP24cVLd3rBULMULFmxDcvihIPlmrW+Hc04d0jGRr9z3qgpOB6206JmsoUR17DLjkAdD2rBQSGzUiZ6dfxL1/Ga1X9WCk+xmyTRp+j35XrTEXLOTl5V/nBoXF/+gs 2Ruk8umb cDltW2rvlrv4EX8JM7JlRqZ+ker4BfQy1XCK1jc1D4bVVzeJ2smzzlwv5+mBvEAgjzDIy4Cv0I0bh3Ownyne7K2irzOC6pTcR7LR7//ZBYDs16doocd2pHmNLULTeqVhKnlCxAqi0CkChHhproS01mbgEvoPq6fDCvISQ/VL1G/otJn4= 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 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. 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. Re-using eBPF for bcachefs's unpack functions is not outside the realm of possibility, but BPF is a heavy, complex dependency - it's not something I'll be looking at unless the BPF people are volunteering to refactor their stuff to provide a suitable API. > One thing I note mmediately is that HAVE_BCACHEFS_COMPILED_UNPACK seems to be > x86-only. If this is important, that'll need some rework to either be > arch-neutral or allow for arch-specific implementations. Correct. Arm will happen at some point, but it's not an immediate priority.