[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250708122755.GV1410929@nvidia.com>
Date: Tue, 8 Jul 2025 09:27:55 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Baolu Lu <baolu.lu@...ux.intel.com>
Cc: Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
Robin Murphy <robin.murphy@....com>,
Kevin Tian <kevin.tian@...el.com>, Jann Horn <jannh@...gle.com>,
Vasant Hegde <vasant.hegde@....com>,
Dave Hansen <dave.hansen@...el.com>,
Alistair Popple <apopple@...dia.com>,
Peter Zijlstra <peterz@...radead.org>,
Uladzislau Rezki <urezki@...il.com>,
Jean-Philippe Brucker <jean-philippe@...aro.org>,
Andy Lutomirski <luto@...nel.org>, Yi Lai <yi1.lai@...el.com>,
iommu@...ts.linux.dev, security@...nel.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 1/1] iommu/sva: Invalidate KVA range on kernel TLB flush
On Tue, Jul 08, 2025 at 01:42:53PM +0800, Baolu Lu wrote:
> > +void iommu_sva_invalidate_kva_range(unsigned long start, unsigned long end)
> > +{
> > + struct iommu_mm_data *iommu_mm;
> > +
> > + might_sleep();
>
> Yi Lai <yi1.lai@...el.com> reported an issue here. This interface could
> potentially be called in a non-sleepable context.
Oh thats really bad, the notifiers inside the iommu driver are not
required to be called in a sleepable context either and I don't really
want to change that requirement.
Can you do something about how the notifier is called to not be inside
an atomic context?
Maybe we can push the kernel page table pages onto a list and free
them from a work queue kind of like what the normal mm does?
Back to the shadowing idea?
Jason
Powered by blists - more mailing lists