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 C390FC77B7D for ; Mon, 15 May 2023 05:02:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 56529900003; Mon, 15 May 2023 01:02:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 514A7900002; Mon, 15 May 2023 01:02:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DD21900003; Mon, 15 May 2023 01:02:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2FAA9900002 for ; Mon, 15 May 2023 01:02:54 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E4F261C88E3 for ; Mon, 15 May 2023 05:02:53 +0000 (UTC) X-FDA: 80791294626.08.B97DFDF Received: from out-22.mta0.migadu.com (out-22.mta0.migadu.com [91.218.175.22]) by imf17.hostedemail.com (Postfix) with ESMTP id DF29D40006 for ; Mon, 15 May 2023 05:02:51 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=QJAzPvdo; spf=pass (imf17.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.22 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684126972; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=q2mGEUvyHwZiGTrF0TDmaBKI7TfcH+VD1Blkzm5ytFk=; b=YDIq3L5wtySdQs4q5q2ZpvvcnlXXDP5MS/mgoEAkPh3O0u+bNap16XHVwMuURvfsQbSgnU EwaXmHygaT7RZ/VuaqgLCqqEbWhs2EEH/15C/ZrlcqBiaCxTVvCtOV5SDjW+OxsQIc7yuR wpAJ4iFZz4GsLtWrvMHUCrDGe2gOpkg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684126972; a=rsa-sha256; cv=none; b=uaMG6z5MAhn3gr5LwIZf2FHNtTm3vT9C9JMFT5nG4TUsSo0+JhCN81nfWest0qEltnpYWZ 2k43xqrDWfFK534rb6st4WgVNKPW1hBaBWsp/xhfLs4Yo/n3Y1yEKOjQXpBtn/SK9zdt00 OT72BO5IZ7QNLbyOXu22rFIgPNiGqDE= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=QJAzPvdo; spf=pass (imf17.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.22 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Mon, 15 May 2023 01:02:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1684126969; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q2mGEUvyHwZiGTrF0TDmaBKI7TfcH+VD1Blkzm5ytFk=; b=QJAzPvdoQUkeyTUk6S2C+QWy4jL4zcmYveWG3SSgImiqUUCC42tKyxxcO2zjN7BKZll567 0ccXmBJd5mbCp9XkvCh9Jw/aMSC5/HQXIWaA8wvZfGp6/o4zsDQVFiMoWCF2m/8nSah/lp /VcUxVy7M0z3GWs4tmlJsv/ywE8JtAA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Christophe Leroy Cc: Lorenzo Stoakes , Christoph Hellwig , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-bcachefs@vger.kernel.org" , Kent Overstreet , Andrew Morton , Uladzislau Rezki , "linux-mm@kvack.org" 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> <8f76b8c2-f59d-43fc-9613-bb094e53fb16@lucifer.local> <6f049870-1684-1875-3cdc-73e1323ffdb0@csgroup.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6f049870-1684-1875-3cdc-73e1323ffdb0@csgroup.eu> X-Migadu-Flow: FLOW_OUT X-Stat-Signature: ra14nqwjnf1ibx8ahgb6yfrhpdfmzjut X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: DF29D40006 X-Rspam-User: X-HE-Tag: 1684126971-821755 X-HE-Meta: U2FsdGVkX1+oDmCfFlxxARrjR7Mx9am0UlvMCkrnCzHuHq2fTGqBtHmk6g9155SNKr4RC+84NdEPN4rzshj7IEcR8WkaudIPSQGxW1qXB5C2lfMaLx5ZmHvsMLF3N3odkXR6CJfD0y609QMo8T2e0cq9+0titC/7SgttM3LGNC42QxL1MA+MhOZlTupo4FWjQYGJxSwiq8sNUBZ1ISvAEgv9Pix3BKqrNmfqVVYAIhNvV8fo/Zns1/UhbOo1P4kXMWFEzEXmWJGN3kzj0KSf9WC7DX2zUBdYRv3xF8Meb001TbgmlVoiVJ9Eb0LBlj20VaSGh2UJwyNOYAwx+L5CcofezFpxRgxu+d+l/bKYq+BU0hBGT3AyRooy6nf6YDYlcu9cvCkSgcTiZITU398ZDdQAOCYfYDkkveBltYKZrlDfwvd+dii/iWvQauq1HVMrIlQss/DDue3SMUH6Nvcg27AUBnInvfxhO/s32/l9GCwcz2gF716mR2zc00634djMQY/8C2z5kEimQI+WDLUp79uoyvm4VPQ4R/lkhvvOdXV7cUeo78JnBJ8iagOFhzeRhlcQP2VoRS6EAWVJS+8+PipUHUWfcdwuJaOVQ8g6mik8beuggoCecCRNg4lMGxTGhC4OGHK7W4rH+7X7lUXs5mVVAuXZh9hntBXMoYWjhOUsyA15SOVa/cMV8BG4o5PRyXyG0oEbaq8M4JfkMiQmTJd5kCjFY2hSPvJEMV78rA0URrt7dtMY3m+DYyPIBexwtYAEGWT1pYtJP+D7JXbZ9vhTqk+P3d76TKIA06ukiNe3wDDjlUA8oI/bx/CwP1FSypzT9Y3De8+FSdTTGGmdy1ziPQcz/x/TBk7uv2Sn8x1PeDjSSFcAckFSxEwFudLqKQxF6VGWr5L8mdmtxFIUYpvckSx8AC+SQuFfxqy6pbcrxQ3v90jrFghXl5GlsF3lGGbp5CqXkFfYY+fPdY/ 0Nv3mWI3 7ZAmSoz/Qm51fn28VNqmiTtuzo8wxq9oIYjSZR2beSNizOp0Kl6EOiDMBQkXb2dX3VDvFmK6PR8rtuZYeSla4HLe1PVpjbkRWaVENYTJybypPXn96mlW0H1lGcAo/EodXBVHteFUWp+PS5H2tpv2ur0BGiISHx0+jpczlotGp4W6V3Qig4VT6c0TzqT33ag7d6acskep+Kwsk63I+e+c1TXqWbQ== 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, May 15, 2023 at 04:45:42AM +0000, Christophe Leroy wrote: > > > Le 15/05/2023 à 01:43, Kent Overstreet a écrit : > > On Sun, May 14, 2023 at 06:39:00PM +0000, Christophe Leroy wrote: > >> I addition to that, I still don't understand why you bring back > >> vmalloc_exec() instead of using module_alloc(). > >> > >> As reminded in a previous response, some architectures like powerpc/32s > >> cannot allocate exec memory in vmalloc space. On powerpc this is because > >> exec protection is performed on 256Mbytes segments and vmalloc space is > >> flagged non-exec. Some other architectures have a constraint on distance > >> between kernel core text and other text. > >> > >> Today you have for instance kprobes in the kernel that need dynamic exec > >> memory. It uses module_alloc() to get it. On some architectures you also > >> have ftrace that gets some exec memory with module_alloc(). > >> > >> So, I still don't understand why you cannot use module_alloc() and need > >> vmalloc_exec() instead. > > > > Because I didn't know about it :) > > > > Looks like that is indeed the appropriate interface (if a bit poorly > > named), I'll switch to using that, thanks. > > > > It'll still need to be exported, but it looks like the W|X attribute > > discussion is not really germane here since it's what other in kernel > > users are using, and there's nothing particularly special about how > > bcachefs is using it compared to them. > > The W|X subject is applicable. > > If you look into powerpc's module_alloc(), you'll see that when > CONFIG_STRICT_MODULE_RWX is selected, module_alloc() allocate > PAGE_KERNEL memory. It is then up to the consumer to change it to RO-X. > > See for instance in arch/powerpc/kernel/kprobes.c: > > void *alloc_insn_page(void) > { > void *page; > > page = module_alloc(PAGE_SIZE); > if (!page) > return NULL; > > if (strict_module_rwx_enabled()) > set_memory_rox((unsigned long)page, 1); > > return page; > } Yeah. I'm looking at the bpf code now. Can I just say, for the record - god damn this situation is starting to piss me off? This really nicely encapsulates everything I hate about kernel development processes and culture and the fscking messes that get foisted upon people as a result. All I'm trying to do is write a fucking filesystem here people, I've got enough on my plate. Dealing with the fallout of a kernel interface going away without a proper replacement was NOT WHAT I FUCKING HAD IN MIND? 5% performance regression without this. That's just not acceptable, I can't produce a filesystem that people will in the end want to use by leaving performance on the table, it's death of a thousand cuts if I take that attitude. Every 1% needs to be accounted for, a 5% performance regression is flat out not going to happen. And the real icing on this motherfucking turd sandwich of a cake, is that I'm not the first person to have to solve this particular technical problem. BPF has the code I need. But, in true kernel fashion, did they recognize that this was a subproblem they could write as a library, both making their code more modular and easier to understand, as well as, oh I don't know, not leaving a giant steaming turd for the next person to come along? Nope. I'd be embarassed if I was responsible for this.