linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Jason Gunthorpe <jgg@nvidia.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 17:05:17 +0200	[thread overview]
Message-ID: <12366a6d2a367de0e2a6f26ac9485e50a32aa7e6.camel@linux.ibm.com> (raw)
In-Reply-To: <89a748fb5caee8be5d91806aa5dfd131e92d5d82.camel@linux.ibm.com>

On Fri, 2022-10-21 at 17:01 +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.
> 
> Thanks,
> Niklas
> 

Addendum, of course independently of whether to use synchronize_rcu()
I'll change the error handling in the IOTLB ops to not skip over the
other devices.


  parent reply	other threads:[~2022-10-21 15:05 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
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 [this message]
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=12366a6d2a367de0e2a6f26ac9485e50a32aa7e6.camel@linux.ibm.com \
    --to=schnelle@linux.ibm.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=jgg@nvidia.com \
    --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=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).