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 9752FC4332F for ; Mon, 17 Oct 2022 07:26:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CB506B0072; Mon, 17 Oct 2022 03:26:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 17C06900002; Mon, 17 Oct 2022 03:26:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 06A988E0001; Mon, 17 Oct 2022 03:26:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id EC2736B0072 for ; Mon, 17 Oct 2022 03:26:14 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A82E3160963 for ; Mon, 17 Oct 2022 07:26:14 +0000 (UTC) X-FDA: 80029607868.22.DD06502 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf23.hostedemail.com (Postfix) with ESMTP id 1B929140030 for ; Mon, 17 Oct 2022 07:26:13 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 4877668D05; Mon, 17 Oct 2022 09:26:08 +0200 (CEST) Date: Mon, 17 Oct 2022 09:26:07 +0200 From: Christoph Hellwig To: Song Liu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, x86@kernel.org, peterz@infradead.org, hch@lst.de, kernel-team@fb.com, rick.p.edgecombe@intel.com, dave.hansen@intel.com, urezki@gmail.com Subject: Re: [RFC v2 0/4] vmalloc_exec for modules and BPF programs Message-ID: <20221017072607.GA30977@lst.de> References: <20221007234315.2877365-1-song@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221007234315.2877365-1-song@kernel.org> User-Agent: Mutt/1.5.17 (2007-11-01) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665991574; 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; bh=mfYfVP5XzmJoOZUYpaq/SsgeKgnXY7O6wlYNAVTD8AY=; b=tacBL3a+kLn7fikPs/nl654HVTfPwjvfaMEgCmhucVwdu6wrMjYqrgxThFsTQXehzv9Dsl dtp4BtMaR96sRBpHuVVpY/g1efAaiM6geZzzbFmA/YD+i0Yrv9ecOgA9TXq9PFrmIehdG0 BK7diTMU1Fib24hQpNOgS7CVLef+oZA= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; spf=none (imf23.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665991574; a=rsa-sha256; cv=none; b=fhKVELQ1W+JL4BxO8kZ8AWL7455Fg5xiyTpYbOL+umg1xv4TAK84EsnEJI1GMr7SnUdrnK yrgiGW+prZEdyF/u+JZYFtVFyCYd6rDJyLRc405Zbld99ADxPznpcHnxfUu706XlyhFpOH ifWNsDd6EWy8iheNdMFRKfyDCphfIpQ= X-Rspamd-Server: rspam12 X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=none; spf=none (imf23.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de; dmarc=none X-Stat-Signature: h54h16mu46w9r81zcgudufgja47surq4 X-Rspamd-Queue-Id: 1B929140030 X-HE-Tag: 1665991573-211444 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, Oct 07, 2022 at 04:43:11PM -0700, Song Liu wrote: > Changes RFC v1 => RFC v2: > 1. Major rewrite of the logic of vmalloc_exec and vfree_exec. They now > work fine with BPF programs (patch 1, 2, 4). But module side (patch 3) > still need some work. Can you please move the changelog under the description of WTF the series actually does like the normal kernel process? Explaining the changes from a previous version before you even describe what the series does is completely incoherent. > This set is a prototype that allows dynamic kernel text (modules, bpf > programs, various trampolines, etc.) to share huge pages. The idea is > similar to Peter's suggestion in [1]. Please refer to each patch for > more detais. Well, nothing explains what the method is to avoid having memory that is mapped writable and executable at the same time, which really could use some explanation here (and in the main patch as well).