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 84D79C4708D for ; Fri, 2 Dec 2022 17:43:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E87DD6B0072; Fri, 2 Dec 2022 12:43:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E388D6B0073; Fri, 2 Dec 2022 12:43:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D001D6B0074; Fri, 2 Dec 2022 12:43:58 -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 B87636B0072 for ; Fri, 2 Dec 2022 12:43:58 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 86AF8401AE for ; Fri, 2 Dec 2022 17:43:58 +0000 (UTC) X-FDA: 80198089356.02.F1D2866 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf28.hostedemail.com (Postfix) with ESMTP id 0862DC0010 for ; Fri, 2 Dec 2022 17:43:57 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=vqme40fh; dkim=pass header.d=linutronix.de header.s=2020e header.b="XWZ8S6H/"; spf=pass (imf28.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=1670003038; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Hw2IcvB/DAxzATKFNjZzen0qSXdeIAQcVISV0zMHhRs=; b=S/HIGWIlck+Km2p3/UleL9rg5fT3fROBW3MtAabWGptnuow9tEjFEwAGdy5q54SbUDEHlo Xc6tmjGzTspJYg4FmQa74LaIiQ+RuaBsfCnO25rcI7unBl9c5H4umPF1OwjzD8loKHlkqM /7KDOMLIKdBKujV7/Ok8CL5Ou6CEqtE= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=vqme40fh; dkim=pass header.d=linutronix.de header.s=2020e header.b="XWZ8S6H/"; spf=pass (imf28.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=1670003038; a=rsa-sha256; cv=none; b=gdGRjp3YgBUY8fBYKmp8YGXdr2M7gRrB4xvOQutBIoHfcu6hdt/BSUBUiviYs1/4cLl/lY ziNEXhPxDWLLCxHKm1s9VJ13Vr4ias9Jzrp+SYC5TeeNv11RIP6p4xVMjJK8Fg4+oXHHXk UaPrF61dc/hY9xLcYUtIq+xS2/tDajs= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1670003035; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Hw2IcvB/DAxzATKFNjZzen0qSXdeIAQcVISV0zMHhRs=; b=vqme40fhzHor+wxF288mCsnY/rm6HPnwOtK75h/AeGYp4SFl6C/3snqM9dT0eV3WQmSdsT VfjwQCE0VBa+/DFXJrs79iydgOg8RaMVGRQe7AxhMRhDbMhM901pecVQ8quvcvBgSucYCO 6tyLkb9TENNC3eqAxQgghambuYEplJSKQmyshoEE9oQpoJQD9z969tSvYzn3BXyNuhVzdW c2byKk68jrgUaAwQuE0nwW+YvTNHEglVSW0CCy26zZ17G+VFO0S74pcfemmdqzoaP/fn8b iUaRUFkRhaHiPcht1fPOQE/zYqppMouty6V8MvZukGQAUbkTebm0pOyu90oAKA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1670003035; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Hw2IcvB/DAxzATKFNjZzen0qSXdeIAQcVISV0zMHhRs=; b=XWZ8S6H/jSo4nTycZl9+k8Sdnrgh80/yWstyPolb2XirRQQQ1dTKWKS7njbVcaks4RAc9v oEa7doqyBKP0EMAQ== To: Christophe Leroy , 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" Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs In-Reply-To: <5fb21965-48c8-e795-632a-fa190470abe8@csgroup.eu> References: <87v8mvsd8d.ffs@tglx> <87k03ar3e3.ffs@tglx> <5fb21965-48c8-e795-632a-fa190470abe8@csgroup.eu> Date: Fri, 02 Dec 2022 18:43:54 +0100 Message-ID: <87ilitpup1.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0862DC0010 X-Rspam-User: X-Stat-Signature: mr54rtr8qdc3xc3k337cop3ak163edok X-Spamd-Result: default: False [-0.95 / 9.00]; BAYES_HAM(-1.45)[83.70%]; SUBJECT_HAS_UNDERSCORES(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[linutronix.de,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[linutronix.de:s=2020,linutronix.de:s=2020e]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWELVE(0.00)[12]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[linutronix.de:+]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[] X-HE-Tag: 1670003037-832344 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 Fri, Dec 02 2022 at 10:46, Christophe Leroy wrote: > Le 02/12/2022 =C3=A0 02:38, Thomas Gleixner a =C3=A9crit=C2=A0: >> Even modules can benefit from that. The fact that modules have all >> sections (text, data, rodata) page aligned and page granular is not due >> to an requirement of modules, it's so because that's how module_alloc() >> works and the module layout has been adopted to it. > > Sections are page aligned only when STRICT_MODULE_RWX is selected. Correct, but without strict permission separation we would not debate this at all. Everything would be RWX and fine. For separation my point still stands that the problem is that module_alloc() is just doing an en-bloc allocation, which needs to be split into RX, RW, RO afterwards and that consequently splits the large mappings apart. Which in turn means text, data, rodata have to be page aligned and page granular. The typed approach and having a mechanism to preserve the underlying large page mappings is the broadest scope we have to cover. An RWX only architecture is just the most trivial case of such an infrastructure. The types become all the same, the underlying page size does not matter, but it's just a configuration variant. Architectures which support strict separation, but only small pages are a configuration variant too. All of them can use the same infrastructure and the same API to alloc/free and write/update the allocated memory. The configuration will take care to pick the appropriate mechanisms. No? Thanks, tglx =20