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 02597C4345F for ; Fri, 19 Apr 2024 17:33:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A3DF6B0092; Fri, 19 Apr 2024 13:33:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 853E96B0095; Fri, 19 Apr 2024 13:33:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F4316B0096; Fri, 19 Apr 2024 13:33:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 51B896B0092 for ; Fri, 19 Apr 2024 13:33:20 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 01CD61C030F for ; Fri, 19 Apr 2024 17:33:19 +0000 (UTC) X-FDA: 82026977760.17.777B631 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf30.hostedemail.com (Postfix) with ESMTP id 65F5B8000A for ; Fri, 19 Apr 2024 17:33:16 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hz5HA12m; spf=pass (imf30.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=1713547997; 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=thIwesszatYaJ6sctPtDKM7mmBtwkWZpjuK7ZWkjfTQ=; b=3P+duwIgtK0TbqqXgffMPTrg8+3+W/wdd8k2QkEX5s74Gsmfd61ATQmkUyQ7bWWWZsSMQk eaIBiwsPP4nr2N55wTrXTHw6uTkQ556MkZ4v3BRlX+5sj/1dZt+8Ldkn7F8EjDlqSm7RZQ qCKixEXoXJmS1B9vgvL71tCm3ynDxwk= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hz5HA12m; spf=pass (imf30.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=1713547997; a=rsa-sha256; cv=none; b=qsc3NamYTfy45BiGQyVibxtry/WCz4Sp6pIJ533yOGJwv1H7UfStbqJvp0R2spveBEEM3u c5Ks1rxNEopD0amUPpbRSigx+D5JucpxviVbkcU1Nca/4keS65rLaYDll8D4QN1LVLm66h nPkbXDl337iMu4QHYaa02Wras8ppaR4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 0C806CE1B57 for ; Fri, 19 Apr 2024 17:33:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4680AC072AA for ; Fri, 19 Apr 2024 17:33:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713547992; bh=sVegppIF/niXLnTLCcBWzkxa2L1ow1Dt9dF+ATN6lsk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hz5HA12mGjDKfqVeo5OEuWAXF7TDIh13CeKJ5HkGMfIHVK1Eso9dNbU7tD++O5rKF 0sUzDpSaXME0yKE/l8cgrQWT0Z2sDz6N+xBa5e2JQHDmU99ok3qp4SzMoIVGoVpEwf FexKUZUXH+JNYzZwL8sv4Ui8jBZVcdQT31/FMgdQ0m5wu28goRuvm3B21LF/otZU2O XoCzXXYsLp/0EakVkhWxF02OBZtpBRVRnjNTzYgCBl9NhL3X5Jwa9LaLOt0hsxr64Z QzmDAxTOkYMWvKL9laT9o+PUmzjOHAVeOdb0I3eJy8krCoZrJBeqor627d4pzQ8XKs l7bBiZSmzj0Uw== Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-571ba432477so2353501a12.1 for ; Fri, 19 Apr 2024 10:33:12 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWOYDVxDhryGnvMmSgnua3VPqynjc/mIyhm6l3pG/+bUblhwyZvCfbnYWdEebWfIXcaEy9VpXEbaO+wcJjsMJZuTbM= X-Gm-Message-State: AOJu0YxyaBiWsEC2fCGIfj+ZIjEPgutFVZLgujELqukDIp2plKutiqfR Xb/2vcnxBh4RN2DHQk4iP4s29bwyhzXpx5YxaQYGY38Y/663lCEduX1+n8RPRNHAGISDxh5VaqO 44rO8BQCm74kfe5kxwv90/vMxLBY= X-Google-Smtp-Source: AGHT+IFQL0ZIY0ZfQ4j9vl7SSSW0Y7vt5IE5s4aAkthQ3+dt0vC//uVhsYgqRpBdUKo6ap4ecg5hjMNFhNToQ1hMBQU= X-Received: by 2002:ac2:5a1e:0:b0:519:296e:2c80 with SMTP id q30-20020ac25a1e000000b00519296e2c80mr1475078lfn.15.1713547970497; Fri, 19 Apr 2024 10:32:50 -0700 (PDT) MIME-Version: 1.0 References: <20240415075241.GF40213@noisy.programming.kicks-ass.net> In-Reply-To: From: Song Liu Date: Fri, 19 Apr 2024 10:32:39 -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: r9oenyghc378jc478cx98mph8gzn9ppd X-Rspamd-Queue-Id: 65F5B8000A X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1713547996-793012 X-HE-Meta: U2FsdGVkX1+BYtCwgCULZe0YcmitUk+xChOAJumDbYHWXONLzsdgIcYnoB9qel7Vtu1yyV82AZ5dq2tXyu3an9YWe9yBGS4k66syBS9csMEFOt5QgQmDMC1Ec8oRT2T96EegyQYDQwcVp015k+zKAt0oiAbansX+i/QTqY0maePn1/VIcJbPCPH7mR5XdKZIiTXT/jmdW6gJcB831RONxsyALySAEavGWAU+MmWp3nbch4vhsaPDAr2m7n6Rwfj/C/9L5rokOx4wKZAt45PYNGJgaIPVQSQ+x/rHNrIhlDj81lLkzOMbgOnmwcrYx63EL0sP58hTG/0PwCB9sZ5n9wvI89lf4p76KCUAvOoBs/7u0omIpvdG+HzwSZDG2UYr2+0LH1WFCbfxVYshCTMuh18OG7zdXG5YXuayMr/oGNyUqQzXPUnxbYRzvu4EyxlPuj/gP93JE8nYKF+Hq38+ukBMDVdZ2oFuUK7/vuqBrYK4yvX5nF/DP/VsYxLXIWmQhycrrjtR6YZC5KnzEgHQMeakuoNkV0+sBJdB/Tz0V0BfC7LomwNFaDvOVPDCbTtMF0Drh2RTP3NaMhq2R7tNi68raZfkHjNRIqBCv24LzbdpMvNU5hML5qTF5UYa7hfirXcaWU9NiYN6gsO2icshoDOvZfG8vqds2gjwytCKpAUdSytNEffcVTj58CEb2/SZpG6ON2k4P0oWp+zP5f4yyhMQOIxLxEBHjKfCgYMC/grRTtvd2sCdBUAx+pkKB3Dkbdz8BDFfKk9gc7lySoXqmyglR9mep3nX/DZicHMjUaLk6CyHfyko7EFiXWE3yIjk1q9vQN+5J6K2UABP0FbMUTi9fZpXLq6SZSIkpV/MXAFLPZsXuxrd0DAoYubp/OHTYKKQm1rGhdumQtuWYzxp2AUX5yrOvaN4focaM9IVSAjyPNi46005XegG3j39vBX2+dDKV1VuBeOOYxQWv+1 tMUDo5Dy eAj3x21xDP+Yd3SG98VAb9265A9szB/jvNekK6H71dZEwZxENV78QlAeDVJlbkQp+LGQdkLFUaZyLxnumPIoT0lkXfKEz4wVqwXlJfPhPD+hlsbR9mAN7n9VoUH/VGNWzIKqmk8t6iwNj7JOPk4BLbINe6KqxIWibglaUAdVB6djaoMc06T7v7Az1sa09/v9T7jerZ7bH5VcTwL0l3/81qcCLMsJ0z2vCHlaN6IJZ0be2Qbokl9Z+RoWw27vEgskAG3gCbHMB93zN+n0AVkd1NhYCSEllrQLZ+bP0oUsaO0fccFkt1SLBuT0MrQiwccKV1mvOGDpvYuHHmoPSnuNwM+khmvzvo4vbte+b+NHgYEsQdABMRN53f6mIN8T/Wrrq5OMLmNlsOrZEHLc= 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: List-Subscribe: List-Unsubscribe: On Fri, Apr 19, 2024 at 10:03=E2=80=AFAM Mike Rapoport wr= ote: [...] > > > > > > [1] https://lore.kernel.org/all/20240411160526.2093408-1-rppt@kernel.= 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 si= ze) > > { > > ... > > 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 work, > > 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 space= . > > For other architectures this indeed needs to be fixed with passing the > range to __execmem_cache_alloc() and limiting search in the cache for tha= t > range. I think we at least need the "map to" concept (initially proposed by Thomas= ) 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. Does this make sense? Song