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 E08C9C4345F for ; Mon, 22 Apr 2024 18:32:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 792196B0093; Mon, 22 Apr 2024 14:32:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 71A756B0095; Mon, 22 Apr 2024 14:32:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BB996B0096; Mon, 22 Apr 2024 14:32:45 -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 395BE6B0093 for ; Mon, 22 Apr 2024 14:32:45 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D5E1B1C0CF4 for ; Mon, 22 Apr 2024 18:32:44 +0000 (UTC) X-FDA: 82038013848.17.EB4F9E7 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf29.hostedemail.com (Postfix) with ESMTP id 2F4E1120014 for ; Mon, 22 Apr 2024 18:32:40 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qA68HtY8; spf=pass (imf29.hostedemail.com: domain of song@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713810761; a=rsa-sha256; cv=none; b=o0JQMOLFyY9bvjDYBrvHOoy0EsUVAqOmcoSeSvDvnMp8B4+jfOaQD/vq8Db2X4QXwSOXjF SLCyXik+xrI3d5Sgww4Ayh3Nta4eMJ4yxJz5RwMchaRye9KJ+6CmkLnHQPvcleRStYm6qj Hyom41t/12UiLST0UXcTJ2QfUtgMxXs= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qA68HtY8; spf=pass (imf29.hostedemail.com: domain of song@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713810761; 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=41bQmayZLa9F2TS6BjEFSDm7V8S6LLEq/o95h7wxG6E=; b=dXv2KXm3Zm55fwAlV0+BTbaPqdbli6CpcYAb0KLKyoeypATiVT/j9Q2cLRP7G7s7UnwNLR SMHrJRtamrifKipYFSCFG/D+1RIWar4LFNd7rFz9iXSKMGn20r/VVsfZshSCZdBo7iMALY pqD9iZ2tvk1SPFDFf6V2dvS+lTMboHc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id A3686CE0AE8 for ; Mon, 22 Apr 2024 18:32:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9391C32783 for ; Mon, 22 Apr 2024 18:32:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713810756; bh=41bQmayZLa9F2TS6BjEFSDm7V8S6LLEq/o95h7wxG6E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=qA68HtY8VqgqRqZf2Z+BRxEGJ87lJdUCx6Osh8gSscfIYLuwih8LbbcRjgeSN72TL Xw4JdoR+vqq1sJrywF+UW6jt11XxxAfhRX5vf+4P5PZXOtwSy4cCuAVWYzrkNtfZFY RJi50MG1o3p5BPD9oDayagmrPVMy0EhVLAw/pglX6Uo5PAN1xX+pidD1GnidGKtKn6 ykB1LL+ua/PB+25yLvCBTFxFBB/U4R1LEgj+l7TftBqPQ+Ztyd7hEVqFG/2O36A5Z1 UjuZ6JKnGq1s27TbSA3JcyRLnCb+mXgDdhxyZJYk3N/4rAuQbLQhxxn1GV+slKtDRx DyT9rgFt2Zekg== Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2dda77dfb9eso13612551fa.1 for ; Mon, 22 Apr 2024 11:32:36 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVNrwF9AM6KQiFdGKuMw8VmaAY+naqwA/hZD5+gSWD+6SuwbCa19OVX2gvAJQ1TtZynu7ieq9pMucraDVncC7ba60U= X-Gm-Message-State: AOJu0YznqYmgDmgnbrRDhcbFzuBBQIYIg4+SHw65k4geYnTXGIZdu8V/ v88Y9AoL2eqW7EblIdAHiho5+71CCeaORmV470eRGEw1JynKkFwYVPlMDNTfcpSGMFm35c6cbIS vDj8SrOec3u79PoLK9MtG0hzp3xA= X-Google-Smtp-Source: AGHT+IEL0FWUHmCKYIOk93aax6U4BdFHP3q3Bogcq6+CoScwmomqpj0/rB2eiX3SYQzXlZuuQSNAuqDXXtIwEOxd65Y= X-Received: by 2002:a2e:9496:0:b0:2d8:1d29:23a8 with SMTP id c22-20020a2e9496000000b002d81d2923a8mr6582027ljh.29.1713810734431; Mon, 22 Apr 2024 11:32:14 -0700 (PDT) MIME-Version: 1.0 References: <20240420181121.d6c7be11a6f98dc2462f8b41@kernel.org> In-Reply-To: <20240420181121.d6c7be11a6f98dc2462f8b41@kernel.org> From: Song Liu Date: Mon, 22 Apr 2024 11:32:02 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 05/15] mm: introduce execmem_alloc() and execmem_free() To: Masami Hiramatsu Cc: Mike Rapoport , Mark Rutland , Peter Zijlstra , linux-kernel@vger.kernel.org, Alexandre Ghiti , Andrew Morton , Bjorn Topel , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Donald Dutile , Eric Chanudet , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Michael Ellerman , Nadav Amit , Palmer Dabbelt , Puranjay Mohan , Rick Edgecombe , Russell King , Steven Rostedt , Thomas Bogendoerfer , Thomas Gleixner , Will Deacon , bpf@vger.kernel.org, linux-arch@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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 2F4E1120014 X-Stat-Signature: mreoka9sh9sg3oyybt9he3wjsnrnama5 X-Rspam-User: X-HE-Tag: 1713810760-647461 X-HE-Meta: U2FsdGVkX1/ZUkhy7WcWEX7e8xvAVHsPwQ3nSYJA9azNHbwk4c0HR1T0ODDGcRzfjKul3JJdtu1raAtfnNv8DhMYAdfA631vChRyd7lCt0D9xeX6CZ7p3JX1BHc/ZAc1MgRkM79sDukQALZ6gURXXkv//HOLrjLrDG6zoY7znS7AwZqZ/Js2RoNvZY74BwqM0PTYL5W+QhJyq5IQ4gDVRdNKhdQtMcskSWJclnE6gvkkrnePWfDaNfpllyblEkbQgYXZovBjmV7jIH8qY6OeUJ7qkF8yqKSYBrA+6Jy5MBM2V+Y81unQ1w6yHgXBI5LM9f1utxA8jsqy1rmZkQVVPM8PFdIeaYHXGiVEJ1WZk6SG5byYvc2SNevfdYPK4UdsDtEtFJwcSQVXHn132ioXMrMuqqbEo1XdWICQMK8by94Nj4HCsYOxgCWgtfmq2oQO1I4mBJg20iGhF0ch759I+6AtIeBXDY34snBYNfVSRyGaTfeXfIpL7j6umHuzTw96jyH2tQW9k8yUsxJYPVTYhkKPtI25W41C3AKmZVer3XQIUYWRHZW3jPKXoCKCClFK5aH/6+J/5i1pjt0vZ5HIpPDJtGszqP2swQCwYOmIGTp5s6PpgW4/XjtfPPCwW73NPF7/VHsVks85NDo9CK9+2AWiujS797QFRWKwHHg7mreDoZSQIviVjAhxqSsrB4i7RRGSc55DUTrSRCz8cgwPTBecDJoR/5Vu4rJsYZJpSv/peRug6NoXY9MMg0flFxtGPDoNqYmJfhPyOMeWGotKoVlWCEgA0qvr0ZLvhG+cOmg7jpTz574CBUwuxJ7uXrDXV8PNWtg+E8NObX72iB3rGOYkh9v77/B4gdCNL148aKdyqlKOm5mjo/qwrJHQFEXns9f4ucTQt1ek6SQs5UKtOMLKY/ueRwZWEwB8nvw4mKR5aLFx8Ezyk9ICQ9r3BMF1XVx0u1ePXUuvyBLmBr7 No9eeDtA DB9NBdeXCmYavyxbreCcXeaZBAWhMMTNsuClO7in1Z39fvSe6mZ1Rs+fIZxlXnZjF1tiU72jaYDM22morCVDovruHp2dIe3YOPe7TT8PAscqEYyg8CVxknZvztVxyAIWwHTNz/9S+bTEDujjEgVUn2+sHiywuifGUA1a+ysdPsm8J85sKQjqzl0P27WgTsMITvkzTKlLoQUi3QcmxfDWCp9BkRxNaTpFCz8sKXlQ2ArLZei5w6b6Ui5EVRy0SukU2AQ+2H5/2FtFBzPWR//Ak8yKWXZHjTjnrZ8hZqYIwv0kNdGTzVSEG0DCTANkKMZX8V7pcQkXUgjjrXJIl1RUn+oQEakjzY06Aj7t11QnxSmaJle7tgZ3AU/ToNZjKkUWBpPrtjOiW50UJ+SQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000013, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Masami and Mike, On Sat, Apr 20, 2024 at 2:11=E2=80=AFAM Masami Hiramatsu wrote: [...] > > > > > > IIUC, we need to update __execmem_cache_alloc() to take a range point= er as > > > input. module text will use "range" for EXECMEM_MODULE_TEXT, while kp= robe > > > will use "range" for EXECMEM_KPROBE. Without "map to" concept or shar= ing > > > the "range" object, we will have to compare different range parameter= s to check > > > we can share cached pages between module text and kprobe, which is no= t > > > efficient. Did I miss something? > > Song, thanks for trying to eplain. I think I need to explain why I used > module_alloc() originally. > > This depends on how kprobe features are implemented on the architecture, = and > how much features are supported on kprobes. > > Because kprobe jump optimization and kprobe jump-back optimization need t= o > use a jump instruction to jump into the trampoline and jump back from the > trampoline directly, if the architecuture jmp instruction supports +-2GB = range > like x86, it needs to allocate the trampoline buffer inside such address = space. > This requirement is similar to the modules (because module function needs= to > call other functions in the kernel etc.), at least kprobes on x86 used > module_alloc(). > > However, if an architecture only supports breakpoint/trap based kprobe, > it does not need to consider whether the execmem is allocated. > > > > > We can always share large ROX pages as long as they are within the corr= ect > > address space. The permissions for them are ROX and the alignment > > differences are due to KASAN and this is handled during allocation of t= he > > large page to refill the cache. __execmem_cache_alloc() only needs to l= imit > > the search for the address space of the range. > > So I don't think EXECMEM_KPROBE always same as EXECMEM_MODULE_TEXT, it > should be configured for each arch. Especially, if it is only used for > searching parameter, it looks OK to me. Thanks for the explanation! I was thinking "we can have EXECMEM_KPROBE share the same parameters as EXECMEM_MODULE_TEXT for all architectures". But this thought is built on to= p of assumptions on future changes/improvements within multiple sub systems. At this moment, I have no objections moving forward with current execmem AP= Is. Thanks, Song