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 11FD5EB64D7 for ; Mon, 26 Jun 2023 17:48:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8981A8D0002; Mon, 26 Jun 2023 13:48:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 849428D0001; Mon, 26 Jun 2023 13:48:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E9A98D0002; Mon, 26 Jun 2023 13:48:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5F2578D0001 for ; Mon, 26 Jun 2023 13:48:55 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 013A8AFB2C for ; Mon, 26 Jun 2023 17:48:54 +0000 (UTC) X-FDA: 80945634630.22.E667F7C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 17ADE40005 for ; Mon, 26 Jun 2023 17:48:52 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Qn7TSH5f; spf=pass (imf12.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 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=1687801733; 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=fFWuzhLLiGkinhaWeToFLkDX/dcx5OWER83aW8VgRow=; b=W8urnI85D8PGGVZdtE7n9bTKcrzJVhMVK1tqnxMgsPmACtcPe9ChPWO3vdx7oFrDHBVBGt szS5dp2HjirYxYKz2GQNMXteZPHZdTqidP83VDWtF6ShlwVvFGZILgDzmY7jSORDdsoE7/ OTz81I4NPIfTdaXZGFEyHuyox634kRQ= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Qn7TSH5f; spf=pass (imf12.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 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=1687801733; a=rsa-sha256; cv=none; b=3j45eKda27VeUF5wgCsmLYGCLRvMP8WCR5O1Um2wGhOz3GAoosidarv1Sdx304NdJClmI6 DRnlJPadjk+EiJb4l0g//DDRbDzb72eCmpVvnfxKupKGlrT/UPzXggg+GdAuAUmU2Z1Uox 7Kus9n8LTTYOY9iWD5ZGBrEjINsDDhw= 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 05BCD60F19 for ; Mon, 26 Jun 2023 17:48:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64161C433CD for ; Mon, 26 Jun 2023 17:48:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687801731; bh=fFWuzhLLiGkinhaWeToFLkDX/dcx5OWER83aW8VgRow=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Qn7TSH5fBy879Kn45s8a/YCOEx1oTS+0VCd/Q+kNmCB7uRTTg7TK3CW2K5FgKL5SO RoBVKuhnNkjoWxoU5K2xmCMLOL3TePePVRvun87gj3KrTnQpXgAMXLWOX/L2U+vGMb wy6CqBDWmWhCmphC6Q8EiBNziTaMXriaczMp6DJiN1Ej/WUjTzJ6N+lvXogj4eiJcj PJKRTqLP+Zecd+1KGIrC38/JsFePpZ84jlJVtuUPeUpe+0KdJssjei1KlWQsAb8xqI wX+VWs0F7zWSqHLgR+NZLp09+VOq+k1qPrGR83NuByW+4SQgicdeCKOv73ZNgnYywR IXCdgqJe6fP2Q== Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-4f954d7309fso4429093e87.1 for ; Mon, 26 Jun 2023 10:48:51 -0700 (PDT) X-Gm-Message-State: AC+VfDzj00g1fpnvsDiRbGv4Vn54GguRZo/gF9D/5JAe2AxbCZsSsIXQ FXDTi/KlglUzmsi7S2DWg6MLkiK6v+VH2TqLVcQ= X-Google-Smtp-Source: ACHHUZ6w6e1OYy7QM9S+YTdK71Dx4cd9s642AcRaJSfPZb8UXF8n/hvi2zuHhdV8C7DcTgUpaxVtcUwpuH0YchvBFOg= X-Received: by 2002:a19:5f5d:0:b0:4f8:5e62:b94b with SMTP id a29-20020a195f5d000000b004f85e62b94bmr8655403lfj.9.1687801729333; Mon, 26 Jun 2023 10:48:49 -0700 (PDT) MIME-Version: 1.0 References: <20230616085038.4121892-1-rppt@kernel.org> <20230616085038.4121892-3-rppt@kernel.org> <20230618080027.GA52412@kernel.org> <20230625161417.GK52412@kernel.org> In-Reply-To: From: Song Liu Date: Mon, 26 Jun 2023 10:48:37 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc() To: Mark Rutland Cc: Mike Rapoport , Andy Lutomirski , Kees Cook , Linux Kernel Mailing List , Andrew Morton , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Michael Ellerman , Nadav Amit , "Naveen N. Rao" , Palmer Dabbelt , Puranjay Mohan , Rick P Edgecombe , "Russell King (Oracle)" , 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, "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 17ADE40005 X-Rspam-User: X-Stat-Signature: p9657fk3jzh7366etositbd7jt3hipar X-Rspamd-Server: rspam01 X-HE-Tag: 1687801732-63816 X-HE-Meta: U2FsdGVkX18uOC8xeKyTcPIRzXEKGWXwpewuTpa1umySJq1M79TJk8D/5h9O3JZwsfCbUnZ/pd+WmDahPk96Jj5FMGa63h41oKmJnd9nrpazdH/DX3KJ9ONrAp0Ji03NvQvussFuzuGPOy9SZhZCDLhCSypvHiPmWZjGOwop5d+dfTJxOnqBKzCNkOGo2oFqoOMIzt08ik7ifRTh4G+B0kicAZ9pyA7u1ECva3Qti1+G558vi3j5jEDFjchM43CN6OrGgbaeoixIIvjVb2fWU7YZepKzH18lJVMdQOjwHo0MxFA2GnVhqmOYUchz5zy/4XyLlHrc3Nzp9CIvbDHJ5StLmQii5BHh7bSGmEba8ZoU1AzGK/ozZ8YWMW83K4KaVP4HrTeVE+T3LZeyT7tO1MGfD74w5dJyyg9QGSeQpiLmIbYMree5z58IgnMUjkNI4HoNVM7EFPMqsvuQgT+gEBwVm1p9ahTiTWGjozhn1jaOArjfjcxbAoTlNqC4EOcBBCW2LQ+t2VG7GqnURzFw/xECJxUhg/91WB0FBUEMRLL6yJ3J5ti6/+UpNz91bAQ1hnzl9AEKm6a7nkGIGOFLJ6+2G3mOLcnfOEVTGFVmAGtxj/jEx2KIdQqfV6cCxRaDCYBpL6oDorfLq1fFXwdBlU+U4QU6t59sdIp7i49K9GtXbWRE3ouq//2SxTjSN3h0QjM/wRRqWqpd9mYuL6XctcklCXHYALsgO6yt9Ug768ujDGg5WNRbvSNDPX5ZMOAznump2BW2gWDm97my+jbU1+9cbp+10RKT0c3IcTC7UJXTGzmzA6xD6UWHMaciIqzjQjSz0iNA7GQK2Mu6XHIvkdyLrBsXaJ52jpH5svM5kNNgZu1WGC5NYTenk8J4qaytaVb3EBZSfb2R17aF8ysYKeLSMSi4Hl6u2EGKo5QGNc6rDvAq07eGh81NE9wDFXz/uKd7VofSYX7uVcotvNu hJL32IIw OZeMglVDpw0jEh2u2IZjQcmsDIF1CzQQDLF5N+qT7YDE+mmQp0mvr+2LJUQLz8jwTRdeYo3Iazj0A064YEAsU5tvndM28y3G6E5XjCZZ97NQu9Rh/81b0qyqSyjmyEj4z9BFNdh1z5lVfCMzCrOMU3D4K1QYqtcIdhaogLQpjixQ2kmeeVAZ+rbq8JsEFJI3iN75e1VVasDCpZLY08bMqAVrkKctYHXF5hDIEmoCG4U2bNP8SMSbEwXaiVt1vOE4WWTCmeCDf5tdhs+C3C8bQ0OxvxH+0DoHeWpS7WBeEwAN3sQRATA95QVszA/9tyd9GK/6F12TGcqJlxX45NnNddRP6XbqZMUfBMAUBhg4R7tpmo1gh1jItPUf1JCqNu26GeoyRY8KDxJMZuHBMLulJ+Wn3a/Bl2n9OfbqJb7JqcMk1gcsA+7IDMKd0HBp4drRVc0l1vivru72uIckkhzM34nv8c9AMu7PzXXLsY5N2B0yFork= 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 Mon, Jun 26, 2023 at 5:31=E2=80=AFAM Mark Rutland = wrote: > [...] > > > > So the idea was that jit_text_alloc() will have a cache of large pages > > mapped ROX, will allocate memory from those caches and there will be > > jit_update() that uses text poking for writing to that memory. > > > > Upon allocation of a large page to increase the cache, that large page = will > > be "invalidated" by filling it with breakpoint instructions (e.g int3 o= n > > x86) > > Does that work on x86? > > That is in no way gauranteed for other architectures; on arm64 you need > explicit cache maintenance (with I-cache maintenance at the VA to be exec= uted > from) followed by context-synchronization-events (e.g. via ISB instructio= ns, or > IPIs). I guess we need: 1) Invalidate unused part of the huge ROX pages; 2) Do not put two jit users (including module text, bpf, etc.) in the same cache line; 3) Explicit cache maintenance; 4) context-synchronization-events. Would these (or a subset of them) be sufficient to protect us from torn rea= d? Thanks, Song