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 E8286C433F5 for ; Thu, 12 May 2022 21:24:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DB946B0073; Thu, 12 May 2022 17:24:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 462276B0075; Thu, 12 May 2022 17:24:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DD5E6B0078; Thu, 12 May 2022 17:24:31 -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 18A366B0073 for ; Thu, 12 May 2022 17:24:31 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D92D421173 for ; Thu, 12 May 2022 21:24:30 +0000 (UTC) X-FDA: 79458369900.26.A924EEF Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf20.hostedemail.com (Postfix) with ESMTP id 454661C0003 for ; Thu, 12 May 2022 21:24:20 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1652390667; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=O0oZd+Y8woJ6fFGZxNFZTKswF93ZoW1CaLUWFySAj0A=; b=nAdjWvTjYBrTDrCyGJfRXhhyjrSHLW4CZ3GF6Yf71+/cg6pHseaIqb2GEGB3ZTITjBCV3u u+nwms1rNvpSQF7UZibEepc2avbvdv7x4sOPQiFC90ll+IiVTbkjr5oIZ6fd+YcyKpJloq aq2qtwU+mWMU8dxGt3OBGwzQrR50UoV8DmBKcTRbu6jwXRwrfdsAD9dJGnqlEimpTaK4vS Z9fNxHovZSvpr7qUs4/KZFSsGdavGsKTd21O54MLx9/0MrdSVqQB5sTxiL1lirVtW/U/ae OtFuPPBdRI/JJAfFoi6Umj7JSK2wiKLktQJpLw0ir8nsNZbCBiuQhzOi9V8hvw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1652390667; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=O0oZd+Y8woJ6fFGZxNFZTKswF93ZoW1CaLUWFySAj0A=; b=mc+PbD5GUeDJd5gRo1q9/E9BiRbr+vlIeXqnLZGcFbpz8umfAIgSRpndoFcOjBunDCmkPE PBx7GjFwxgTG2OAg== To: Dave Hansen , Peter Zijlstra , "Kirill A. Shutemov" Cc: Dave Hansen , Andy Lutomirski , x86@kernel.org, Alexander Potapenko , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFCv2 00/10] Linear Address Masking enabling In-Reply-To: <875ymav8ul.ffs@tglx> 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> Date: Thu, 12 May 2022 23:24:27 +0200 Message-ID: <87zgjmtpf8.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 454661C0003 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=nAdjWvTj; dkim=pass header.d=linutronix.de header.s=2020e header.b=mc+PbD5G; spf=pass (imf20.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-Rspam-User: X-Stat-Signature: frt5iue4464r541mchqxy961o686p1zk X-HE-Tag: 1652390660-489411 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 21:39, Thomas Gleixner wrote: > On Thu, May 12 2022 at 10:22, Dave Hansen wrote: >> 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? This would need cooperation from the application because it has to tell the magic facility whether it intends to utilize the large VA space on a 5-level paging system or not. I have no idea how that is supposed to work, but what do I know about magic. >> It's totally fine with me if the kernel only initially supports LAM_U57. >> But, I'd ideally like to make sure that the ABI can support LAM_U57, >> LAM_U48, AMD's UAI (in whatever form it settles), or other masks. > > Sure. No argument here. Assumed that the acronym of the day, which uses this, has a real benefit from the larger number of bits, we can support it. But we are not going to make this a per thread selectable thing. It's a process wide decision at startup simply because it does no buy thread A anything to select U57 if thread B selects U48 before thread A was able to map something into the U48 covered address space. Same issue the other way round as then B has to fallback to U57 or NONE. That does not make any sense at all. I'm all for flexible, but not just because we can. It has to make sense. Making it process wide and once on startup puts the 'complexity' into the prctl(), but keeps the runtime overhead as small as it gets: - CR3 switching needs just the | mm->lam_cr3_mask - untagging one of the uglies Peter and I came up with Making U48/U57 hardcoded would not buy much. Thanks, tglx