[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8c044e49-74bb-df56-8a60-663013c0910e@intel.com>
Date: Tue, 26 Apr 2022 08:27:00 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Jean-Philippe Brucker <jean-philippe@...aro.org>
Cc: "zhangfei.gao@...mail.com" <zhangfei.gao@...mail.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Joerg Roedel <joro@...tes.org>,
Ravi V Shankar <ravi.v.shankar@...el.com>,
Tony Luck <tony.luck@...el.com>,
Ashok Raj <ashok.raj@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
x86 <x86@...nel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
iommu <iommu@...ts.linux-foundation.org>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Andy Lutomirski <luto@...nel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>, will@...nel.org,
robin.murphy@....com, zhangfei.gao@...aro.org
Subject: Re: [PATCH v4 05/11] iommu/sva: Assign a PASID to mm on PASID
allocation and free it on mm exit
On 4/25/22 09:40, Jean-Philippe Brucker wrote:
> The problem is that we'd have to request the device driver to stop DMA
> before we can destroy the context and free the PASID. We did consider
> doing this in the release() MMU notifier, but there were concerns about
> blocking mmput() for too long (for example
> https://lore.kernel.org/linux-iommu/4d68da96-0ad5-b412-5987-2f7a6aa796c3@amd.com/
> though I think there was a more recent discussion). We also need to drain
> the PRI and fault queues to get rid of all references to that PASID.
Is the concern truly about blocking mmput() itself? Or, is it about
releasing the resources associated with the mm?
Powered by blists - more mailing lists