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 08A0FC04FF6 for ; Fri, 19 Apr 2024 21:42:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2CDC16B0088; Fri, 19 Apr 2024 17:42:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 27DAF6B008A; Fri, 19 Apr 2024 17:42:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 145D36B0092; Fri, 19 Apr 2024 17:42:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E45376B0088 for ; Fri, 19 Apr 2024 17:42:56 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 984201A0A5B for ; Fri, 19 Apr 2024 21:42:56 +0000 (UTC) X-FDA: 82027606752.01.8B9FA24 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf07.hostedemail.com (Postfix) with ESMTP id 40A3040003 for ; Fri, 19 Apr 2024 21:42:53 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=m4HnPRVF; spf=pass (imf07.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=1713562975; 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=Af6anyP9dkFAnpnHgVPwZT72TVuxloyY0iL0DnoDdx0=; b=13PgrIDHEEbxjpttUffn6oNpTkV/gY8WddDgJZ0rb2k8ZPank3G//g5pGEOzs0NpGZNQrc NEyqfvJjkZtb594+OeKaNTNhKhvED1SnteHaAHhMmpt/c32d3pJ9u/RgUNFseCQY8pBwGy NcxFcA/mYD+6WSOe3nMDYzO+lrzBFc0= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=m4HnPRVF; spf=pass (imf07.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=1713562975; a=rsa-sha256; cv=none; b=TU0/glq+Rwh0kSzrsTTbquy7fEJFqPz3eknJC3wkZEX97viMGFqFH3r41cNUOKxv4ZXEfa 4hcnMclz6SjxxQYLWGhhcjchNezISEx1mnw5JQV1MWpGLz9FWZ5QoGo2zYZireZALoJd66 QgE/iKevbNycj6KpkKnD2xfONGl8VHw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id D58F6CE1AD8 for ; Fri, 19 Apr 2024 21:42:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06B5BC2BD11 for ; Fri, 19 Apr 2024 21:42:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713562970; bh=TCFccoU0QynIlhNVSwfE9PBflv6m2g3eer2smjEjHo0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=m4HnPRVFmWRnbZz8jQgaboXaGgGHKM6NiRHPnWxYnXriYRx79b4qxLh61hmOGchcc BeAAWFrwxoxYJkYzlzLPxW1HmMSHuQQ804wgQ9HB2dliWoJAMe+WuPJgC73w48qsaY 8p0FVzWBN/to3b7K3DQ7j/PsKeJd4uV1W+Gch+w6NTUGukNdlDn0g0cB3UnAb3jQx7 PSf8rBW9ZQhouGbP6ra7uug8JuzEdjBEg+XfggIiIEQt0h1ve10SOMFqY9M0wevTbL Eq6Fd3MJ0oNRWLCEy29E4JMXnQs2SedtXJyicXYfXpkSeddtxs7BNvLDpvfmOC5KQu tl/dlpBBhEWSQ== Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4199332c1dcso5974885e9.3 for ; Fri, 19 Apr 2024 14:42:49 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCW9Id2xI9ge+XS1gpzA0CBEEjWKGo4+C2LzlCi64lDuzBbjDUHdlVX+o9LLUsXetpRL2LvU3TmmqVzQoxPAESXuDN4= X-Gm-Message-State: AOJu0Yw6iH4IT5EEZ5U2w7Kkjz5mcsctnpmWkaT6oayUGe5q6TceBr+y +Cp+ym3cWj8WRY1OcEuGCBcwd1US3mF+oboGuBPAo52Jm2TfFfu/K9Rop30lzcymSluiAMri7uA CkJjxk++tQsibStaFsKfisFQNOGs= X-Google-Smtp-Source: AGHT+IH4AnwX5zN14P6kYOA/5jMldeW1Bv8FPwjpWGtVTE89ihBaxTYgE7/68A2MjqxVZZCm/ny8Sr/SdDVp6qchZyo= X-Received: by 2002:a19:5f4d:0:b0:519:5b84:1038 with SMTP id a13-20020a195f4d000000b005195b841038mr1897119lfj.20.1713562948432; Fri, 19 Apr 2024 14:42:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Song Liu Date: Fri, 19 Apr 2024 14:42:16 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 05/15] mm: introduce execmem_alloc() and execmem_free() To: Mike Rapoport Cc: 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-Stat-Signature: 8a6wc7y6xmr4gypstwmnrh7w8s1qef9r X-Rspamd-Queue-Id: 40A3040003 X-Rspamd-Server: rspam02 X-Rspam-User: X-HE-Tag: 1713562973-467575 X-HE-Meta: U2FsdGVkX18+WxsQIvk63fMkmXc47SrMnu7erNCDdNMISbn8HwWmdgj5RHVJAWfxwLyKHIdr46ERQhM25CLUBMSf63rNvqM11ro26fY5jx3a159aZPvR3JnNp8Ei4R2LqwIbNLLbwV8WxKpOHgLhWUreETI42vlUUWAh0Pu+KsLcdDtVqExfIl9bhaYqjlMYcX/cVhOK8QzafHmj5mg7dzQaFOAYwVnc7byTIT4aTKb+lGjnJXdzA59UV3f+6yyKjLndQrHgCF81k6AeHe9NkZ4ha+ZNM0vVAhWT0JRHC+520spDEw16JDTIt7k/hdDve3AHz3iy/0OpZkpfDxOteK9D5dWOVCkaWsIR8WTQEaEDEvMwVUK5ixBnctWYeehzYmS77GEB54c7w5VrQ5ubsS38TxQ7NMmzxB67YkKEhuoj3N16k6txu0UkbrQMI3A6wiO1Gv56Gt2rF81SrozgG7pFc3WXBPzBW1He95Z22P0lZR+lEp2d4oe/4SgdwaAzCHBrNPjNmU9NzTn3tBKxOYZnyHMNg5Zzjfw3eL+QZSd68NP7B4pCTBqXr3y+EborHOp0pqi/+K7I5utg/DLL0SHYjCvcoreJwPDMJfZm7HDnD/QtWaH+yIbgqiF90mHNkwCjiwg6jC0RjpNZ4eDb//MwPDXdI96vcGBE7fPFJuD4Sxsy/kwQ+4kgeuHvxzYxIvonnuA1og4CioXZYLY2jcYgqUAdPeMbz7aqMoXzndwipHsbPRJy581vWVS8p9BP2gqxopIov3kC/KtnbFyHHVEXQG4T8pRokulz1jOfS1MdscrFkzmHpa2qcZLlLYyJo+Xv/HaF0zL4a9iJ2HvkyBdjkFxdZcQQh04xbzMDayw1194f/SqrH/2V2TXlrDaTgvrMoqIKTLWNA/9jcYfn1t/xy4kfKKT+S0GrM4NVKme8QsP7ktJlN4cYjPzKJeIL8HO+jrtipkryulhMX7Q CvtxWsDs 4xJGYcdOWUAgc7JC9ve/+Biwo19De+SrNCTHleGp0DJgg3mhcAbIbFoMva1P81gWphB1p X-Bogosity: Ham, tests=bogofilter, spamicity=0.000018, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Apr 19, 2024 at 1:00=E2=80=AFPM Mike Rapoport wro= te: > > On Fri, Apr 19, 2024 at 10:32:39AM -0700, Song Liu wrote: > > On Fri, Apr 19, 2024 at 10:03=E2=80=AFAM Mike Rapoport wrote: > > [...] > > > > > > > > > > [1] https://lore.kernel.org/all/20240411160526.2093408-1-rppt@ker= nel.org > > > > > > > > For the ROX to work, we need different users (module text, kprobe, = etc.) to have > > > > the same execmem_range. From [1]: > > > > > > > > static void *execmem_cache_alloc(struct execmem_range *range, size_= t size) > > > > { > > > > ... > > > > p =3D __execmem_cache_alloc(size); > > > > if (p) > > > > return p; > > > > err =3D execmem_cache_populate(range, size); > > > > ... > > > > } > > > > > > > > We are calling __execmem_cache_alloc() without range. For this to w= ork, > > > > we can only call execmem_cache_alloc() with one execmem_range. > > > > > > Actually, on x86 this will "just work" because everything shares the = same > > > address space :) > > > > > > The 2M pages in the cache will be in the modules space, so > > > __execmem_cache_alloc() will always return memory from that address s= pace. > > > > > > For other architectures this indeed needs to be fixed with passing th= e > > > range to __execmem_cache_alloc() and limiting search in the cache for= that > > > range. > > > > I think we at least need the "map to" concept (initially proposed by Th= omas) > > to get this work. For example, EXECMEM_BPF and EXECMEM_KPROBE > > maps to EXECMEM_MODULE_TEXT, so that all these actually share > > the same range. > > Why? IIUC, we need to update __execmem_cache_alloc() to take a range pointer as input. module text will use "range" for EXECMEM_MODULE_TEXT, while kprobe will use "range" for EXECMEM_KPROBE. Without "map to" concept or sharing the "range" object, we will have to compare different range parameters to c= heck we can share cached pages between module text and kprobe, which is not efficient. Did I miss something? Thanks, Song