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 A90F7C6FA82 for ; Wed, 21 Sep 2022 16:57:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C40B26B0071; Wed, 21 Sep 2022 12:57:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF0946B0072; Wed, 21 Sep 2022 12:57:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A91D0940007; Wed, 21 Sep 2022 12:57:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9A08E6B0071 for ; Wed, 21 Sep 2022 12:57:53 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5E8AE121209 for ; Wed, 21 Sep 2022 16:57:53 +0000 (UTC) X-FDA: 79936699626.12.D6656B5 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf08.hostedemail.com (Postfix) with ESMTP id C7F06160013 for ; Wed, 21 Sep 2022 16:57:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663779471; x=1695315471; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=KfeL1caenfC1WwBXXSUs1g5r/dvpabVdylm3CpznaYo=; b=IEUw5nnv0Lovu41xLWicKZGeodXV4zmmokViQk0XPE+IZv9Br0lhzYHk smwVct5GKExiE9MSdwFYz+ZZF5sIpkkl8j3R4YL6lhf+QShgdtX3g3J7X NpZnmJNJI8nlvjeBHN95YPU1xYXKSJehI6LVTqBQojY6HmGNPat4JSwfc dzTCipwpCJ96FB31twrJJYENUhvNSxD81IJbIp6uBOVfvfoj4C9/fFEsi fgRuYxepsVtMZf/9yiynpPkqC3Ixd2ur1oyEBUPllbfe+pYVQ/+/ff4iO 4wgqI6fyFYtAjEadWcgwzmZJGmuZ0Tk6HzZ6I1d7XZStJfYvzAMU2V47s g==; X-IronPort-AV: E=McAfee;i="6500,9779,10477"; a="300903349" X-IronPort-AV: E=Sophos;i="5.93,333,1654585200"; d="scan'208";a="300903349" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2022 09:57:50 -0700 X-IronPort-AV: E=Sophos;i="5.93,333,1654585200"; d="scan'208";a="723291831" Received: from nchaplot-mobl1.amr.corp.intel.com (HELO [10.209.89.231]) ([10.209.89.231]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2022 09:57:48 -0700 Message-ID: <562dec4d-a39f-b517-58a3-45f691a2d10a@intel.com> Date: Wed, 21 Sep 2022 09:57:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling Content-Language: en-US To: "Kirill A. Shutemov" , Jacob Pan Cc: Ashok Raj , "Kirill A. Shutemov" , Ashok Raj , Dave Hansen , Andy Lutomirski , Peter Zijlstra , x86@kernel.org, Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Alexander Potapenko , Taras Madan , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jason Gunthorpe , Joerg Roedel References: <20220904003952.fheisiloilxh3mpo@box.shutemov.name> <20220912224930.ukakmmwumchyacqc@box.shutemov.name> <20220914144518.46rhhyh7zmxieozs@box.shutemov.name> <20220914151818.uupzpyd333qnnmlt@box.shutemov.name> <20220914154532.mmxfsr7eadgnxt3s@box.shutemov.name> <20220914165116.24f82d74@jacob-builder> <20220915090135.fpeokbokkdljv7rw@box.shutemov.name> <20220915172858.pl62a5w3m5binxrk@box.shutemov.name> From: Dave Hansen In-Reply-To: <20220915172858.pl62a5w3m5binxrk@box.shutemov.name> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663779473; a=rsa-sha256; cv=none; b=D31pjiyerMtPaVZkiN+Yjp0PqUQP3zVm+AhLoosrpDKjcRob3nJhfIbz1vDu8LUE9cLiW9 cIw32zkAtU2S/02SE5qpmJZrXaFoCDAbsWVJMnKxK4Vjsc+uaL3zmHo7zMiP7wqpR82D6O FnFTmPJaR9zT6WLSUlHEy/OUMiJq5zY= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=IEUw5nnv; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf08.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.24 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663779473; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=J21iBuTA+2/91xI2WPlfOAbxyXnnD/10Lq7+gBAEcZM=; b=gEYyx5+Eit9Bi6qTx1StiD98MKxQCJh5EVGZTFNuTIpQk9Iq7t8Y8imLTCGVJQp4qD5Uae Edrs4Jjd/nsq2p12P6A1o4YdNi9YH93TVelpF9A9PiqpJnoyHPKNC4+ZmxUta/Ys6QI5j8 4OCRmBdAagbghXuOfasUAA/EBy07cFc= X-Rspam-User: X-Stat-Signature: k7638c635bprse6w9u5n8th9scwu8xmc X-Rspamd-Queue-Id: C7F06160013 Authentication-Results: imf08.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=IEUw5nnv; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf08.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.24 as permitted sender) smtp.mailfrom=dave.hansen@intel.com X-Rspamd-Server: rspam07 X-HE-Tag: 1663779471-369641 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 9/15/22 10:28, Kirill A. Shutemov wrote:> + /* Serialize against address tagging enabling * > + if (mmap_write_lock_killable(mm)) > + return -EINTR; > + > + if (!arch_can_alloc_pasid(mm)) { > + mmap_write_unlock(mm); > + return -EBUSY; > + } Shouldn't this actually be some kind of *device* check? The question here is whether the gunk in the mm's address space is compatible with the device. * Can the device walk the page tables in use under the mm? * Does the device interpret addresses the same way as the CPUs using the mm? The page table format is, right now, wholly determined at boot at the latest. But, it probably wouldn't hurt to pretend like it _might_ change at runtime. The address interpretation part is, of course, what LAM changes. It's also arguable that it includes features like protection keys. I can totally see a case where folks might want to be careful and disallow device access to an mm where pkeys are in use.