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 BE2CCC433FE for ; Tue, 15 Nov 2022 21:18:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B7DC6B0071; Tue, 15 Nov 2022 16:18:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 141906B0072; Tue, 15 Nov 2022 16:18:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F23458E0001; Tue, 15 Nov 2022 16:18:51 -0500 (EST) 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 DE65B6B0071 for ; Tue, 15 Nov 2022 16:18:51 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B30741202B6 for ; Tue, 15 Nov 2022 21:18:51 +0000 (UTC) X-FDA: 80136941262.23.A2DAFF4 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf13.hostedemail.com (Postfix) with ESMTP id 6148120003 for ; Tue, 15 Nov 2022 21:18:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=PTyeKdb3/txpXvphlUoCQiFR4/5ocBSBLSRXjYf6Ong=; b=z7OdM20wk+Np7ESx4LDk4+pOzg DaF8BA16/aqpCjYAMCsVcOf0evn61rjvG2U9y7uWeTCAVqye9sHUkpJ3GU9aLrRCS9fyN++18/FTe ljpQZdA6N+44Z1eIzwMbUf3FvhizlK0sQU5M6FN9qRBh0INSZKnEdJ41/GaqR0OS5lIoqQ/0qNjPl LfYzGxwKejdu48NjIPzS3nE7hvd0cX6/3lgypT0Ft6qxLS9Tdvd87ZjW3/cxd6vLsIHPX8YEhhPZc uLYiaPTCftdAwhdONpLcPn2bryU6wZmz0wkmslQ1uWk2yGSsC0Xt8m1gFF8VpITk+1jFJ6kQDKFO7 EG1pV9ZQ==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1ov3KO-00F1vH-TE; Tue, 15 Nov 2022 21:18:44 +0000 Date: Tue, 15 Nov 2022 13:18:44 -0800 From: Luis Chamberlain To: Song Liu Cc: Mike Rapoport , "Edgecombe, Rick P" , "peterz@infradead.org" , "bpf@vger.kernel.org" , "linux-mm@kvack.org" , "hch@lst.de" , "x86@kernel.org" , "akpm@linux-foundation.org" , "Lu, Aaron" Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs Message-ID: References: <20221107223921.3451913-1-song@kernel.org> <9e59a4e8b6f071cf380b9843cdf1e9160f798255.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668547131; a=rsa-sha256; cv=none; b=QWWFrWSB3OG2ZInlAJmQ8esvUerblqKLNRZ/qFrsgbt/D/0n39IDQKCIvvT6hM/0VXg24U LzJ5gE/yQ/2IfoZx+TkxLdeKHM0fyckWCln85JZvSb5EndZ/+po1Mwfm7H9iG1/JQviPyC mSSFd6divQgQldotiUHIz76MmbypQ4M= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=z7OdM20w; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=none (imf13.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668547131; h=from:from:sender: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=PTyeKdb3/txpXvphlUoCQiFR4/5ocBSBLSRXjYf6Ong=; b=OfATHdAXr+TZ3r3VH1KbQxz9PypMbOkoDCBoO5NpKtu8LbK0I0xQq6apiQ2V2MnRVTDF0r XOGeIkGet8Hw5PwtjaVrjO0ljgDUlVEh3T5YORgE9hr5TS+OlNUUmHPI0Vh3mf4CugwsMn R9kjdO6i8y4/LWGsXaVW4IMhyRvdojM= X-Rspamd-Queue-Id: 6148120003 X-Rspam-User: Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=z7OdM20w; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=none (imf13.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org X-Rspamd-Server: rspam06 X-Stat-Signature: s9qzhpsfnopzzsxcgyhwziqy3irnqaio X-HE-Tag: 1668547131-823046 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Nov 14, 2022 at 12:30:49PM -0800, Song Liu wrote: > On Sun, Nov 13, 2022 at 2:35 AM Mike Rapoport wrote: > > > > On Wed, Nov 09, 2022 at 05:04:25PM +0000, Edgecombe, Rick P wrote: > > > On Wed, 2022-11-09 at 13:17 +0200, Mike Rapoport wrote: > > > > On Tue, Nov 08, 2022 at 04:51:12PM +0000, Edgecombe, Rick P wrote: > > > > > > > How the caching of large pages in vmalloc can be made useful for use > > > > cases like secretmem and PKS? > > > > > > This part is easy I think. If we had an unmapped page allocator it > > > could just feed this. > > > > The unmapped page allocator could be used by anything that needs > > non-default permissions in the direct map and knows how to map the pages > > elsewhere. E.g it would have been a oneliner to switch x86::module_alloc() > > to use unmapped allocations. But ... > > > > > Do you have any idea when you might pick up that stuff again? > > > > ... unfortunately I don't see it happening anytime soon. > > > > > To answer my own question, I think a good first step would be to make > > > the interface also work for non-text_poke() so it could really be cross > > > arch, then use it for everything except modules. The benefit to the > > > other arch's at that point is centralized handling of loading text. > > > > My concern is that the proposed execmem_alloc() cannot be used for > > centralized handling of loading text. I'm not familiar enough with > > modules/ftrace/kprobes/BPF to clearly identify the potential caveats, but > > my gut feeling is that the proposed execmem_alloc() won't be an improvement > > but rather a hindrance for moving to centralized handling of loading text. > > I don't follow why this could ever be a hindrance. Luis is very excited about > this, and I am very sure it works for ftrace, kprobe, and BPF. The main hurdles for modules are: * x86 needs support for CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC to use this properly * in light of lack of support for CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC we need a fallback * today module_alloc() follows special hanky panky open coded semantics for special page permissions, a unified way to handle this would be ideal instead of expecting everyone to get it right. Other than this there are probably odd corner cases which would likely only come up during testing. I see Song's efforts striving towards these objectives, and because of the new ARCH_WANTS_MODULES_DATA_IN_VMALLOC, it should be possible to get us there. Luis