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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71DBFEB64DB for ; Mon, 19 Jun 2023 12:47:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230406AbjFSMr3 (ORCPT ); Mon, 19 Jun 2023 08:47:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229767AbjFSMr2 (ORCPT ); Mon, 19 Jun 2023 08:47:28 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6CA31113; Mon, 19 Jun 2023 05:47:25 -0700 (PDT) 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 E311112FC; Mon, 19 Jun 2023 05:48:08 -0700 (PDT) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.36.163]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8FF033F64C; Mon, 19 Jun 2023 05:47:23 -0700 (PDT) Date: Mon, 19 Jun 2023 13:47:18 +0100 From: Mark Rutland To: Kent Overstreet 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: 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: <20230619104717.3jvy77y3quou46u3@moria.home.lan> Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Jun 19, 2023 at 06:47:17AM -0400, Kent Overstreet wrote: > On Mon, Jun 19, 2023 at 10:19:00AM +0100, Mark Rutland wrote: > > On Tue, May 09, 2023 at 12:56:32PM -0400, Kent Overstreet wrote: > > > From: Kent Overstreet > > > > > > This is needed for bcachefs, which dynamically generates per-btree node > > > unpack functions. > > > > Much like Kees and Andy, I have concerns with adding new code generators to the > > kernel. Even ignoring the actual code generation, there are a bunch of subtle > > ordering/maintenance/synchronization concerns across architectures, and we > > already have a fair amount of pain with the existing cases. > > Look, jits are just not that unusual. I'm not going to be responding to > vague concerns that don't have any actual engineering rational. 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. > > Can you share more detail on how you want to use this? > > > > From a quick scan of your gitweb for the bcachefs-for-upstream branch I > > couldn't spot the relevant patches. > > I've already written extensively in this thread. Sorry, I hadn't seen that. For the benefit of others, the codegen is at: https://lore.kernel.org/lkml/ZFq7JhrhyrMTNfd%2F@moria.home.lan/ https://evilpiepirate.org/git/bcachefs.git/tree/fs/bcachefs/bkey.c#n727 ... and the rationale is at: https://lore.kernel.org/lkml/ZF6HHRDeUWLNtuL7@moria.home.lan/ 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. Thanks, Mark.