From: Jason Gunthorpe <jgg@nvidia.com>
To: Niklas Schnelle <schnelle@linux.ibm.com>
Cc: Matthew Rosato <mjrosato@linux.ibm.com>,
iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Gerd Bayer <gbayer@linux.ibm.com>,
Pierre Morel <pmorel@linux.ibm.com>,
linux-s390@vger.kernel.org, borntraeger@linux.ibm.com,
hca@linux.ibm.com, gor@linux.ibm.com,
gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
svens@linux.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/5] iommu/s390: Use RCU to allow concurrent domain_list iteration
Date: Fri, 21 Oct 2022 12:04:34 -0300 [thread overview]
Message-ID: <Y1K1AqVWEyY0/Uqy@nvidia.com> (raw)
In-Reply-To: <89a748fb5caee8be5d91806aa5dfd131e92d5d82.camel@linux.ibm.com>
On Fri, Oct 21, 2022 at 05:01:32PM +0200, Niklas Schnelle wrote:
> On Fri, 2022-10-21 at 10:36 -0300, Jason Gunthorpe wrote:
> > On Fri, Oct 21, 2022 at 02:08:02PM +0200, Niklas Schnelle wrote:
> > > On Thu, 2022-10-20 at 08:05 -0300, Jason Gunthorpe wrote:
> > > > On Thu, Oct 20, 2022 at 10:51:10AM +0200, Niklas Schnelle wrote:
> > > >
> > > > > Ok that makes sense thanks for the explanation. So yes my assessment is
> > > > > still that in this situation the IOTLB flush is architected to return
> > > > > an error that we can ignore. Not the most elegant I admit but at least
> > > > > it's simple. Alternatively I guess we could use call_rcu() to do the
> > > > > zpci_unregister_ioat() but I'm not sure how to then make sure that a
> > > > > subsequent zpci_register_ioat() only happens after that without adding
> > > > > too much more logic.
> > > >
> > > > This won't work either as the domain could have been freed before the
> > > > call_rcu() happens, the domain needs to be detached synchronously
> > > >
> > > > Jason
> > >
> > > Yeah right, that is basically the same issue I was thinking of for a
> > > subsequent zpci_register_ioat(). What about the obvious one. Just call
> > > synchronize_rcu() before zpci_unregister_ioat()?
> >
> > Ah, it can be done, but be prepared to wait >> 1s for synchronize_rcu
> > to complete in some cases.
> >
> > What you have seems like it could be OK, just deal with the ugly racy
> > failure
> >
> > Jason
>
> I'd tend to go with synchronize_rcu(). It won't leave us with spurious
> error logs for the failed IOTLB flushes and as you said one expects
> detach to be synchronous. I don't think waiting in it will be a
> problem. But this is definitely something you're more of an expert on
> so I'll trust your judgement. Looking at other callers of
> synchronize_rcu() quite a few of them look to be in similar
> detach/release kind of situations though not sure how frequent and
> performance critical IOMMU domain detaching is in comparison.
I would not do it on domain detaching, that is something triggered by
userspace through VFIO and it could theoritically happen alot, eg in
vIOMMU scenarios.
Jason
next prev parent reply other threads:[~2022-10-21 15:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 14:51 [PATCH 0/5] iommu/s390: Further improvements Niklas Schnelle
2022-10-18 14:51 ` [PATCH 1/5] iommu/s390: Make attach succeed even if the device is in error state Niklas Schnelle
2022-10-28 15:55 ` Matthew Rosato
2022-10-18 14:51 ` [PATCH 2/5] iommu/s390: Add I/O TLB ops Niklas Schnelle
2022-10-28 16:03 ` Matthew Rosato
2022-10-31 16:11 ` Robin Murphy
2022-11-02 10:51 ` Niklas Schnelle
2022-10-18 14:51 ` [PATCH 3/5] iommu/s390: Use RCU to allow concurrent domain_list iteration Niklas Schnelle
2022-10-18 15:18 ` Jason Gunthorpe
2022-10-19 8:31 ` Niklas Schnelle
2022-10-19 11:53 ` Jason Gunthorpe
2022-10-20 8:51 ` Niklas Schnelle
2022-10-20 11:05 ` Jason Gunthorpe
2022-10-21 12:08 ` Niklas Schnelle
2022-10-21 13:36 ` Jason Gunthorpe
2022-10-21 15:01 ` Niklas Schnelle
2022-10-21 15:04 ` Jason Gunthorpe [this message]
2022-10-24 15:22 ` Niklas Schnelle
2022-10-24 16:26 ` Jason Gunthorpe
2022-10-27 12:44 ` Niklas Schnelle
2022-10-27 12:56 ` Jason Gunthorpe
2022-10-27 13:35 ` Niklas Schnelle
2022-10-27 14:03 ` Jason Gunthorpe
2022-10-28 9:29 ` Niklas Schnelle
2022-10-28 11:28 ` Jason Gunthorpe
2022-10-21 15:05 ` Niklas Schnelle
2022-10-18 14:51 ` [PATCH 4/5] iommu/s390: Optimize IOMMU table walking Niklas Schnelle
2022-10-18 14:51 ` [PATCH 5/5] s390/pci: use lock-free I/O translation updates Niklas Schnelle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1K1AqVWEyY0/Uqy@nvidia.com \
--to=jgg@nvidia.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gbayer@linux.ibm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=robin.murphy@arm.com \
--cc=schnelle@linux.ibm.com \
--cc=svens@linux.ibm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).