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 874ABC433F5 for ; Fri, 13 May 2022 00:09:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E7B356B0073; Thu, 12 May 2022 20:09:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E28FD6B0075; Thu, 12 May 2022 20:09:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF3196B0078; Thu, 12 May 2022 20:09:13 -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 BDCD46B0073 for ; Thu, 12 May 2022 20:09:13 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9277E318D4 for ; Fri, 13 May 2022 00:09:13 +0000 (UTC) X-FDA: 79458784986.27.E2AA734 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf25.hostedemail.com (Postfix) with ESMTP id A8EB1A009B for ; Fri, 13 May 2022 00:08:53 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id l7-20020a17090aaa8700b001dd1a5b9965so6292190pjq.2 for ; Thu, 12 May 2022 17:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+te11kMiQn1wAaGnvrzw5FU1YDy3n162ybzqTsqCXWw=; b=O02+VUPfxLERX+aEvxOOMv58BTXCIigcUQ2GGXQIYGGfH84rhIFoxvB+3DjdKXdNe3 mla74cDOBOyK50JZVrzFkQSXaBfrmmgwNRX1P3AiIkgOHVGe/zGNlI2Cg4F6mJIhpFot fM7vYEUE06CYFzNMu7Vbpwn4X71ZrwbvkgFv6aJlPxEmjeZYYug6VX8ZWyOFJl3FG+oI qHd8i1wIyWvK5hQQniAKpC9g9jFqu/sa1ZxaVtgGUzuUtbsoOVr8wykJUmzZiLL46ud8 sMSvNdeIQEW2nT5LSsWLWrf744oOVEa5yJ1NOxLDiCPPxtT5qlt8PofyyPJ/XbjZdi4W Dwxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+te11kMiQn1wAaGnvrzw5FU1YDy3n162ybzqTsqCXWw=; b=P9mBR+3h9+y1vhwAVgMcJ6UmlNVkonXSqWRs00LZXBbp+mLyghVg6eGb1PzSB5MDjp 4evup8nGOohHhYV9hIkCttpRzDNm72Xv33jASve36CBPJUZdCfYTBUsX/YSJTx7SYk7u iX0IRwz9fMpK428uBHaTYCKkjgDFyuBm2SDmVt5xPw654vcmGXgaNE3xRBdMIBUblG5e ulT2myQ8ogGUR79pM1xKZ64wrcj18nvZvlP2OR8Kh5bJCrcP+vABbUxdBakzuT+EDlR7 4MtXYr5b2kj3MDEPHE88M15FF0KzoBA9iFH7x6QHWjzeV7+2pLeWyHy0CKCCaY0c713l yfrw== X-Gm-Message-State: AOAM5319bnaymFL0adIhvG9wcDeRXuXp49PiNSljyy03RHWOygVj4cpv 7Chvou7BQRnZ0cW9Dht0a1TgwsDquy7EqZqSsOU= X-Google-Smtp-Source: ABdhPJzWX6qW4/YFCHZ4aZhdqqQLcy0MiIAbU4gjlQfNjhLq+u6RvNYAPiLyqpo6gPxzBS6nQz8EgDTm/O0mViV1P+o= X-Received: by 2002:a17:902:bcc6:b0:15f:4990:baec with SMTP id o6-20020a170902bcc600b0015f4990baecmr1897019pls.102.1652400551692; Thu, 12 May 2022 17:09:11 -0700 (PDT) MIME-Version: 1.0 References: <20220511022751.65540-1-kirill.shutemov@linux.intel.com> <20220511064943.GR76023@worktop.programming.kicks-ass.net> <20bada85-9203-57f4-2502-57a6fd11f3ea@intel.com> <875ymav8ul.ffs@tglx> <55176b79-90af-4a47-dc06-9f5f2f2c123d@intel.com> <87o802tjd7.ffs@tglx> In-Reply-To: <87o802tjd7.ffs@tglx> From: "H.J. Lu" Date: Thu, 12 May 2022 17:08:35 -0700 Message-ID: Subject: Re: [RFCv2 00/10] Linear Address Masking enabling To: Thomas Gleixner Cc: Dave Hansen , Peter Zijlstra , "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , "the arch/x86 maintainers" , Alexander Potapenko , Dmitry Vyukov , Andi Kleen , Rick Edgecombe , Linux-MM , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A8EB1A009B X-Stat-Signature: piekakmonsfmcq5d6iror5o44hoze87q X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=O02+VUPf; spf=pass (imf25.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1652400533-364089 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 Thu, May 12, 2022 at 4:35 PM Thomas Gleixner wrote: > > On Thu, May 12 2022 at 15:10, H. J. Lu wrote: > > On Thu, May 12, 2022 at 2:51 PM Dave Hansen wrote: > >> On 5/12/22 12:39, Thomas Gleixner wrote: > >> >> It's OK for a debugging build that runs on one kind of hardware. But, > >> >> if we want LAM-using binaries to be portable, we have to do something > >> >> different. > >> >> > >> >> One of the stated reasons for adding LAM hardware is that folks want to > >> >> use sanitizers outside of debugging environments. To me, that means > >> >> that LAM is something that the same binary might run with or without. > >> > On/off yes, but is there an actual use case where such a mechanism would > >> > at start time dynamically chose the number of bits? > >> > >> I'd love to hear from folks doing the userspace side of this. Will > >> userspace be saying: "Give me all the bits you can!". Or, will it > >> really just be looking for 6 bits only, and it doesn't care whether it > >> gets 6 or 15, it will use only 6? > >> > >> Do the sanitizers have more overhead with more bits? Or *less* overhead > >> because they can store more metadata in the pointers? > >> > >> Will anyone care about the difference about potentially missing 1/64 > >> issues with U57 versus 1/32768 with U48? > > > > The only LAM usage I know so far is LAM_U57 in HWASAN. > > That's at least a halfways useful answer. > > > An application can ask for LAM_U48 or LAM_U57. But the decision should > > be made by application. > > It can ask for whatever, but the decision whether it's granted is made > by the kernel for obvious reasons. > > > When an application asks for LAM_U57, I expect it will store tags in > > upper 6 bits, even if the kernel enables LAM_U48. > > The kernel does not enable LAM_U48 when the application only wants to > have LAM_U57, because that would restrict the address space of the > application to 47 bits on 5-level capable system for no reason. > > So what are you trying to tell me? > I am expecting applications to ask for LAM_U48 or LAM_U57, not just LAM. -- H.J.