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 DD9CAC4345F for ; Mon, 29 Apr 2024 14:56:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 726886B0096; Mon, 29 Apr 2024 10:56:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D50D6B009E; Mon, 29 Apr 2024 10:56:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59C866B009F; Mon, 29 Apr 2024 10:56:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3BC166B009E for ; Mon, 29 Apr 2024 10:56:33 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D15681201D8 for ; Mon, 29 Apr 2024 14:56:32 +0000 (UTC) X-FDA: 82062870624.05.EAC0AC6 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf01.hostedemail.com (Postfix) with ESMTP id 07C9D4000E for ; Mon, 29 Apr 2024 14:56:30 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=Z8qCMwWK; spf=pass (imf01.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.222.179 as permitted sender) smtp.mailfrom=jgg@ziepe.ca; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714402591; 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=WyfECjGT2cPe5HE/2z0fDQqdazh8yGo98dGumX8os9Y=; b=ZyBk2Qth0Nqs9IZkSu/Nh5N2mimUUa2FnayyrCqWQPJoY1VxobVtCAd4rULZ5XwhKqACS5 i84edSDCD0v6fM4kGrbEf3FcquepmDCIa8wjLHb048TRQvxaVhjK3NHic3p+NM7RwTfILt suutp2XIOy/6v+etsatoWHEx5Ss1Ghw= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=Z8qCMwWK; spf=pass (imf01.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.222.179 as permitted sender) smtp.mailfrom=jgg@ziepe.ca; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714402591; a=rsa-sha256; cv=none; b=GW4CD7EvD7A49hC+WyerycKr4DRXVYoTXDVK2esxy66UAI1iWYiPWiN2dqsxIeUq75rOEB i0PxxR8v7G1aPQ/es5iwG31ytoA6c9vrxeQsqOccH8MPaSm0dwG2GreX8MvHQZR+KNkGPg ECXrjZx84CDBU070INLMG1711v1IMeo= Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-790f91b834cso71012085a.0 for ; Mon, 29 Apr 2024 07:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1714402590; x=1715007390; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=WyfECjGT2cPe5HE/2z0fDQqdazh8yGo98dGumX8os9Y=; b=Z8qCMwWKmIzzBZ+ZTxZF7OZgxeGOcVR1T2zTpZ2nzJnaVO4txQECiNtUf6xWEj6OQ7 au836N0VvE22eeD8pXBdPihhkenLiNv9LG2+p667BI0O7aax6QXDH0ODoInBXhduzxnK fhuFgjrjIaGirfkt3/v21DaRWgQhTNrq2zLSSVi6rJ/ee5QJtXfQIL4ViuD96FtUZ3cR ndaKAMHzSQAETA7Jm7Q/Z/v5UAiw6Ny0WLqimWw4vjSZmKC5OyemnB3pX7lx9/HTrX5O +7vLluckSo+Y5p4zVRhSeqS5mot4TVUaY0cI+CR7aJGhqUeMaw2oWBCfclNbxfNaNErn HQQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714402590; x=1715007390; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WyfECjGT2cPe5HE/2z0fDQqdazh8yGo98dGumX8os9Y=; b=REdT9S5pX0T/HM8CIBMbCkKecx/O/stvK6UsK5CMa5uB4TR4PHobNlV0S8tvPqOg71 LXdEVQ53GP397O8UaSgHUTQswhQQIseTg1wprqbXCdXU4Dcr2yobk9VkAzK+gK5Ir5E6 LGRaRg+nIna5lFQObF5g9RZi98m6kpek/MCrDgCbXPO1Eh1O35K3CV3FQ0c3ZfE9LfE/ wkXQBXziLadMTzqmudZyh4IwacAS7AwRViC3YBHu32AE4rVD5OtJTs1x+w8QxTjthIQY VT01k+cxkn/hdndAhHuGbLO/7mhKlY2m58EUkV75hR3jHt/esuH5dh1VD+n41TbKXvGL paXQ== X-Forwarded-Encrypted: i=1; AJvYcCW/VbUZAMmImva8gRJEOMiEMbSaSq9jBDXaNw39Xy33CSxGffSk6I/YdwoftJHvVI/rvxUlFDBFuQZa5A7pRuzv7hI= X-Gm-Message-State: AOJu0Yz6rL3UPdsPS3mXJcfR7nvAmo9ccOcgUrD5G+RfRLt9DWpFQ6wM oUoewEOa2Cf0RZVuMCnGGikvdfr4fn0Pfi/lXgcVmeoovT2V825hDkAURs0isJiyc3QVP+BwBJT q X-Google-Smtp-Source: AGHT+IGVwrWen1NFJQXMe84L+uew1vCbsRt/8eFOs7aaXjU9TsngFFpgUz3SkXHgLUIQ5SMhLpHX/w== X-Received: by 2002:a05:620a:47c2:b0:788:31a1:4a16 with SMTP id du2-20020a05620a47c200b0078831a14a16mr12178748qkb.43.1714402590105; Mon, 29 Apr 2024 07:56:30 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-68-80-239.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.80.239]) by smtp.gmail.com with ESMTPSA id op53-20020a05620a537500b0078d67d40c49sm10499522qkn.70.2024.04.29.07.56.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Apr 2024 07:56:29 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1s1SQf-001WJH-1Y; Mon, 29 Apr 2024 11:56:29 -0300 Date: Mon, 29 Apr 2024 11:56:29 -0300 From: Jason Gunthorpe To: Pasha Tatashin Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rientjes@google.com, dwmw2@infradead.org, baolu.lu@linux.intel.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, iommu@lists.linux.dev Subject: Re: [RFC v2 2/3] iommu/intel: synchronize page table map and unmap operations Message-ID: <20240429145629.GO231144@ziepe.ca> References: <20240426034323.417219-1-pasha.tatashin@soleen.com> <20240426034323.417219-3-pasha.tatashin@soleen.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240426034323.417219-3-pasha.tatashin@soleen.com> X-Rspam-User: X-Rspamd-Queue-Id: 07C9D4000E X-Rspamd-Server: rspam06 X-Stat-Signature: ocgnu866onh88qw77z3ozchh9k1sotqp X-HE-Tag: 1714402590-338316 X-HE-Meta: U2FsdGVkX18cAxDyF2xInLVbkTxFC1JILf7Mk0pumb4fikZiGyQalPx+oXY7fYUBG0hH5nxPIpskdZoj/Jsu+BzVsrjVAfZH8yg3bTsTMdwkhmLV/4DIiPsnKsyJOySZ+lTNNL6y4DSXylfMEoNW3pr4A23qIvyeCt2Zs3PPSHB+JwA7USgw4LhNxCMJX1VBS1JFsZ6n4jxJRCa3BXgHdIE+hAmGJRT55pFbI4u5Opjgd1LA7w7lqktCnMd+1xcMmB97weFQHd6aY6b2o79KOhkCOCqUI2Y2uEBpt0E9mZFN/Nd6ahfZmK7dyMa+WfdfRdFOmSXBo8XGvCvFqsaE8swOOxYR7dQh+FkxxhtGD6eehgXx0E6cShTJa3Fx1NWgauQjUhpMx7gn96EzBbybhzWiKTugqiON+FMHrR5CXem8iBQ29Bmhwo1i8rsUOls9O7SJybyLydBnuJyyqRYdhb71ftSqFep7gXOp7N47L3dH4t4LgTTmsjdn1rcIHwqvedKWdk3zEG9n4SIC9R1N/hMagjI0ZgFW7sRMrBq6TRqcbwsW4fzk1VdnctHk9xdcnwA5x7rofIw2tLfMeUQ5vD9bSJWdI9yA2NY3QPI7Af5KtzQjr8FgZHGRx1pUjh15hlUbJl00CG5l7FTaDTLW1EGBHN9HVLFKRcqSQ+7qal+HI/Qe6anj+Y9Y7DrVwEhGoQtb/4gtEtzZD8UU8W0Q9MLkh8A2MKTkXuYhGdY9PT0Z/9RzHbMi8swy1DuKdJXUbnEaeSOES4Wh5xPnvbzatnbWx9AlxzjXAshqZ1rgMfGpdja2AU3UcEdYeGHJcUeIqIHcHxqnn6N4xwLchzSXAYdL4XuW0IkKsG4733A0/79iFqjPP8WVlD46OxtxiCuiG+znMJO6r/Rrkx/Pnh1yFn2l6m8KuwnaruFIYBXPz6pfw1D+T0goOKRf9efFLLPxxdox4jvYMgJ/bF5pzxV sROsDzHv EfD3gMSlc6LWka16p6PEFdQ2vSYU6xnc+aTyiHRShWHAiyD8= 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: List-Subscribe: List-Unsubscribe: On Fri, Apr 26, 2024 at 03:43:22AM +0000, Pasha Tatashin wrote: > Since, we are going to update parent page table entries when lower > level page tables become emtpy and we add them to the free list. > We need a way to synchronize the operation. > > Use domain->pgd_lock to protect all map and unmap operations. > This is reader/writer lock. At the beginning everything is going to be > read only mode, however, later, when free page table on unmap is added > we will add a writer section as well. > > Signed-off-by: Pasha Tatashin > --- > drivers/iommu/intel/iommu.c | 21 +++++++++++++++++++-- > drivers/iommu/intel/iommu.h | 3 +++ > 2 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > index 1bfb6eccad05..8c7e596728b5 100644 > --- a/drivers/iommu/intel/iommu.c > +++ b/drivers/iommu/intel/iommu.c > @@ -995,11 +995,13 @@ static void dma_pte_free_pagetable(struct dmar_domain *domain, > unsigned long last_pfn, > int retain_level) > { > + read_lock(&domain->pgd_lock); I think no to this. This is a very performance sensitive path for the DMA API, we really do want to see a lockless RCU scheme to manage this overhead here. This would be fine for a VFIO user, which I guess is your use case. IMHO it is not a good idea to fiddle around the edges like this. We need to get the iommu code to having shared algorithms for the radix tree so we can actually implement something good here and share it. Every driver has the same problem and needs the same complicated fix. I keep threatening to work on that but have yet to start.. Jason