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 2C771C6FA83 for ; Tue, 13 Sep 2022 00:06:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 975D66B0072; Mon, 12 Sep 2022 20:06:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9245B6B0073; Mon, 12 Sep 2022 20:06:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8126E8D0001; Mon, 12 Sep 2022 20:06:41 -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 72FC56B0072 for ; Mon, 12 Sep 2022 20:06:41 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 52B46A11D9 for ; Tue, 13 Sep 2022 00:06:41 +0000 (UTC) X-FDA: 79905121002.12.2A531F1 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf12.hostedemail.com (Postfix) with ESMTP id 570B8400B1 for ; Tue, 13 Sep 2022 00:06:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663027600; x=1694563600; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Uvw6V9KjV6Vb8eX5TMVrCqR2Yi0yPi5W4S9MFXY9hpk=; b=JDVOuTZmsX4hFK+9sPg0fJ5wNyJmTNbX2IsH5BgbRBoIrX0VLhw6XKNl XDF2sPVtfNm6rSLfV++vkJSwfEkSfWnifYLLz/KPKIe7E0nv4G355qHWE uENZWH17QN9K73G/Hd5hOj8DFrX2MPAv+en7vI0Rgy0bKEyi1dOI1uAec yUKz6qbKVzWQniDWIViyhDmXr9CfOfrA8O+KCUWZj0D/fz9Tj3GokCjCV 0Xn+INiXoNatRtk6DLC3Mt1PBnFLnj2xoBlUJcSqSO3eABLq6EUI8PQ6I O6cC8AWB9EVhaQ2ONyiFZCGYBzu2Qav5PbZxOWpTva8W73uRombj6hjHn A==; X-IronPort-AV: E=McAfee;i="6500,9779,10468"; a="299338075" X-IronPort-AV: E=Sophos;i="5.93,311,1654585200"; d="scan'208";a="299338075" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Sep 2022 17:06:38 -0700 X-IronPort-AV: E=Sophos;i="5.93,311,1654585200"; d="scan'208";a="944838249" Received: from aburgsta-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.251.208.142]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Sep 2022 17:06:34 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 3177910455B; Tue, 13 Sep 2022 03:06:32 +0300 (+03) Date: Tue, 13 Sep 2022 03:06:32 +0300 From: "Kirill A. Shutemov" To: Jacob Pan Cc: Dave Hansen , Ashok Raj , "Kirill A. Shutemov" , 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, Ashok Raj Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling Message-ID: <20220913000632.2o4alsekgskof2x2@box.shutemov.name> References: <20220830010104.1282-1-kirill.shutemov@linux.intel.com> <20220904003952.fheisiloilxh3mpo@box.shutemov.name> <20220912133935.3bb3e247@jacob-builder> <356d4ad1-f7d8-b8ff-3b63-819a64bf5b9f@intel.com> <20220912155502.0087a993@jacob-builder> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220912155502.0087a993@jacob-builder> ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=JDVOuTZm; spf=none (imf12.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663027601; a=rsa-sha256; cv=none; b=mebSGFRBxTLyBIbNqmxarjndaftqfCG3LDOtPZOvVQc6zQrGLV2qAPHdyk8hKMQB1s8W5c FhYP39C7qWsMZZkpXjcw3XTBcfYocrRuxsSLB41PVQBKh0qp7r5uVa8cOipDdAx9iq1rqR xtGi1YwTGaL0CBBti3kpQ/3tOPj8NaQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663027601; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=07MLbX9pl9PmW9+LzHvAS62+pEJ1g7Y7LfoVnHwGhng=; b=ULCT8xE5YTi7rQYrFNb9nxeOaWHdwjS+nOdKQWs5nIi6h6pohgrlzY/HU/MdE/2D9td/kM QopWRxsySxrwxSZHase3a4o02bMCooQj5e8uooDk9K0JIr8uXxRbc8mlfVw6WtGKRzjxzU 4aBGFJejt2i1gAiCm+VVnlsfkGRoIn4= Authentication-Results: imf12.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=JDVOuTZm; spf=none (imf12.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Rspamd-Server: rspam12 X-Stat-Signature: usb5kij4tabcguyeju6aafrzy7scjhd9 X-Rspamd-Queue-Id: 570B8400B1 X-Rspam-User: X-HE-Tag: 1663027600-839807 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 Mon, Sep 12, 2022 at 03:55:02PM -0700, Jacob Pan wrote: > Hi Dave, > > On Mon, 12 Sep 2022 14:41:56 -0700, Dave Hansen > wrote: > > > On 9/12/22 13:39, Jacob Pan wrote: > > >>> + if (pasid_valid(mm->pasid) && !forced) { > > > I don't think this works since we have lazy pasid free. for example, > > > after all the devices did sva_unbind, mm->pasid we'll remain valid > > > until mmdrop(). LAM should be supported in this case. > > > > Nah, it works fine. > > It just means that the rules are "you can't do LAM if your process > > *EVER* got a PASID" instead of "you can't do LAM if you are actively > > using your PASID". > Sure it works if you change the rules, but this case need to documented. > > > > > We knew that PASID use would be a one-way trip for a process when we > > moved to the simplified implementation. This is just more fallout from > > that. It's fine. > > > Is LAM also a one-way trip? Yes. -- Kiryl Shutsemau / Kirill A. Shutemov