Re: [PATCH v9 5/6] vduse: add vq group asid support

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Nov 19, 2025 at 11:38:32AM +0100, Eugenio Perez Martin wrote:
> On Wed, Nov 19, 2025 at 10:32 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Wed, Nov 19, 2025 at 10:26:43AM +0100, Eugenio Perez Martin wrote:
> > > > But this is not the logic that is
> > > > implemented in this patch as there's no synchronize_rcu() in the
> > > > vduse_set_group_asid_nomsg().
> > >
> > > We only set the pointer on the writer's side, we do nothing like
> > > freeing resources. Should we set the pointer before or after
> > > syncrhonize_rcu()?
> >
> > synchronize_rcu is called after writer makes it's changes.
> >
> > > What do we need to do on the other side of
> > > syncrhonize_rcu()?
> >
> > Presumably, return so the caller knows the as has been updated.
> >
> 
> I'm happy to add the syncrhonize_rcu() just in case, but the caller of
> vduse_set_group_asid_nomsg does not need to know that the reader has
> been updated.
> 
> The first caller is vduse_dev_reset which has its own way to avoid
> being called while vqs are being processed. In particular, it reset
> their addresses which is way more dangerous. I could call it with
> dev->rwsem down though.
> 
> The second one is set_group_asid vdpa callback which is called from
> the ioctl itself.

This one for sure needs to know that after ioctl completed
the new AS is in use.

> Moreover, rcu_assign_pointer is WRITE_ONCE by itself so we know all
> the readers will get the new value after it.


No we don't. The words "after it" do not have a meaning on an SMP
system. The only way to know that another CPU sees a value
is to synchronize with it.


> So what's the value of
> explicitly waiting for all the readers to finalize their DMA operation?


Read Documentation/memory-barriers.txt
If still unclear, read it again ))

> I'd understand if we need to do modifications or memory management in
> the now unused ASID, but that's not the case here.
> 
> > However, user-triggerable synchronize_rcu() is almost always a bug.
> >
> > If that's what is going on, you want srcu.
> >
> 
> I did not know about it, thanks! but I think all the code that can
> sleep is out of the RCU critical sections now, isn't it?


what I tried to say is that if triggering synchronize_rcu from userspace
is a problem, srcu is one solution.