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 244A2C433F5 for ; Thu, 12 May 2022 22:10:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4A6046B0073; Thu, 12 May 2022 18:10:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 455616B0075; Thu, 12 May 2022 18:10:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 31CCF6B0078; Thu, 12 May 2022 18:10:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 229B36B0073 for ; Thu, 12 May 2022 18:10:55 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E5B944FE for ; Thu, 12 May 2022 22:10:54 +0000 (UTC) X-FDA: 79458486828.25.B782D83 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by imf25.hostedemail.com (Postfix) with ESMTP id 5130EA009B for ; Thu, 12 May 2022 22:10:35 +0000 (UTC) Received: by mail-pl1-f177.google.com with SMTP id q4so6192478plr.11 for ; Thu, 12 May 2022 15:10:54 -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=5pINHEZv62I1VVi/6cPBplzqwfW+cUrao+xeCNK719k=; b=LCRFLml7xEJRxFGUFkWpJE/kchV+HpiS1oOHDIpBNpG5BsbTuduUCS8YfO5TzpHlYQ 3ptdU3A+twkT86qLqhKa4sj2dWAb2DwxO+ygJyGzul9PWb4o8o2QQEnlkn/eNhcZT1fi D8TFh38oRb8dLnSChfMarF325DLkkTM0oA6oD3ZBj4AqOS3XYntUhjg5ydhZ89fDcgOS RMTHM/olvT8e/DciINTCtF9OUhBxwilTni6qAOqfCVgq1wMW9xcGmryBpd5q68GaHUp1 /BvgYZqfC+ExF2aNI0CBO0X26nEDS6wpORgNp1jK02QYVUyU+jHwF30vNsUnd57Euqvt HTjA== 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=5pINHEZv62I1VVi/6cPBplzqwfW+cUrao+xeCNK719k=; b=bS/YBlCsNKrYcGoU1nho41ca/Is8U69+xI71kVfjYBVL8sn31XiIy0R9xYU+a70+YU /dXTF2WeyGm/yU+WWyamI8HNKLzTIwn3adOvkHlyAa5oGgw+5mDMfRS94suP2qhNZlzA QYbLg73KJe/5aU4VFBPyhg7c+MZ4YMoM0TGI/ipqjKGvyNo02ZG6t4mxiHXtFPHKcv2d 8vkEkYuhUD0Xh+2pdeu+WM6/dRRujn3JfuHnsT0WvMQP/3o0Bvjy/GhWJmCcqXtsakUM KzbqAMvG2Lxm6iNkajXqKDJRjz9BfMAv8CjdfkZ2c2GwSAK+o3FC4WGVk3YYvTCmJc/3 w9wg== X-Gm-Message-State: AOAM530it/VsshjRECbv6E0S5ge6IMPZftBeFxl3iWHjrerzPKi0CmMv TDHEFVGv0Kld7PJUX5633ha2rmYp/DJpV2nMVYI= X-Google-Smtp-Source: ABdhPJyf6+hXy2q/+T6v2bshm8tdUo6EkuVGShdkL0vzhulsFZI82vRLQGS4bF3INIXlm0R9mB7rjkbvdcUvyPmT7Bw= X-Received: by 2002:a17:903:1108:b0:156:73a7:7c1 with SMTP id n8-20020a170903110800b0015673a707c1mr1653537plh.101.1652393453361; Thu, 12 May 2022 15:10:53 -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> In-Reply-To: <55176b79-90af-4a47-dc06-9f5f2f2c123d@intel.com> From: "H.J. Lu" Date: Thu, 12 May 2022 15:10:17 -0700 Message-ID: Subject: Re: [RFCv2 00/10] Linear Address Masking enabling To: Dave Hansen Cc: Thomas Gleixner , 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-Stat-Signature: 88bs3b7dy1pwcxg7zhjxyom4z7re88wk Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=LCRFLml7; spf=pass (imf25.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 5130EA009B X-HE-Tag: 1652393435-513371 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 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. An application can ask for LAM_U48 or LAM_U57. But the decision should be made by application. When an application asks for LAM_U57, I expect it will store tags in upper 6 bits, even if the kernel enables LAM_U48. -- H.J.