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 153D2EB64DB for ; Sat, 17 Jun 2023 06:58:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B6366B007E; Sat, 17 Jun 2023 02:58:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 666DF6B0080; Sat, 17 Jun 2023 02:58:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52EBF8E0001; Sat, 17 Jun 2023 02:58:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 418BB6B007E for ; Sat, 17 Jun 2023 02:58:50 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0D1A3C013A for ; Sat, 17 Jun 2023 06:58:50 +0000 (UTC) X-FDA: 80911337220.01.8D16F33 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf14.hostedemail.com (Postfix) with ESMTP id 413AD100004 for ; Sat, 17 Jun 2023 06:58:48 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nHkTyW+h; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686985128; 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=OQXP9ijNzfVawbuEHwPnoybJkHMiyJVTW9lj6nigcvA=; b=3buZIFu8UQHTnhH+Ju3an+5Wv2uob1KerqIVfvgsezB9y6gxYLZ7tONNQoPUwzPmqAut18 XCy3FS2qx/X+aQ9hyHrwBw32F783xixrdzzSBHNwu6CKw7Baq3XPdQqKABrEPqRw65cHtW Oxdbi1MGi4t3Wryc/PJpIjxBs9iBuws= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nHkTyW+h; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686985128; a=rsa-sha256; cv=none; b=1h7dluaazDYlxBy0uDZ3pQN9nCW3+opyo6Pl19E3TSwp17u2Niak/2VNnLRHSJx5Eu4QWM AM1Nst73RO2vUavVZ2cZG0pc0zvW9X+j0jUzcjKWjdWWWFVmZV2/y/aXPDUWxk/eB0pfHd 8fawogKsdtVjEzliK89yR9K6IBtAdL0= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2E11B6068F; Sat, 17 Jun 2023 06:58:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9588BC433C0; Sat, 17 Jun 2023 06:58:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686985126; bh=9S4P8JW7Aw6+2ZoVDniU5EdIBLc9OdiTvqw3YA9ECf4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nHkTyW+hctadrgmIg2I6LaptKR6YKkmtmdcOS/HSni9feQ5p1DZtCSX6Dnam1slU3 FLDQnf/OEx1d4jSPxMmAwLEhSg3dDkigyXgxGzkX1VJc1UJnkk6n01fCEZ0qwx4ELP r6wbjQNoXnPg5HveUgv1zS7owOZuF5kej34YgRIGZdC2tH3sGX0H+MpQa784HSW6mk qjN9Au7ZhvMEPLupJ+gAv5/GudEwZVVlLyNGJFO9CDGv8qdQ0I+Zmw8CDlXcjxb8w/ RZuOMQ5h8Q4Z/8VeTux+zm8PEK9dnLGg98fBUnC+4CbpTq0gKeC8d5BMUXJufl+4IU tPAEuFrGSOYnA== Date: Sat, 17 Jun 2023 09:57:59 +0300 From: Mike Rapoport To: Song Liu Cc: linux-kernel@vger.kernel.org, Andrew Morton , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Mark Rutland , Michael Ellerman , Nadav Amit , "Naveen N. Rao" , Palmer Dabbelt , Puranjay Mohan , Rick Edgecombe , Russell King , Steven Rostedt , Thomas Bogendoerfer , Thomas Gleixner , Will Deacon , bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev, netdev@vger.kernel.org, sparclinux@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH v2 07/12] arm64, execmem: extend execmem_params for generated code definitions Message-ID: <20230617065759.GT52412@kernel.org> References: <20230616085038.4121892-1-rppt@kernel.org> <20230616085038.4121892-8-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 413AD100004 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ej1rcckxnq99h34fa8tgpbkt7r8dwer5 X-HE-Tag: 1686985128-134492 X-HE-Meta: U2FsdGVkX19rIrTWBzwXhW3Oyw+hcrpMLIGkcy96pX0WOPA7laWsgJ9eq8IkABidSavfQRikfJW+l79bTS/0m7UDWsycOUhz+Os9gITodl/2zw59YNw4Tgb4Ha0vsbSrM7z36ecz5mqlk9jBu1K9kL7d2G9hhVsBV6XBo3LEH7zBaD1SzhHgGsR1W0Bz9HEGfZvI1jwIlpjxwOEuI7E2EzEtHQEOFSlT8+CGm+q/3U2F2wq3nS354Pp4H58mMxUzAg6TZMH3vzTpgDRrJ4wRTUAKlCBn/Ej+gFGkMUUgQgajViz8UV3k1JGZEDcYmI3pCZ6LecGxXh7Heglu+VSlrEOWSSdgKH4LeyIUjIJDwMdZVIYZM+35rYqt8li0zVCAE5qjSEmiYb+W0P6sKu3WwSH+3g1ICInpushUbP7P5AZE4RmJsokz4kl1zgLBjzOKctmU60nytYzBPPRc8EdkNhY0IYgHUDTnwCGFX2SfHlpbuphtzxVBMzkgtO9XdwoWrkXYqwrKPUuErL/n3vYtmzwkUusKZSh+WsODE0FJp6vjPiwJMh5DUjaMJ63B81B4Q7r5aKcCzJxhyHQxNgHiVjjQmE+Lg0LGs9vNESEod+f65uuwIPFAKI16/1nxHCjCKtGDln6n1wmO4B0PUJxuKmLcoROHlyyME06vADTI91P0UzjKg4By0zCMrrMV+jySV3q8/whstkQJXgfz+RWA1gCRxZOyGt/8vx1+R2VJ1CuQeyIP1urJX0Ob2JngzLGp421trDWEpsLAuGRgoAR5ChMFVZvwnlw2rnvYSmFVZdz5Yeu+fthL8gzgmGwoo9n/o/iqx7Oh5vD1SEaXAxNSNpNB8uw5NivUSEviWVL0bbSdmD+0jIbW3BJ8Re/p/W//yxHn9u5ONAaKz9Nh3Wfrf6hvpZ1XXn00RC9XY8NMiszhgpvr8bdRHBpf7rTEoqF06RC+EgoqQbMbCHNMdHY XIYKUwEa toaxlPg6VOklKeMPdmWZ1aV8oU8Plb3tliJjs5Ac5syehlj1ZtNQeN4Qb7C/SI64yWa8WHI25HX4vcMSyEk8DrIccFIDgipRMpYPjHJmAmfRhhxdorgd/walqxrvaGtYzzbTxmEhRuKTlNSQY1LL84ixbvd/FdmeF4tXCuxOs0fk6zbOhaVFm0Rjr/DCGlfnJogd4NpIEwjB5V0TKT7EB4PiJ3ftQmQLKfAzkT8flAwcEP0JavuB5yD47vGEyeMFmVz7/YgncwCdjHuhBv6TD33v40nl+r8IbMNopjN6m8SpnjRVh5htBCchIi8j5pzmzmI651zB2SziWfSxRPWjB2GHmSJthXKPX7+o+nQszJbL4ewRjx5WtO4XMV9qi6jGUqEJnTi0YopNc1AoT0TOwq4+PF9zMxIfWLZwzRzssHltoPe2M8xDcAkYXSbBQ9V+YfdJ2oAAFSZbpsbycQdIf0WcArA== 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, Jun 16, 2023 at 01:05:29PM -0700, Song Liu wrote: > On Fri, Jun 16, 2023 at 1:52 AM Mike Rapoport wrote: > > > > From: "Mike Rapoport (IBM)" > > > > The memory allocations for kprobes on arm64 can be placed anywhere in > > vmalloc address space and currently this is implemented with an override > > of alloc_insn_page() in arm64. > > > > Extend execmem_params with a range for generated code allocations and > > make kprobes on arm64 use this extension rather than override > > alloc_insn_page(). > > > > Signed-off-by: Mike Rapoport (IBM) > > --- > > arch/arm64/kernel/module.c | 9 +++++++++ > > arch/arm64/kernel/probes/kprobes.c | 7 ------- > > include/linux/execmem.h | 11 +++++++++++ > > mm/execmem.c | 14 +++++++++++++- > > 4 files changed, 33 insertions(+), 8 deletions(-) > > > > diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c > > index c3d999f3a3dd..52b09626bc0f 100644 > > --- a/arch/arm64/kernel/module.c > > +++ b/arch/arm64/kernel/module.c > > @@ -30,6 +30,13 @@ static struct execmem_params execmem_params = { > > .alignment = MODULE_ALIGN, > > }, > > }, > > + .jit = { > > + .text = { > > + .start = VMALLOC_START, > > + .end = VMALLOC_END, > > + .alignment = 1, > > + }, > > + }, > > }; > > This is growing fast. :) We have 3 now: text, data, jit. And it will be > 5 when we split data into rw data, ro data, ro after init data. I wonder > whether we should still do some type enum here. But we can revisit > this topic later. I don't think we'd need 5. Four at most :) I don't know yet what would be the best way to differentiate RW and RO data, but ro_after_init surely won't need a new type. It either will be allocated as RW and then the caller will have to set it RO after initialization is done, or it will be allocated as RO and the caller will have to do something like text_poke to update it. > Other than that > > Acked-by: Song Liu -- Sincerely yours, Mike.