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 C6D2FC4332F for ; Fri, 2 Dec 2022 08:39:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5E3FC6B0073; Fri, 2 Dec 2022 03:39:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 594646B0074; Fri, 2 Dec 2022 03:39:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 45D3B6B0075; Fri, 2 Dec 2022 03:39:02 -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 3286E6B0073 for ; Fri, 2 Dec 2022 03:39:02 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E6E3B412C6 for ; Fri, 2 Dec 2022 08:39:01 +0000 (UTC) X-FDA: 80196716082.09.95D2BF9 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf30.hostedemail.com (Postfix) with ESMTP id 55A5C80017 for ; Fri, 2 Dec 2022 08:39:01 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YzLV3QVb; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf30.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 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=1669970341; 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=wdHw5qNB+ags3IDr1GVIc/Jt8em+HYL5Dq34RvCg0Kk=; b=F535yNCN6weEDw+PnIwOcI41XKLJl578ib9BPzXl2aDhqApiy4BoAQu3gEVDlGhRm9XCpe bldra8wwRHSxMG4xiTYlL99ZinWJnpswYY1SJ/8bs1yXXeEuWq1OjtOh7zM2IRzuO4mfuM Cz+SUtSy6eJyhkG3g8onm+CDchqh7TU= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YzLV3QVb; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf30.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669970341; a=rsa-sha256; cv=none; b=EBWExB87pLk0l0NMJAWkw51bDq21zFWk+zmSlocZPqAz7jcx+uWbeYnzMInQ7Xa62Yyz7m n+pXZSvkmuLwINz0poRw5zsIQi7AasgO2xbXqaDjOTMkVieKG5zI+zGHgMWgy6cCnzL4bw kykB6Y5qh3Iq695JVphyrqB8piSzriQ= 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 65E67620C7 for ; Fri, 2 Dec 2022 08:39:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC7E5C4347C for ; Fri, 2 Dec 2022 08:38:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669970339; bh=OQj2RdSG+g9kHrqQXz6JdFh2L923aPaG2AapH6vQw7A=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=YzLV3QVbZqzdlPfkxH7ykUAn1NwcnRAUjuZnZV3I/GorFQoParZmxj1kK8sCiUbJn flkHMOA/Pv6kpIjn8C/cQkCNdaC5C/YaVFJvzVwdRmK3NKSZlphIhrRcN07F0AvCgV Un7XP2z3FyDB6J8G4Z3Qt5IeeAHuI4hJPpiabk8AOrPO/FiGJy74l5pGzbPldPn4XY odJ6o9Z5nVWG/Xyl6l72g/xC/iC8pKxcdVxNUsXtDRCSU7fkUMNFC8J4rBphasZFym uUlANu7THsScnSR+oHTi3U8ZxQhmwEc7RDojuWdGNxOHeiQ++UhkbXgMpaXIWBdB+1 g/ltAzBMsfW8w== Received: by mail-ed1-f42.google.com with SMTP id e13so5514301edj.7 for ; Fri, 02 Dec 2022 00:38:59 -0800 (PST) X-Gm-Message-State: ANoB5pnYCC9Zg+JqDOsy1l7Fgi3thXV35Fr2rxK5C3C+avZga/mnEPiv QGi5qp0729jeKl0LUy4ZtZIhnRCWGKc4tz/ANWM= X-Google-Smtp-Source: AA0mqf4JKfe++A3IGRWObi6GLw7nINrk27DN0AaVySi0wIYrJ4mBaSEIOLmHhirCZQcgYKJKCA5aELJXuT/NuO3Gg7o= X-Received: by 2002:aa7:d496:0:b0:46b:e7c0:9313 with SMTP id b22-20020aa7d496000000b0046be7c09313mr6634536edr.412.1669970338011; Fri, 02 Dec 2022 00:38:58 -0800 (PST) MIME-Version: 1.0 References: <87v8mvsd8d.ffs@tglx> <87k03ar3e3.ffs@tglx> In-Reply-To: <87k03ar3e3.ffs@tglx> From: Song Liu Date: Fri, 2 Dec 2022 00:38:45 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs To: Thomas Gleixner 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 Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: wz6bu7pm8grqosb8k9hqt57zpaje6tki X-Spamd-Result: default: False [0.10 / 9.00]; BAYES_HAM(-3.00)[100.00%]; IRL_BL_25(2.00)[52.25.139.140:received]; SUBJECT_HAS_UNDERSCORES(1.00)[]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; R_SPF_ALLOW(0.00)[+a:dfw.source.kernel.org]; RCPT_COUNT_SEVEN(0.00)[11]; DMARC_POLICY_ALLOW(0.00)[kernel.org,none]; R_DKIM_ALLOW(0.00)[kernel.org:s=k20201202]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[kernel.org:+]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[linux-mm@kvack.org]; ARC_NA(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 55A5C80017 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1669970341-616838 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: Hi Thomas, Thanks for all these suggestions! On Thu, Dec 1, 2022 at 5:38 PM Thomas Gleixner wrote: > [...] (everything snipped here makes perfect sense). > > You have to be aware, that the rodata space needs to be page granular > while text and data can really aggregate below the page alignment, but > again might have different alignment requirements. I don't quite follow why rodata space needs to be page granular. If text can go below page granular, rodata should also do that, no? > > So you need a configuration mechanism which allows to specify per type: > > - Initial mapping type (RX, RWX, RW) > - Alignment > - Granularity > - Address space restrictions [...] > > Step 1: > These steps are really helpful. Thanks! [...] > > For text that's obviously module_write_text(), but for the [ro]data > mappings memcpy() is still fine. For the rodata mapping you need > set_memory_ro() right in the module prepare stage and for the > ro_after_init_data() you do that after the module init function returns > success, which is pretty much what the code does today. I guess this is related to rodata needs to be page granular? But I don't think I got the idea. Do we allow rodata and rwdata share the same 2MB page? ro_after_init_data seems trickier. > > Step 5: > [...] > > Linus once said: > > "Bad programmers worry about the code. Good programmers worry about > data structures and their relationships." > > He's absolutely right. Here is my version of it: > > The order of things to worry about: > > 1) Problem analysis > 2) Concepts > 3) Data structures and their relationships > 4) Code > > #1 You need to understand the problem fully to come up with > concepts > > #2 Once you understand the problem fully you can talk about > concepts to solve it > > #3 Maps the concept to data structures and forms relationships > > #4 Is the logical consequence of #1 + #2 + #3 and because your > concept makes sense, the data structures and their > relationships are understandable, the code becomes > understandable too. > > If any of the steps finds a gap in the previous ones, then you > have to go back and solve those first. > > Any attempt to reorder the above is putting the cart before the horse > and a guarantee for failure. Thanks for these advices! They would help me for many years. > > Now go back and carefully read up on what I wrote above and in my > previous mail. > > The previous mail was mostly about #1 to explain the problem as broad as > possible and an initial stab at #2 suggesting concepts to solve it. > > This one is still covering some aspects of #1, but it is mostly about #2 > and more focussed on particular aspects of the concept. If you look at > it carefully then you find some bits which map to #3 but still at the > conceptual level. > > Did I talk about code or implementation details? > > Not at all and I'm not going to do so before #1 and #2 are agreed > on. The above pseudo code snippets are just for illustration and I used > them because I was too lazy to write a novel, but they all are still at > the conceptual level. > > Now you can rightfully argue that if you stich those snippets together > then they form a picture which outlines the implementation, but that's > the whole purpose of this exercise, right? I guess I will do my homework, and come back with as much information as possible for #1 + #2 + #3. Then, we can discuss whether it makes sense at all. Does this sound like the right approach? Thanks, Song