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 21C68C433F5 for ; Fri, 13 May 2022 23:01:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 823386B0073; Fri, 13 May 2022 19:01:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D18D6B0075; Fri, 13 May 2022 19:01:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69E4F6B0078; Fri, 13 May 2022 19:01:29 -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 5C0E56B0073 for ; Fri, 13 May 2022 19:01:29 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 363A13296A for ; Fri, 13 May 2022 23:01:29 +0000 (UTC) X-FDA: 79462243098.29.A124E9A Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf09.hostedemail.com (Postfix) with ESMTP id BA7B51400A0 for ; Fri, 13 May 2022 23:01:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652482888; x=1684018888; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=MTfC/9EMbaMrK28PPc/w3328k2eO4ywXQYc/ZS6xQT4=; b=nuVVgWWpOj6T7dnV+vUDsqsaUr14pvYhkRKx3tEHxvTo474UM3uHFOGh XuZpnx11NYEGIIyWnpadhNCbrcZuOpCoPH4dK6gfnsN8gMo+OUzY4e4cw B3gGWr8MUtGxYxZl1qrR53z470sFCgTiiiv4xEtntTG5rRISEZa5qbUJI gNpZgTms43w+CklDkbYfzHIvv/Ssmxr49vGnQtAckltDD00hfF8LxpKAM PatfCpxYXomLe3wuf487+8aZW5KFdyLfBNCpXcZerhGzgpaI5uaCZ+7+y kLxBNQp3CwcQeoC1sab3A0pMGQIs8rNVUVVsoeidzd1aogXjvlCvxKFRt A==; X-IronPort-AV: E=McAfee;i="6400,9594,10346"; a="269269468" X-IronPort-AV: E=Sophos;i="5.91,223,1647327600"; d="scan'208";a="269269468" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2022 16:01:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,223,1647327600"; d="scan'208";a="659311031" Received: from black.fi.intel.com ([10.237.72.28]) by FMSMGA003.fm.intel.com with ESMTP; 13 May 2022 16:01:24 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id E0917A8; Sat, 14 May 2022 02:01:23 +0300 (EEST) Date: Sat, 14 May 2022 02:01:23 +0300 From: "Kirill A. Shutemov" To: Alexander Potapenko Cc: Dave Hansen , Thomas Gleixner , Peter Zijlstra , Dave Hansen , Andy Lutomirski , the arch/x86 maintainers , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , Linux Memory Management List , LKML Subject: Re: [RFCv2 00/10] Linear Address Masking enabling Message-ID: <20220513230123.wmb4ia3r72snfpwj@black.fi.intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=nuVVgWWp; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf09.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=kirill.shutemov@linux.intel.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: BA7B51400A0 X-Rspam-User: X-Stat-Signature: ysdxxso6a9tdq3epdt6pmmoouymsh8nn X-HE-Tag: 1652482879-275677 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 Fri, May 13, 2022 at 01:07:43PM +0200, Alexander Potapenko wrote: > On Thu, May 12, 2022 at 11: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? > > (speaking more or less on behalf of the userspace folks here) > I think it is safe to assume that in the upcoming year or two HWASan > will be fine having just 6 bits for the tags on x86 machines. > We are interested in running it on kernels with and without > CONFIG_X86_5LEVEL=y, so U48 is not an option in some cases anyway. Just to be clear: LAM_U48 works on machine with 5-level paging enabled as long as the process doesn't map anything above 47-bit. -- Kirill A. Shutemov