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 EFB46C7EE22 for ; Tue, 9 May 2023 21:54:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 47F106B0071; Tue, 9 May 2023 17:54:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 42FC36B0072; Tue, 9 May 2023 17:54:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 31E426B0074; Tue, 9 May 2023 17:54:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 23BDF6B0071 for ; Tue, 9 May 2023 17:54:33 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DCDB2C09CE for ; Tue, 9 May 2023 21:54:32 +0000 (UTC) X-FDA: 80772071184.20.EF8B4B0 Received: from out-42.mta1.migadu.com (out-42.mta1.migadu.com [95.215.58.42]) by imf06.hostedemail.com (Postfix) with ESMTP id E6691180013 for ; Tue, 9 May 2023 21:54:30 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=DnM8qOme; spf=pass (imf06.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.42 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683669271; a=rsa-sha256; cv=none; b=onrJ7uFCc6IC/l3EnCHw40dXNDbxQPdChG3bFDWQjFNXh/Q6k/3X+iaE77iYA5uHBHzSO4 Ok2m3fw82nvk1tedmo0bw/uysu1p6XJ0CH8shF7xVQd0otZ7PPIUkG12j+O0CwzV25NZGF msBZz+p/TZYlAaOwKyje7TL/PiYUigM= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=DnM8qOme; spf=pass (imf06.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.42 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=1683669271; 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=1n3YMxW+Zb7xSLAr/eeZIRD4PtBRt8sxu+5EqSQhpSY=; b=ToRtS5nwJ+gq+O82wKtdbo1pi/7ifSbN77X8oXMnH4LgeHTH867U+xp+fBkdlxP1DPq4qJ FvLK959FS8CfnVnPQsz5hqWWoFiIDIPePRxppmzvsheh5zC4Alh6P26uMpIBj9uEW1FmIZ zisO6HXS8iwn9qojOSFtoM8Tt93avA4= Date: Tue, 9 May 2023 17:54:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1683669269; 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=1n3YMxW+Zb7xSLAr/eeZIRD4PtBRt8sxu+5EqSQhpSY=; b=DnM8qOmeFjElK/7kmR9lrk8seVkOltc4T81yq9nzxwJ0tWrpzuZjphK0O0rFxUZuREoLjH 4BGrtcWLzxP0pNXP/Rrv20VFYXzZePCsv+ToELAp1vj4npjoYANBuaQ9qfSjDvpQsbPq+u I+IxdbTG3un3iPQvVU9g3Lw60JsigXg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: "Darrick J. Wong" 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> <20230509214319.GA858791@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230509214319.GA858791@frogsfrogsfrogs> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Stat-Signature: 1apoojm84oxf6h4ajfbzkjea5ukrtznm X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: E6691180013 X-HE-Tag: 1683669270-784847 X-HE-Meta: U2FsdGVkX19dootbxhVd7qvPaC3nXpEpwK2ASOG7yvW1A4uyyBblnfuC4Q+4ZhaN7AcujeN/doy3bsDAYflw0GGx05l7LEwPN0gUNQ8L+vY7bd42u9HshWGdqVJfqZAb+OM1l6ejg06xJVmzi+MOIlFuWB9FO8jYkOq4WT+9jY8jEkMnhRZEAlLBSaCXcW15x4dxNRD8QUHh/67V3F3DhNHuYn6UbXkhfEhBsKOWYoDcHFec4yyyjDzFAL2b1wcovlMpQmceMFE9S+5+27+/vAqcmLpUYEcRzTDE5jozEHHipibxXdw6NHz0aQ/YOngbSOiHRfrBiiCUSvHwl95N4aQv1BwusXWqKteY8ax5GKyQ4vKEnA8CitQ/zO9VPN/TqXJurwdaDVFo+qsvra0/H9st8EYN2PHqt0ZwGqNJvelunmfSAfs+V1apprqZxdl8q0vpTekAgBTsC2aPhBjoMTly9RLx7b+sD+9jL0yKrRp+ADXX57GbFhYUIOrOJ+tnvxIqWevCbTGr8WV39edRkoe1Z9aGp33J+4l2XZKQTlHqK/Uysxumqf2IhhlvjHYyU/KxgWVHrzpXveijGTuR97OBPqydIznQf6ygG45uwHqQO+dLYJC891kg4wcJNtECX4rVbyauak4HnD/1j1NEqiDs3ZLvqiWIayCC+KYt8YAqrGIzq2l5qkXS95elcHZdCp8r2X+C7J+mDbQuw8uF+FTe96cmoc/ss1dVicrlshF7zY43f8o2s+jPpLPlShfOtIieFkeLtTeQ4L4NbYVyeizLrLTYLAYPBFEOpUYlT085G9axUwOFUhEVUd5OpACb69TcuBIDdRGDVvBDZooMcpl7Sf+4Hu0HG6v7SVbWnwg7xPF/nNJvo5Lb8n1D7ngpGEO01jHAuoSCvcHWWcJ7Oq6f7A6VVwn0Du3haDB4hiSakeAZ1fVvq7qNKKF3QreUPLA5BT8IWL5m6N0dYeU +tYddlo9 BqQu3r2sTBRfBuPYWaKLcNeNfLyXbm6kdU0WvgsN1EWpEl/+IuWrFHISCHkiuA1cz4rmsNSXfOo010l3xAfwXIv6KBLtyWgY0AT7UycmYYwJ2z9Rub9gLdGWXSKi+lC6vyEGCtsEpWYrMzdTBEwnqeCM00V+Fh5j59sX3FCU8cnklU+uXubGlXELVqJBpgV+kFIHU 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 Tue, May 09, 2023 at 02:43:19PM -0700, Darrick J. Wong wrote: > On Tue, May 09, 2023 at 02:12:41PM -0700, Lorenzo Stoakes wrote: > > On Tue, May 09, 2023 at 01:46:09PM -0700, Christoph Hellwig 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. > > > > > > No, we will never add back a way for random code allocating executable > > > memory in kernel space. > > > > Yeah I think I glossed over this aspect a bit as it looks ostensibly like simply > > reinstating a helper function because the code is now used in more than one > > place (at lsf/mm so a little distracted :) > > > > But it being exported is a problem. Perhaps there's another way of acheving the > > same aim without having to do so? > > I already trolled Kent with this on IRC, but for the parts of bcachefs > that want better assembly code than whatever gcc generates from the C > source, could you compile code to BPF and then let the BPF JIT engines > turn that into machine code for you? It's an intriguing idea, but it'd be a _lot_ of work and this is old code that's never had a single bug - I'm not in a hurry to rewrite it. And there would still be the issue that we've still got lots of little unpack functions that go with other tables; we can't just burn a full page per unpack function, that would waste way too much memory, and if we put them together then we're stuck writing a whole nother allocator - nope, and then we're also mucking with the memory layout of the data structures used in the very hottest paths in the filesystem - I'm very wary of introducing performance regressions there. I think it'd be much more practical to find some way of making vmalloc_exec() more palatable. What are the exact concerns?