Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Song Liu <songliubraving@fb.com>
To:     Peter Zijlstra <peterz@infradead.org>
CC:     Song Liu <song@kernel.org>, bpf <bpf@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        Linux-MM <linux-mm@kvack.org>,
        "linux-modules@vger.kernel.org" <linux-modules@vger.kernel.org>,
        Luis Chamberlain <mcgrof@kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        "naveen.n.rao@linux.ibm.com" <naveen.n.rao@linux.ibm.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "anil.s.keshavamurthy@intel.com" <anil.s.keshavamurthy@intel.com>,
        "keescook@chromium.org" <keescook@chromium.org>,
        "hch@infradead.org" <hch@infradead.org>,
        "dave@stgolabs.net" <dave@stgolabs.net>,
        "daniel@iogearbox.net" <daniel@iogearbox.net>,
        Kernel Team <Kernel-team@fb.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "rick.p.edgecombe@intel.com" <rick.p.edgecombe@intel.com>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH bpf-next 1/3] mm/vmalloc: introduce vmalloc_exec which
 allocates RO+X memory
Thread-Topic: [PATCH bpf-next 1/3] mm/vmalloc: introduce vmalloc_exec which
 allocates RO+X memory
Thread-Index: AQHYlpK25UY5kW1ND0S/krM8qG//OK18FxyAgABbw4CAAE2vgIAADyyA
Date:   Wed, 13 Jul 2022 21:20:55 +0000
Message-ID: <78A18945-0841-4CCE-8A33-6C09ECBFF7E1@fb.com>
References: <20220713071846.3286727-1-song@kernel.org>
 <20220713071846.3286727-2-song@kernel.org>
 <Ys6cWUMHO8XwyYgr@hirez.programming.kicks-ass.net>
 <7C927986-3665-4BD6-A339-D3FE4A71E3D4@fb.com>
 <Ys8qfRwkTbUYwmKM@worktop.programming.kicks-ass.net>
In-Reply-To: <Ys8qfRwkTbUYwmKM@worktop.programming.kicks-ass.net>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?h8Y6B+axFnz/xxORosmkN7QShWUmKc5VHuPZuJZ2MSVLn/XcEmYFl8RamI/O?=
 =?us-ascii?Q?84IVBjGVLsceKUtCCu7mmytiqjNAdFsN32cypIUOtDA7hw62F+s2V7lCEwVF?=
 =?us-ascii?Q?rGZ8JgMz5TCNdBxz8P4baPXLLYuoxj4cx09culnwPuT35K80LVRdfMrk7bRY?=
 =?us-ascii?Q?kAQ8hIziH7HO3Iy2zpaygElOH2BtFCrL3rofCwkZ9MamfiJIwF/gZr3c4GxK?=
 =?us-ascii?Q?aOM+Dm/ewpk4qYYmmjdDOeeIlrM+iVa+OeK0wykTdgU0SLwSdM7rUn6/tfiY?=
 =?us-ascii?Q?U/3zriPOiu1dpv3Ud9Wd8CAiV1a+mDXT7KtZ6BbWYiXrfaG5FbgJEqxHNa7g?=
 =?us-ascii?Q?pVKtlduDFzDwHV3g6d4X4Mt2ELL/AyICE7lWDtNIewCFycvZRgcRVLsDgznI?=
 =?us-ascii?Q?kKp3YWbqG6bnKiq9J68fGneFWW/5CwJn61wCkZfd2gx2LFiHlW9j4r3876cT?=
 =?us-ascii?Q?86qT3m1SAjj0tI3eIDdFb/hYteoCGSGGwEf9K1jg9wtmOkVt3vTkUKt09qtj?=
 =?us-ascii?Q?WB+CEjvP1aao+vNoeDaUH3BT2Jla/zc98CZysgMr3SN87CoklDJMrtmutBF0?=
 =?us-ascii?Q?VE8gK8NRgLQ9W7Kk75dPCRlZY3bAvjgXgSMZjgN+CITLdLYJrjhunHPzTaaN?=
 =?us-ascii?Q?A6atuFHG0CWGeSLa23qW2XYoWx5j1bi1dra8gY1/V4zM/H3dMVwLjY9AAQG/?=
 =?us-ascii?Q?uyjpYnvaJAfLHreCIbDkjXWR1CYU+NyMetw2PG9QzbltGpJv1BJDjvWV+PZ0?=
 =?us-ascii?Q?xXg1Sn4WOgWy84qdpQYsogbVscwZqoRvRRd1VIZwfQu85z9P/O1CW64ZZE9n?=
 =?us-ascii?Q?RjoDLkeEztW876zRyt+mb54xqHq62qu3h/DVbQAvhcqLS6frVvuZgQAPjKwU?=
 =?us-ascii?Q?7ioYCFSzMHYO2MdBVvNHv4v0i0icaoIUzSyJFOcMlCweUhQlyM3hAfTbixYX?=
 =?us-ascii?Q?3rvFioQMSAQAyZrhwbj1Ei1sUDf8dkBUcr02OzbNARhN2p+Kb1jRY7O2s3Jf?=
 =?us-ascii?Q?uWKD7UC4TILzaEJO6NNQyqIeKngmIwpoumza2KwIxHCaA/nrfQQvIxB6tGYs?=
 =?us-ascii?Q?j8P6RYagNyTmKZEsxa9D2t6wDgcWO9dTpWIVCood3ibi8CQPva1S/ZnVAq4o?=
 =?us-ascii?Q?C+/BGQyrLVcJOo59xMwrej++qJfaadXN98vxoOnFAarBHvjIOjj+4zDRbu0y?=
 =?us-ascii?Q?rCZYkEIlzY6QPS49fdaBiokfISntFIZYviibBNJiuwfsX2LaLH+vugIteO+j?=
 =?us-ascii?Q?TT99owLcJULQSWrO/985HrDgzMb1VMEgKJ6Ewa/hFD2LhL+OA1S3FLnnP8gU?=
 =?us-ascii?Q?rIWGAGFSI9AR0xd7JdxTetSgv4iacU/6+7IpzTeE5AQJ9epacl1ugoai5vJQ?=
 =?us-ascii?Q?+keJOn5mhgseweFJ3FOOxpB8YejrsfKKcB5AepRST0L75lPZyWaRkiHBP4lx?=
 =?us-ascii?Q?Ioas29KxULxQlitMdO4HT9XA/Cqe6qCYW8KUkNdnjq/G2WlD7nCjRz6C7Hv9?=
 =?us-ascii?Q?geiuRwGf5YAgeYwp1vrkRnqweyLUlvfa3cO9b57P4xLJ6GPflxpcT4aGv1f5?=
 =?us-ascii?Q?wWctPkxfDDrvCr2YPw9ESf+hNRh9g0qkP+8eVf8ZsS2hOi1eGcKhpPXhwuZp?=
 =?us-ascii?Q?fyi+YZHykLEdxNHhjWNxtcQ=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <CF74EEC71C01D04EA239ABB2FF4184A0@namprd15.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: fb.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR15MB5109.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a2342e2-2985-4a20-25f7-08da651592f1
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2022 21:20:56.0186
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7IJzOdzqmd/mjsk9nwZ72oXf1r++3h0OeaAfRoYDAs+xrfRIkSfjrwL0XJuS9PWprj327/q2SxZgoouRqxIybQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR15MB5011
X-Proofpoint-ORIG-GUID: ywhtoKhG8kY0PnOBy0fjJRe_sAbR_DkL
X-Proofpoint-GUID: ywhtoKhG8kY0PnOBy0fjJRe_sAbR_DkL
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1
 definitions=2022-07-13_11,2022-07-13_03,2022-06-22_01
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Jul 13, 2022, at 1:26 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> 
> On Wed, Jul 13, 2022 at 03:48:35PM +0000, Song Liu wrote:
> 
>>> So how about instead we separate them? Then much of the problem goes
>>> away, you don't need to track these 2M chunks at all.
>> 
>> If we manage the memory in < 2MiB granularity, either 4kB or smaller, 
>> we still need some way to track which parts are being used, no? I mean
>> the bitmap.  
> 
> I was thinking the vmalloc vmap_area tree could help out there.

Interesting. vmap_area tree indeed keeps a lot of useful information. 

Currently, powerpc supports CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC, 
which leaves module_alloc just for module text. If this works, we get
separation between RO+X and RW memory. What would it take to enable
CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC for x86_64? 

Thanks,
Song