Re: [PATCH 2/2] xen/rwlock: add check_lock() handling to rwlocks

[Jürgen Groß <jgross@xxxxxxxx>]

On 30.10.20 16:10, Jan Beulich wrote:
> On 30.10.2020 15:25, Juergen Gross wrote:
> > --- a/xen/include/xen/rwlock.h
> > +++ b/xen/include/xen/rwlock.h
> > @@ -65,7 +65,11 @@ static inline int _read_trylock(rwlock_t *lock)
> >            * arch_lock_acquire_barrier().
> >            */
> >           if ( likely(_can_read_lock(cnts)) )
> > +        {
> > +            check_lock(&lock->lock.debug, true);
> >               return 1;
> > +        }
> Why not unconditionally earlier in the function?
Its trylock, so we don't want to call check_lock() without having
got the lock.

> > @@ -87,7 +91,10 @@ static inline void _read_lock(rwlock_t *lock)
> >        * arch_lock_acquire_barrier().
> >        */
> >       if ( likely(_can_read_lock(cnts)) )
> > +    {
> > +        check_lock(&lock->lock.debug, false);
> >           return;
> > +    }
> >   
> >       /* The slowpath will decrement the reader count, if necessary. */
> >       queue_read_lock_slowpath(lock);
> I guess doing so here and ...
>
> > @@ -162,7 +169,10 @@ static inline void _write_lock(rwlock_t *lock)
> >        * arch_lock_acquire_barrier().
> >        */
> >       if ( atomic_cmpxchg(&lock->cnts, 0, _write_lock_val()) == 0 )
> > +    {
> > +        check_lock(&lock->lock.debug, false);
> >           return;
> > +    }
> >   
> >       queue_write_lock_slowpath(lock);
> ... here is okay, as the slow paths have checks anyway.
>
> > @@ -205,6 +215,8 @@ static inline int _write_trylock(rwlock_t *lock)
> >           return 0;
> >       }
> >   
> > +    check_lock(&lock->lock.debug, true);
> But here I again think it wants moving up.
No, another trylock.


Juergen