[Intel-gfx] [PATCH 5/5] dma-buf: nuke reservation_object seq number

Daniel Vetter daniel at ffwll.ch
Mon Aug 5 16:41:46 UTC 2019


On Mon, Aug 05, 2019 at 05:07:41PM +0100, Chris Wilson wrote:
> Quoting Christian K├Ânig (2019-08-05 16:45:54)
> > @@ -214,16 +214,16 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll)
> >                 return 0;
> >  
> >  retry:
> > -       seq = read_seqcount_begin(&resv->seq);
> >         rcu_read_lock();
> >  
> > +       fence_excl = rcu_dereference(resv->fence_excl);
> >         fobj = rcu_dereference(resv->fence);
> >         if (fobj)
> >                 shared_count = fobj->shared_count;
> >         else
> >                 shared_count = 0;
> > -       fence_excl = rcu_dereference(resv->fence_excl);
> > -       if (read_seqcount_retry(&resv->seq, seq)) {
> > +
> > +       if (rcu_dereference(resv->fence_excl) != fence_excl) {
> 
> If I remember my rules correctly, rcu_dereference is a
> read-data-depends, which only means that a read through the pointer
> returned by rcu_dereference() is after the retrieval of that pointer.
> Nothing orders the retrieval of fence_excl vs shared_count (different
> pointers), so I think the last line should be:
> 
> smp_rmb();
> if (rcu_access_pointer(resv->fence_excl) != fence_excl)

Also, barriers must have a comment, the comment must be on both barriers
(if you don't have two, you're doing it wrong), and each barrier comment
must reference its counterpart.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list