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 A283CC433FE for ; Thu, 17 Nov 2022 08:50:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 278306B0072; Thu, 17 Nov 2022 03:50:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2299C8E0001; Thu, 17 Nov 2022 03:50:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 117FD6B0074; Thu, 17 Nov 2022 03:50:18 -0500 (EST) 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 F21DF6B0072 for ; Thu, 17 Nov 2022 03:50:17 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BE7F4A0D15 for ; Thu, 17 Nov 2022 08:50:17 +0000 (UTC) X-FDA: 80142312474.12.F529166 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf02.hostedemail.com (Postfix) with ESMTP id 555068000A for ; Thu, 17 Nov 2022 08:50:17 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 626506210E; Thu, 17 Nov 2022 08:50:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B9D1C433D7; Thu, 17 Nov 2022 08:50:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668675015; bh=0cv6ecQvsQeiZ/g/IAt6E+nml0CMo7hBuCz/4hvUNd4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aXHQWEGDEbSgK4prgoQE6YqukkFtBwSq/vS1PL2LU3UceSDWQodBS44dapBqpLpAm kBqqoXoz4HzSKO/aT9/AV1yzgxWIbH6MMxUxWqgi38fK09mTMHcHMQAteYsF5FmSxn sXnTU1ALae71TKe2L3hCQoQii4JI5TtcViwdnVMf/QS27P/G2kpNMEaQ3KgKNrwVjy 14P8+Coq1OTwErtpqMY+mUk5VldjE+g3fdrawl7+g5OE9MghnnO0dFkA3gZiRRTAAh 2nLqkv5v1hNMWQ/SCrkQ2144oFm9jpOUc6hiYbWnZo+jgAl3FpOiANqhtA4l3vyvso lCBAoYREfiODQ== Date: Thu, 17 Nov 2022 10:50:00 +0200 From: Mike Rapoport To: Song Liu Cc: "Edgecombe, Rick P" , "peterz@infradead.org" , "bpf@vger.kernel.org" , "linux-mm@kvack.org" , "hch@lst.de" , "x86@kernel.org" , "akpm@linux-foundation.org" , "mcgrof@kernel.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=1668675017; a=rsa-sha256; cv=none; b=2b9RGwLw/Jogx9a9Jj76i+TR8M1+AlaxzEU1RKb1w5euHQ7PAdZlLMCJ9lZuJzOXxhmlRe rKOfLlmBGgLlmLbDAPrwuz1voemli2mhKo5Fhb57MXiUC7S2fQY89T2+vMv/1QwcDHJBEK vGH/z2dVRd6xlnD4CheS5xYjuLF7wBE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aXHQWEGD; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668675017; 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=5Os2jXR4ipiuMHL3z9t9eKnLCwY46rX8We2TDRirp6w=; b=z4jrtIC/xpKu5J+zvP3laGSlJaQKpXA3J6y+eaJtfgBxuT+foSQWXGfk+D3NJOGPXDKIGO KCr3u6vFXsHxtSScBSM1Dv0UKat1DfPEKcZPkf+f6ECKTL3QBYs8FFbreX4grnQ/mUjiBV misanZBXi2cYjo0S4ZWL6bWo3c1p7JY= X-Stat-Signature: 6dibdbeaz7f349snabmdp1xmd7hiisoo X-Rspamd-Queue-Id: 555068000A X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aXHQWEGD; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Rspamd-Server: rspam09 X-HE-Tag: 1668675017-304410 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, Nov 14, 2022 at 12:30:49PM -0800, Song Liu wrote: > On Sun, Nov 13, 2022 at 2:35 AM Mike Rapoport wrote: > > > > 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. Again, it's a gut feeling. But for execmem_alloc() to be a unified place of code allocation, it has to work for all architectures. If architectures have to override it, then where is the unification? The implementation you propose if great for x86, but to see it as unified solution it should be good at least for the major architectures. > > It feels to me that a lot of ground work is needed to get to the point > > where we can use centralized handling of loading text. > > Could you please be more specific on what is needed? The most obvious one to implement Peter's suggestion with VM_TOPDOWN_VMAP so that execmem_alloc() can be actually used by modules. > Thanks, > Song -- Sincerely yours, Mike.