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 9C008C02193 for ; Tue, 4 Feb 2025 23:50:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B5D056B009E; Tue, 4 Feb 2025 18:50:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B099D6B009F; Tue, 4 Feb 2025 18:50:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 984376B00A0; Tue, 4 Feb 2025 18:50:16 -0500 (EST) 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 72D716B009E for ; Tue, 4 Feb 2025 18:50:16 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 226D9B0596 for ; Tue, 4 Feb 2025 23:50:16 +0000 (UTC) X-FDA: 83083908432.04.1413A1C Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf13.hostedemail.com (Postfix) with ESMTP id 267EA20004 for ; Tue, 4 Feb 2025 23:50:13 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=jrtc27.com header.s=gmail.jrtc27.user header.b=G595ahqq; spf=pass (imf13.hostedemail.com: domain of jrtc27@jrtc27.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=jrtc27@jrtc27.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738713014; 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=PAwwkQdvPZEYfqSCljbBHvE3Q2wGsLsoHyROCL0y8wIJkB+XcuzHYnEUPh1RLuxHAWg/Hi P1/8Ji4M5he+S3GDp5qPerfEahR4d6yxdCZSvqWKsJJLn5tRGe8RvAi3iGu1uEyukAup0Z +Lcg4jmTB0usid0lHaURKD116cKRMxA= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=jrtc27.com header.s=gmail.jrtc27.user header.b=G595ahqq; spf=pass (imf13.hostedemail.com: domain of jrtc27@jrtc27.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=jrtc27@jrtc27.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738713014; a=rsa-sha256; cv=none; b=q6OZ+kfPJtnT9A+j6JsSXv6TSrDQnmdD1Xy2ITKxAyzSWXMGOLxh/2iwyUiVGyanzTWkV5 Wk1uGpP8lDHktCxer91KFqU4JEGaYbAuXqqoMxo4AmkAqxw1Ej1GlEePTBXGcaMGYstl2u 4Etjj6M7bGkK11UpsY2atVKKo5/Remw= Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-38634c35129so4856140f8f.3 for ; Tue, 04 Feb 2025 15:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jrtc27.com; s=gmail.jrtc27.user; t=1738713013; x=1739317813; 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=G595ahqqzyUhXP0obWz8stTxLGmQL7l0EFC/EtdPcqiMATerdESt2rsF2EO5M0HwxJ Tr6v3oYO1/4OSYJ2SkBM0TmJMUXIOZfWHf5iR27BFasDpwbMnrYRh11LnNgSD+UAV+Ns KZbeMjOpgW+wZGD2uQLxpsuXGuHWPJ+Mnkutb5HqClKvhUDJSjEFlMAodM7ccTXql2yA mHlp0XKllc0lgcCoNoTJkIgDHONvLj/WQ22OOM2bGWaMCiqoPybfz5LHtwSutqgTlDul xjUz8DxdUSxf5xmS4KpHUOK5aVAr8wsB+SahQ6wams7IpcAuEAf5lAm52FkYW1UaUxHe J4lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738713013; x=1739317813; 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=E8cnMkThTA5gr1AWcqBeieM15B3xYd17TV7rUgOaKQXNNAmYjvCS0sl1kEyEBgzy3c vsrF7A1V9t/KOpfpXD7+G/9PgGtGdx8gBz7qXe5lwgJ0Ov5WI8TyLKNGMFIjclNZs24P h7B88x4BIFXvubFnpSTFBAD9HyYoNjMZijq2B3hsKG2jOFUO64eHCdO+4FtYu77hSFrM o8wvD8SQrYsVZ/v3/uVn5vI0IVQ8z4nUK4PyJpXTaJLqlDroGS+cu3np5N1ZMlMJDJki KQVuFpjDb3GDcNY2A68XvftCvlTcxa6u/oi8rOr+NvNEXOICZZMopNbmvrkiEG7mqcJG WfXw== X-Forwarded-Encrypted: i=1; AJvYcCWI8W359CogXddtwGJzUZ2jYnxcmTCiSirEDWPcT8dJd54N2l22i+bH1qtzOu24ndEUiuKiP8sa4Q==@kvack.org X-Gm-Message-State: AOJu0YwUdQ17PnA8hdOqT0OUIZK39GEGJYCdKaLbT7Z7F5ODJ+NuLYhA B8E0Z18RA8SlmF/cSlRddocvMO7Xa/ldVZJSGI4ZwrxqER4dL1+pl897NdkmoiE= X-Gm-Gg: ASbGnctiSPhX40guRkBezu4dyiojSZ37DRDpUVXWtqNNRBnaKIiE7FwRExAHLk6hh8O EUtVX5yXSYqyF1MO2Erx+TnFmfxo+ahejQ4RR23g4UqmQ6k1CBFA7sdOi3lV1mXrPccYcJvs83p xFxyhzPifjvZI8xxRFeDug9ZLRk5qrxv5ZqtILlM9W5RRsWiXfsKgOR+yar1XgKj8lbmrJQNmYs JiXQmMCkBa9zPHcieQRiJIPAGpUsxK4SYaG70DRrJNl/cfrxZvRvsmr4RkJcPRNMV7QgtR14WZK GQadpluIdvBbHwWXs6ZUOL2lNFhE X-Google-Smtp-Source: AGHT+IEypTIpZh6mfBdWNl0Yo6S1z/L0NXKr61jortReoHSuVGBqrXhoBHP93m2FnFAjaJ4GCP4WRQ== X-Received: by 2002:a5d:5f56:0:b0:385:df43:2179 with SMTP id ffacd0b85a97d-38db48bccf9mr352139f8f.17.1738713011907; Tue, 04 Feb 2025 15:50:11 -0800 (PST) Received: from smtpclient.apple ([131.111.5.201]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38c5c1cee41sm16885326f8f.81.2025.02.04.15.50.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Feb 2025 15:50:10 -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: References: <8bd9c793-aac6-a330-ea8f-3bde0230a20b@gentwo.org> To: "Christoph Lameter (Ampere)" X-Mailer: Apple Mail (2.3826.300.87.4.3) X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 267EA20004 X-Stat-Signature: d7xqba4axcmm8j83i7rqfne9qxis9jsq X-Rspam-User: X-HE-Tag: 1738713013-766030 X-HE-Meta: U2FsdGVkX1+GadH+JEU0k178NhhFvL8l1EpHj5Uh8U1cKthl4fNm2sUbecmxrGLywfNLsdHDTt9YeJPGt02KbeZ/jk7ak1YLqgIA96R75PhsWlw/fj3LaS7fDjqYSjWXnxSGhULEgr9MULQWH5LIswTwuouMJ/81N78ZZDZLXlNbI0grBS98K2KA5VwZ0RHhGnmwp7KHd5wnM6op4/9vI2p3RQFrBC1O5wn5YbuZ7E0+eksHx8IhgxjgvYt9vKasoKNj8zE+iblUXUuz5zzWDatqbqK2vru/jm13b0pxvKL+Yyvi6UB1vN/PP/UpLdrk6UqabxqIFVTJkJSgkC1dvhsx/8ev2DOQkdPTO4fa4wEmsy/dyu8RSL44HSr1+Q1YiCkMij3N6BTgL5o9YM0WGTVUiHYQuyeUyTinIDpZKE1qjxSjdd3F+UfDJdDYJ49QeE8ovcL8Mq41hWoZ2qzG1vjTqMbRgY1Ftxo4HpkxMQD+FLWrKt6xwSZ3TfSK5IdVSTluoNb6juHFO+CwElSM2JYGeEnPN26QudzYhtJEy6X+8qws3tLB3IBb3DANGRrLBnrOApayLn50WVHm/JYOZ8vV6U2AXwQCQNXA0gDGpcV70Sp/pp62qjoBhFfL4TgT2Znx7vAcjjUkl+ZBkwSu+z1xyCbcPwQrsteU1nP3e/9D0t190QZGEmdqAHSdRSxt2n1khp1VhSnwkIN9+e8ct7cu2/X3mkvJo34mIMKuEsJrsLMTrBIzUYPykf0Ct8uxsf7MqIjM5575WtBsa3f27wz474fnlujY2yvXKz7rfv4fwcPFR2ZU8zOdh1vegyazGHEn65P1tadlE1t3xLopqDDbiZBlqFWdTXyLY9/oOLPnagGKOK3dza97VlROo8Mc6+l7cyjwKe2kQcpt+R1gs10doGUhHfwkIosck/UzdDBSY+dipOeG7dwLp+obYzpc4eKl1jPJawON+Az9LhV mO5OktDd RJLDYYtzPFWfL3M1ijl6/9SbqH3X50djkuc2FuertevNJ3m+F5Z9HbMv3wOhkYZrd80Qakxt2ijsgURNrsCuTwXaWWsA5yw3y0mCBi5rAkNzoxtJkcoP+oJ1mz1nVUAcvqyIq8BEMGAC3Zxlr/eNFjJhUwO5fRIFS5lV4Ouv6Nc40MTytXbKgsi5KK3qOIOu0QiQ3YJ0I+3DzToqVoN7AaIyi7oH00/huIg2rBhXyVwlfryx9cCrc6B+fnDXNLKRHtMbuiUTfgm4V8VU9qfYJdaJNShsyBhvh/t+LwnwUjBGsz0ZIL8OmJq1W7SLUL5lnifZlijmxLXWBLZp9OXwkOuvig7U4qV16mP5aBSv4aUCDGIP/4mCFZZneLeJzb1iwyFn0MEh/rgB1uNwhYiwerDWgWhYRHh3nyUOb/gYXqB9d9UQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000047, 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