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 50695C433F5 for ; Fri, 13 May 2022 22:48:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60FD26B0073; Fri, 13 May 2022 18:48:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BE0A6B0075; Fri, 13 May 2022 18:48:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 45E2E6B0078; Fri, 13 May 2022 18:48:28 -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 3415D6B0073 for ; Fri, 13 May 2022 18:48:28 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F2C3A32B5C for ; Fri, 13 May 2022 22:48:27 +0000 (UTC) X-FDA: 79462210254.03.E7A8DD2 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf03.hostedemail.com (Postfix) with ESMTP id 639F3200AE for ; Fri, 13 May 2022 22:48:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652482105; x=1684018105; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=1cfR5hfccC3vnCWnbdp0zOpiSAhh/23Oja5qGIjqHtc=; b=lu+VYn8tAEDBzowvl9RgYwdn8NYxPGt2W0AbIertMwZqctHQgIXUzirH G0gp62BwCzKhya+Zde7epcBYqj6WAfKVcDnE+aPN9GXMYE8/Hr26NaCRk jkgbZ4xpaFAWd55y45F+gV3bOVwvuqFhFGDTqy8PUPbsci94h0AWrzPGY QTwcHS67IuqHCEiKFWaDJjNv7BDq9J+DgYHFIpyBrDvU95cMI9RLvvHqe HdNj+CxtBfr97oN29K3qjAGaEbQOD9S1lV0kh2+ywkQD0Ujgm9uvssXxO dovpnuksKyeOKriL0bLfTU+t45D0OtTkV5HGuKWVecYoEtQoPhqxjvv7g g==; X-IronPort-AV: E=McAfee;i="6400,9594,10346"; a="250336528" X-IronPort-AV: E=Sophos;i="5.91,223,1647327600"; d="scan'208";a="250336528" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2022 15:48:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,223,1647327600"; d="scan'208";a="567396586" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga007.jf.intel.com with ESMTP; 13 May 2022 15:48:17 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id C6F2AA8; Sat, 14 May 2022 01:48:16 +0300 (EEST) Date: Sat, 14 May 2022 01:48:16 +0300 From: "Kirill A. Shutemov" To: Dave Hansen Cc: Thomas Gleixner , "H.J. Lu" , Peter Zijlstra , Dave Hansen , Andy Lutomirski , the arch/x86 maintainers , Alexander Potapenko , Dmitry Vyukov , Andi Kleen , Rick Edgecombe , Linux-MM , Catalin Marinas , LKML Subject: Re: [RFCv2 00/10] Linear Address Masking enabling Message-ID: <20220513224816.g3uhtiq5xqgql2fs@black.fi.intel.com> References: <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> <67aef839-0757-37b1-a42d-154c0116cbf5@intel.com> <878rr6te6b.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 639F3200AE X-Stat-Signature: pzdj3nn4hkgbjce7n8yfs8wa7gta18y7 Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=lu+VYn8t; spf=none (imf03.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.136) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com X-HE-Tag: 1652482096-301625 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 08:05:26PM -0700, Dave Hansen wrote: > On 5/12/22 18:27, Thomas Gleixner wrote: > > On Thu, May 12 2022 at 17:46, Dave Hansen wrote: > >> On 5/12/22 17:08, H.J. Lu wrote: > >> If I had to take a shot at this today, I think I'd opt for: > >> > >> mask = sys_enable_masking(bits=6, flags=FUZZY_NR_BITS); > >> > >> although I'm not super confident about the "fuzzy" flag. I also don't > >> think I'd totally hate the "blind" interface where the kernel just gets > >> to pick unilaterally and takes zero input from userspace. > > That's the only sane choice and you can make it simple for userspace: > > > > ret = prctl(GET_XXX_MASK, &mask); > > > > and then let it decide based on @ret and @mask whether to use it or not. > > > > But of course nobody thought about this as a generic feature and so we > > have the ARM64 TBI muck as a precedence. > > Well, not quite *nobody*: > > https://lore.kernel.org/linux-arm-kernel/7a34470c-73f0-26ac-e63d-161191d4b1e4@intel.com/ In the first RFC I tried to get ARM TBI interface generic. I resurrect it if it fits better: https://lore.kernel.org/all/20210205151631.43511-2-kirill.shutemov@linux.intel.com/ -- Kirill A. Shutemov