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 D74FFC4708D for ; Wed, 7 Dec 2022 20:57:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5D7DA8E0006; Wed, 7 Dec 2022 15:57:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 55FE58E0001; Wed, 7 Dec 2022 15:57:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DA298E0006; Wed, 7 Dec 2022 15:57:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2ADBE8E0001 for ; Wed, 7 Dec 2022 15:57:09 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 03CA5A0E91 for ; Wed, 7 Dec 2022 20:57:08 +0000 (UTC) X-FDA: 80216720178.11.A3B5003 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf23.hostedemail.com (Postfix) with ESMTP id F14CB140007 for ; Wed, 7 Dec 2022 20:57:06 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=1mDnIOdV; dkim=pass header.d=linutronix.de header.s=2020e header.b=8YAU1+Yx; spf=pass (imf23.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670446627; 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=j4jZkbcuJIwiAgf91WY2daretNxTTG2dG6tHKPWxG5s=; b=0OEJi9dGuLbw0Nv8vi4pr5LmGs3iVKB/sAbzvdcbQlLF7IeQ2aWFsyNfv2wWbTDhB3uXWz vdg+c0HSV6pfJVfAOJb9//xcapfqq4quJkf/e7E+ks+M4NA4W386ZEAmrK+ExUUZwMg91G r69xWCQLK9yFvKuCgXtEtmWkxpVfKHM= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=1mDnIOdV; dkim=pass header.d=linutronix.de header.s=2020e header.b=8YAU1+Yx; spf=pass (imf23.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670446627; a=rsa-sha256; cv=none; b=CGt8GoNf7Kw59pGoGRnhIdEbjXnXoEF4Bq1pHcKBYC0tFNio4A4VxeR9gjlW1Gw6pItfEP XHrUbkBUtpiUoPkFfNhpJbb554mko6aCtMIA+usEqn5FTGCSSUL/HkbYoOjyhrprn4Dcor rrQs2UxN0m2JO96HGwLu3CWfEA5IX5E= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1670446624; 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=j4jZkbcuJIwiAgf91WY2daretNxTTG2dG6tHKPWxG5s=; b=1mDnIOdVFdENa9SioPfbGoLSFBWnnRIl0+5DUev/kW7WYKbi+3gEXdtGKSmTtaDemhwEER achgTAb/z3y6dkIMuDTM57GI/c/rpZfCkxQUztCRa/fJ1tMJ3ydO8DOHQPLbUEDHpIoxPo z6Y2Oie9BCMT0B5Yk6Wa0aPPVHAwXYvJJ47fF0+0ql6u1uRug6uLzFYneICNkOjwD72aGE PpZEzd0nDGds1GQ+8S2IEyeoKdqq8sdxlHR43ukkGLato/G52ppFCilujz7L4POv/kLv6j tQzM+DQ6xssbeq8Ai7W65gC/LIFYxM2fbq9DAwgafeQpgHg0W2u2+pcAr134Wg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1670446624; 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=j4jZkbcuJIwiAgf91WY2daretNxTTG2dG6tHKPWxG5s=; b=8YAU1+YxLGwjaU83ja4X7yCURRPxwpv6QaOXOrtX7dhXDjGuNPIFGelH7wWze2TszQBJ6p /BlIz8UDMyBNdaBQ== To: Song Liu Cc: bpf@vger.kernel.org, linux-mm@kvack.org, peterz@infradead.org, akpm@linux-foundation.org, x86@kernel.org, hch@lst.de, rick.p.edgecombe@intel.com, aaron.lu@intel.com, rppt@kernel.org, mcgrof@kernel.org, Dinh Nguyen Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs In-Reply-To: References: <87v8mvsd8d.ffs@tglx> <87k03ar3e3.ffs@tglx> <878rjqqhxf.ffs@tglx> <87v8mndy3y.ffs@tglx> Date: Wed, 07 Dec 2022 21:57:04 +0100 Message-ID: <87k033dja7.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Result: default: False [-0.38 / 9.00]; SUBJECT_HAS_UNDERSCORES(1.00)[]; BAYES_HAM(-0.88)[78.69%]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[linutronix.de,none]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[linutronix.de:s=2020,linutronix.de:s=2020e]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ZERO(0.00)[0]; RCPT_COUNT_TWELVE(0.00)[12]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[linutronix.de:+]; TO_DN_SOME(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; ARC_NA(0.00)[] X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: F14CB140007 X-Stat-Signature: m9d8b5cr7wm8c9hetqpgbyt1ipswci9i X-HE-Tag: 1670446626-864242 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: Song! On Wed, Dec 07 2022 at 11:26, Song Liu wrote: > On Wed, Dec 7, 2022 at 7:36 AM Thomas Gleixner wrote: >> > I think we can handle all these with a single module_alloc() and a few >> > module_arch_* functions(). >> struct mod_alloc_type { >> unsigned int mapto_type; >> unsigned int flags; >> unsigned int granularity; >> unsigned int alignment; >> unsigned long start[MOD_MAX_ADDR_SPACES]; >> unsigned long end[MOD_MAX_ADDR_SPACES]; >> pgprot_t pgprot; >> void (*fill)(void *dst, void *src, unsigned int size); >> void (*invalidate)(void *dst, unsigned int size); >> }; > > Yeah, this is a lot better than arch_ functions. Remember the order of things to worry about: #3 :) > We probably want two more function pointers here: > > int (*protect)(unsigned long addr, int numpages); > int (*unprotect)(unsigned long addr, int numpages); > > These two functions will be NULL for archs that support text_poke; > while legacy archs use them for set_memory_[ro|x|rw|nx]. Then, I > think we can get rid of VM_FLUSH_RESET_PERMS. Depends. You can implement fill() memcpy(...); set_memory_ro(); and invalidate() set_memory_rw(); memset(); as global helpers which can be used by the architecture for the init struct or used as default for certain types. > I think I am ready to dive into the code and prepare the first RFC/PATCH. > Please let me know if there is anything we should discuss/clarify before that. I think we covered most of it by now, so sure a POC is probably due, but please yell when you find a gap in step #1 - #3 which we did not cover yet. Thanks, tglx