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 92129C433FE for ; Wed, 16 Nov 2022 01:21:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E1BD16B0073; Tue, 15 Nov 2022 20:21:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DCC056B0074; Tue, 15 Nov 2022 20:21:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC5B78E0001; Tue, 15 Nov 2022 20:21:11 -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 BDC136B0073 for ; Tue, 15 Nov 2022 20:21:11 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 887FB1C69E9 for ; Wed, 16 Nov 2022 01:21:11 +0000 (UTC) X-FDA: 80137551942.09.153AE44 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf10.hostedemail.com (Postfix) with ESMTP id D5D43C0004 for ; Wed, 16 Nov 2022 01:21:10 +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 ams.source.kernel.org (Postfix) with ESMTPS id B3539B81B95 for ; Wed, 16 Nov 2022 01:21:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B3F2C43141 for ; Wed, 16 Nov 2022 01:21:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668561667; bh=HPqSwtnsmvwz/eW+Mmf5+RnJY7HuFktOa5yX14Ed7LM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ogNeepUbx4ycRs7rkijwdNMMjenRJ7ktYqIqBHZ3+8d9pXOYOER27DbiyVxFqzkaf sK7dBRdeyDh5WmW6Z1Msj21RLfC/7JZGgPM1VXOZ3bltDMzZKD+1/5bXOF7REtmqPF nlY69skj6mwy9QcYAX+hvytwqkCV05dfa3Ypp9AA4fvevz6pbC2dRsMqAL31IaV9qZ xT0ReD/xHjIs9uWFLREaWSCSXNEo/EdOZjL4gFUNIVNmOqaCAf9+wSUJtUtqfzFEwn h1roVBjh8rIwxp6+e1Egs2gdcoIPQROw/keNZ/eftt7QJR/tlz/IyBBty/EsfESqOY k2XkjT0JoT7Kw== Received: by mail-ed1-f41.google.com with SMTP id z18so24440886edb.9 for ; Tue, 15 Nov 2022 17:21:07 -0800 (PST) X-Gm-Message-State: ANoB5pm/2OdZkGqzV8939++yNOBSKtmwIkzTZ3/eWe3G1GhAnupzgcZt sjKuaa8dcXn4q7YW8hJsj8FoE0uheMhj5BifWV4= X-Google-Smtp-Source: AA0mqf7gEknKqMKDRE7Lw2a12ouFxnXF1mlyTLNDq1SQ+e7WcGJ0EcOvuMxWLRCAkNh28uhLFAEQbiIvDlIJX0i3/4A= X-Received: by 2002:aa7:c6d9:0:b0:462:2c1c:8791 with SMTP id b25-20020aa7c6d9000000b004622c1c8791mr17503929eds.29.1668561665575; Tue, 15 Nov 2022 17:21:05 -0800 (PST) MIME-Version: 1.0 References: <20221107223921.3451913-1-song@kernel.org> <4bf1a1377ea39f287a4fd438d81f314d261f7d7f.camel@intel.com> In-Reply-To: <4bf1a1377ea39f287a4fd438d81f314d261f7d7f.camel@intel.com> From: Song Liu Date: Tue, 15 Nov 2022 17:20:53 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs To: "Edgecombe, Rick P" Cc: "peterz@infradead.org" , "rppt@kernel.org" , "bpf@vger.kernel.org" , "linux-mm@kvack.org" , "hch@lst.de" , "x86@kernel.org" , "akpm@linux-foundation.org" , "mcgrof@kernel.org" , "Lu, Aaron" Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668561671; a=rsa-sha256; cv=none; b=piAGfdkjPrmwN6OvMD3IHvgWM7HSfDjvh/PL/9s6pRdy8PeD1xZ1tHQ9t8cnGBFw6xuaUe IAkBUf4ihB5tsS0HQP7uPjliZm1mItNSU52QqxZ/L2LxnQjU44UgiwbRNXMlJ1DCQViYeu bE97vghuQKHv39d8T8vqQAsAAIfwSJQ= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ogNeepUb; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf10.hostedemail.com: domain of song@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=song@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668561671; 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=2M1D7rfvL7hbWQnNJOkFgOI0clJqbmsz9B2hLRXYDp0=; b=br1n88nDDLkHR1UwYrXGvtFJBez5usuNWxIlgI1EhhXAV8uzRAE2aLQzhfJAxoAGnuRPk4 6Z3mUFf5aWAkix6OQg8Y4Iyd5+7poQtA3D6SMXBS/kRPkOZtHUakaD4jQpRkIwxPsZaRdI RkCL5oV1iPUkOHSkl5VtP5f1e2omVbA= X-Rspamd-Queue-Id: D5D43C0004 Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ogNeepUb; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf10.hostedemail.com: domain of song@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=song@kernel.org X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ohgqkhhs8ic5x3issu3ozrdt4kygtgqb X-HE-Tag: 1668561670-24059 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, Nov 15, 2022 at 2:14 PM Edgecombe, Rick P wrote: > > On Tue, 2022-11-15 at 13:54 -0800, Song Liu wrote: > > On Tue, Nov 15, 2022 at 9:34 AM Edgecombe, Rick P > > wrote: > > > > > > On Mon, 2022-11-14 at 17:30 -0800, Song Liu wrote: > > > > Currently, I have got the following action items for v3: > > > > 1. Add unify API to allocate text memory to motivation; > > > > 2. Update Documentation/x86/x86_64/mm.rst; > > > > 3. Allow none PMD_SIZE allocation for powerpc. > > > > > > So what do we think about supporting the fallback mechanism for the > > > first version, like: > > > > > > > https://lore.kernel.org/all/9e59a4e8b6f071cf380b9843cdf1e9160f798255.camel@intel.com/ > > > > > > It helps the (1) story by actually being usable by non-text_poke() > > > architectures. > > > > I personally think this might be a good idea. We will need this when > > we use > > execmem_alloc for modules. But I haven't got a chance to look at > > module code in > > great detail. I was thinking of adding this logic with changes in > > module code. > > BPF used to have a generic allocator that just called module_alloc(). > If you had a fallback method could you unify all of BPF to use > execmem()? To clarify, are you suggesting we need this logic in this set? I would rather wait until we handle module code. This is because BPF JIT uses module_alloc() for archs other than x86_64. So the fall back of execmem_alloc() for these archs would be module_alloc() or something similar. I think it is really weird to do something like void *execmem_alloc(size_t size) { #ifdef CONFIG_SUPPORT_EXECMEM_ALLOC ... #else return module_alloc(size); #endif } WDYT? Thanks, Song