Re: [RFC 01/20] iommu/iommufd: Add /dev/iommu core

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Oct 19, 2021 at 10:11:34AM -0700, Jacob Pan wrote:
> Hi Jason,
> 
> On Tue, 19 Oct 2021 13:57:47 -0300, Jason Gunthorpe <jgg@nvidia.com> wrote:
> 
> > On Tue, Oct 19, 2021 at 09:57:34AM -0700, Jacob Pan wrote:
> > > Hi Jason,
> > > 
> > > On Fri, 15 Oct 2021 08:18:07 -0300, Jason Gunthorpe <jgg@nvidia.com>
> > > wrote: 
> > > > On Fri, Oct 15, 2021 at 09:18:06AM +0000, Liu, Yi L wrote:
> > > >   
> > > > > >   Acquire from the xarray is
> > > > > >    rcu_lock()
> > > > > >    ioas = xa_load()
> > > > > >    if (ioas)
> > > > > >       if (down_read_trylock(&ioas->destroying_lock))    
> > > > > 
> > > > > all good suggestions, will refine accordingly. Here destroying_lock
> > > > > is a rw_semaphore. right? Since down_read_trylock() accepts a
> > > > > rwsem.    
> > > > 
> > > > Yes, you probably need a sleeping lock
> > > >   
> > > I am not following why we want a sleeping lock inside RCU protected
> > > section?  
> > 
> > trylock is not sleeping
> Of course, thanks for clarifying.
> 
> > > For ioas, do we really care about the stale data to choose rw_lock vs
> > > RCU? Destroying can be kfree_rcu?  
> > 
> > It needs a hard fence so things don't continue to use the IOS once it
> > is destroyed.
> I guess RCU can do that also perhaps can scale better?

RCU is not a fence, it is an eventual consistency mechanism and has
very bad scaling if you don't use things like kfree_rcu

Jason