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 0D801C02193 for ; Tue, 4 Feb 2025 23:36:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75A6E28000B; Tue, 4 Feb 2025 18:36:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E3C8280001; Tue, 4 Feb 2025 18:36:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5847228000B; Tue, 4 Feb 2025 18:36:40 -0500 (EST) 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 39CD2280001 for ; Tue, 4 Feb 2025 18:36:40 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E73A28036F for ; Tue, 4 Feb 2025 23:36:39 +0000 (UTC) X-FDA: 83083874118.20.218C266 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by imf06.hostedemail.com (Postfix) with ESMTP id DA98E180011 for ; Tue, 4 Feb 2025 23:36:37 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=jrtc27.com header.s=gmail.jrtc27.user header.b=MIc81l7n; dmarc=none; spf=pass (imf06.hostedemail.com: domain of jrtc27@jrtc27.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=jrtc27@jrtc27.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738712198; a=rsa-sha256; cv=none; b=h7nT0PATc3fGO9qilmCsf1NunDjMUNHO43YyXhPUojXBkG4BbalI+CL3cNBgAvayn/0RR7 AImIDRIdbXi8VCrYyw02PsEIbYJS/k8jKpczWjzGoECQi4J9dztowOow5uGzSBcmxvp/FT aniCt7mE97Uqe/SRFsxDetieU7VOKq0= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=jrtc27.com header.s=gmail.jrtc27.user header.b=MIc81l7n; dmarc=none; spf=pass (imf06.hostedemail.com: domain of jrtc27@jrtc27.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=jrtc27@jrtc27.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738712198; 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=QjEre/G3BLqcrCF5wreFajQVoRGv9unmtvDg4S23UQU=; b=pSPcKwnDrFDFeIcrJ6x5uRgB/JLsmTyj4CYFMzPDN86KzlxjcDET2BgJxk1ogzptgie9SL 7Q2JBYH0qZUuLhn6t66xctbAJK427G6Ju8S1m92NSl8j37d3sbmoVP6lyte1zA/rtOTtC6 hE7O2SGvNdZ0p+wHtlFfey25oP7zmbY= Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-38da940e689so656695f8f.2 for ; Tue, 04 Feb 2025 15:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jrtc27.com; s=gmail.jrtc27.user; t=1738712196; x=1739316996; darn=kvack.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QjEre/G3BLqcrCF5wreFajQVoRGv9unmtvDg4S23UQU=; b=MIc81l7nM5gpNoMFhuUp4N478gprLpHzWQH9bdyfuKS+5y+ZAew9jso+satjnzsXxm AI1ssFhMZm+D7gsiAh72VtD1+GwE+9JIrzbEjMwIGBlKDLIC+i3PJ3ASWOy0rt8ICRjD UH7JWmlZ3Cq0EMVr7x0wwEISsBpczMtwiZK6CEYSBVvw3FW7mBRKQhZ6QYuahNx232Ix 8BXt9f5OkBO++xGinrR0hZLrza4IMRyv4kvo1RuGvtLrxp8rUvv32bTO8uy+GGGCMGfm FcdczROg3FzIa/lZNYK0mBM785gMZbIbLI/gxH0Vofa7Yyuqldmlc0r+/POs2NGrf/st ENbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738712196; x=1739316996; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QjEre/G3BLqcrCF5wreFajQVoRGv9unmtvDg4S23UQU=; b=Yfb6pUlU+hbKSo3VBLuAqXTDeMCbKLdKdyAYZJv4O+hzSMlPDarWCPSTnjU0qAqwv+ 2WR0M66U11zLquWRqJMb1kH6WQchHfhp2MQOYH+hi+4hzpM1STiWy6Xqi2YHYHvNU64G 6NbmE65W+Ly6fJ0rW7Vkc0ibGKpSo6tbY/t5dCP7xHcquh1qLit4Q0JBYKU0LTmYq8Aw gPi+XWTFb8dYwxuYlP2K/85Xcam6F1EnTKSIbCSLcVMKUZ78u9btPFccBBB9HkTdj68w YzmmISOhyYLVm495MAsxrsHqMYvKfnHWXKduHXc1hCGXnQ3WZSEoZaIr1l24mKsgZawr 4EBg== X-Forwarded-Encrypted: i=1; AJvYcCXGD+lwNiebJnd9QUhq0UmB0qoR4E792nZ2+O6NtGU8Hgb4xNTnLLd38FYWFAEiINP++pAJVLOc5Q==@kvack.org X-Gm-Message-State: AOJu0YwNp9cS3wZx9KoLMu6Io3h/nTyntGvK/rY5I50wQsVfAFuZRh4E 8KXuHW8LabTxIXCbwv9b+DJ05kBGV5n8y4IYiPdvlejBhPb8RNr4WCWuGRR6Gxk= X-Gm-Gg: ASbGncuE6hCox2P9vZSU1bGZMf8Lvr0PlAhq4AZsNLhAlOjwMD0k94Jf1ZN3SW7dOJM Qf0oB+3s55zFFKV0Zau3ySJCl4gZI5zxwlUO9Ik1SFQ/a49fISjLaEKu8QFVVM0gVhIUl2OdjMK SEKIGnxsfdZ+kIDvwwvyOqzOlNcEUS2wiykw3k1xp4TMOBs+7bkj4g4MjGusGEwO1N4tdC2O8C1 OgUicUK2FbLiorbHRCnRrqQA3DE0duwY2kg9WKWDdkfJP4V4EMAIB/at3nCF6+JejXMh16Aw7Vq ELzlu15WS+B03AMp05wx9fm2XrHW X-Google-Smtp-Source: AGHT+IEbYs1SnazTxli1ivvCCDO1Cn9LUrxieFBceKbd6w0ve1uSZrVLlYscY7LZ+tYIHGaLpjoemg== X-Received: by 2002:a5d:4c47:0:b0:38b:dc3d:e4be with SMTP id ffacd0b85a97d-38db49214e3mr355994f8f.51.1738712196024; Tue, 04 Feb 2025 15:36:36 -0800 (PST) Received: from smtpclient.apple ([131.111.5.201]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38c5c0ec369sm16900115f8f.8.2025.02.04.15.36.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Feb 2025 15:36:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.300.87.4.3\)) Subject: Re: [PATCH 00/15] kasan: x86: arm64: risc-v: KASAN tag-based mode for x86 From: Jessica Clarke In-Reply-To: <8bd9c793-aac6-a330-ea8f-3bde0230a20b@gentwo.org> Date: Tue, 4 Feb 2025 23:36:23 +0000 Cc: Maciej Wieczor-Retman , luto@kernel.org, xin@zytor.com, kirill.shutemov@linux.intel.com, palmer@dabbelt.com, tj@kernel.org, andreyknvl@gmail.com, brgerst@gmail.com, ardb@kernel.org, dave.hansen@linux.intel.com, jgross@suse.com, will@kernel.org, akpm@linux-foundation.org, arnd@arndb.de, corbet@lwn.net, dvyukov@google.com, richard.weiyang@gmail.com, ytcoode@gmail.com, tglx@linutronix.de, hpa@zytor.com, seanjc@google.com, paul.walmsley@sifive.com, aou@eecs.berkeley.edu, justinstitt@google.com, jason.andryuk@amd.com, glider@google.com, ubizjak@gmail.com, jannh@google.com, bhe@redhat.com, vincenzo.frascino@arm.com, rafael.j.wysocki@intel.com, ndesaulniers@google.com, mingo@redhat.com, catalin.marinas@arm.com, junichi.nomura@nec.com, nathan@kernel.org, ryabinin.a.a@gmail.com, dennis@kernel.org, bp@alien8.de, kevinloughlin@google.com, morbo@google.com, dan.j.williams@intel.com, julian.stecklina@cyberus-technology.de, peterz@infradead.org, kees@kernel.org, kasan-dev@googlegroups.com, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-doc@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <0BDD645A-3BBE-4A85-9098-257B281A3BA0@jrtc27.com> References: <8bd9c793-aac6-a330-ea8f-3bde0230a20b@gentwo.org> To: "Christoph Lameter (Ampere)" X-Mailer: Apple Mail (2.3826.300.87.4.3) X-Rspam-User: X-Rspamd-Queue-Id: DA98E180011 X-Rspamd-Server: rspam10 X-Stat-Signature: 3wydsdk6qzbr7ros8az691mbt8npzitk X-HE-Tag: 1738712197-604568 X-HE-Meta: U2FsdGVkX1+444LlfyeJu0LSARh0ndYi3I5G1WDXrmCxS3+tx4E6jSB/kRvQKgEGGQ/+a85rLNuoXTcze5BR2GnE8et991FPSPs0C/tKl2w9c+gs9GMplX3+VsJyv3QeGSbw9bt/5aPJ00aquxsKSztDAUD4RXRJnx7B0G6Q2x+yxjOL5Z5h0zCRhKhbvpdPKZ++vQfd/IUTHjOlH4qq5qek9B0ldikzJGMjhTorV6UmKJuEIb7raKGSYn7ej80drs91EvX/oISzZ+1NiiyExd7fz1vSvb+5Rd4IOy2NX3xb0iAIrLDaPLDt0GQYAvLH4l124U/bkd/Zqkn1BYUH8GDQQg8MgNpqWUG1pYdRdSXM4pmZ51p2TbKpzfoVWKCsGR1yj3TsUGqR6hPloPp8lsqU7bYehlzSzV2ApN83UKiOkJOqGvtFYOkPqtroJ/Wr4P7zeQ7VW07yrFL2V5XjFd4WOnyQ9wiflGyJdrkpfs5jKFeFbzXfd3jM67HxCv8Uq20hPRVr5ykSTjzK5uGMmrkgGuY7Y+6h6jAI9oxwomF1+qYRlRL0hyy8rL1EGJsD93rX+zcHn7PS1Su+KoOl1OdIfNe77Yeln283w5OMMRGjGSNuNmalKTXExivc3dm16sY1SrpM448q1kbg9Kklwxvx+OBMeHT6ZhD60uAZNo8SKw5ZGQzZn6qTWvtnksFqAIukCBajOI9C+iyUFbkU/HD/WsHgvJyAR2kI0xFbN6gyNReH0X4x3FwzzQL+a6nLUjShUA4wVE84xHvJBqPkMz0hLhiPW3zBFHqW/C38Pq+SgCEFJ23WZqjtcZhjHSJ5yc/HYH9oc/aU2g70Rw5pib/Nbxm7t9kdH5HnSUXYPF/I48y+PW7y30LAJ6EvDKNUCFKRFI9Z+4Z/5l1MG4Mxs73FlKAX8aXkZTtS4YzfqR996MDkWpjcRW6/ulARE/35jkJ97ckKi2n70WIHzal ZPYVyfjt IHasVsBQIE3Dzbt9I4nFLmP+hdGXxRbzB1BWUoQS40WXBPAvGRbJeW9FrRC+G/uqJWcXkZxyNmZU8bCHsjB96Fh0wdykbgQqcik/21McKDqX5dK7rQGJOI0vJNe/l4FWnOMoQFASz0uQkgDeaNLUvXaAaudfFAMGeT5P8Y8SQT/+CR3Fn5rYPXnStRzvsBT/w+FKMmYyaf+a04430UgvtngTH52NdRj/uW8J/BEY95rpSGsXJT5DGCe1QXRywGKv2CRDMavGZPW+H8ALbenOo1HrI6/fP2E7j9Q/OcVghKJE+2ci+jigKTiEwYfJLTz1P8klwWgVWQItJtg9lndqVDfIPL+iRzVPuUzlGtFR9Jo4Aq9MmcGIlONhi+79Sq7HKA2Gv3znmATsd5gaQcKhl3dkIp47LrTdhVHE1UzPfJEvjJog= X-Bogosity: Ham, tests=bogofilter, spamicity=0.013427, 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 4 Feb 2025, at 18:58, Christoph Lameter (Ampere) = wrote: > ARM64 supports MTE which is hardware support for tagging 16 byte = granules > and verification of tags in pointers all in hardware and on some = platforms > with *no* performance penalty since the tag is stored in the ECC areas = of > DRAM and verified at the same time as the ECC. >=20 > Could we get support for that? This would allow us to enable tag = checking > in production systems without performance penalty and no memory = overhead. It=E2=80=99s not =E2=80=9Cno performance penalty=E2=80=9D, there is a = cost to tracking the MTE tags for checking. In asynchronous (or asymmetric) mode that=E2=80=99s = not too bad, but in synchronous mode there is a significant overhead even with ECC. Normally on a store, once you=E2=80=99ve translated it and have the = data, you can buffer it up and defer the actual write until some time later. If you hit in the L1 cache then that will probably be quite soon, but if you miss then you have to wait for the data to come back from lower levels of the hierarchy, potentially all the way out to DRAM. Or if you have a write-around cache then you just send it out to the next level when it=E2=80=99s ready. But now, if you have synchronous MTE, you = cannot retire your store instruction until you know what the tag for the location you=E2=80=99re storing to is; effectively you have to wait = until you can do the full cache lookup, and potentially miss, until it can retire. This puts pressure on the various microarchitectural structures that track instructions as they get executed, as instructions are now in flight for longer. Yes, it may well be that it is quicker for the memory controller to get the tags from ECC bits than via some other means, but you=E2=80=99re already paying many many cycles at that point, = with the relevant store being stuck unable to retire (and thus every instruction after it in the instruction stream) that whole time, and no write allocate or write around schemes can help you, because you fundamentally have to wait for the tags to be read before you know if the instruction is going to trap. Now, you can choose to not use synchronous mode due to that overhead, but that=E2=80=99s nuance that isn=E2=80=99t considered by your reply = here and has some consequences. Jess