Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Aug 2019 12:49:03 +0200
From:      Mateusz Guzik <mjguzik@gmail.com>
To:        Andriy Gapon <avg@freebsd.org>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>,  "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: userret: assert td_lk_slocks == 0
Message-ID:  <CAGudoHGm87sGxz5hkfpNONQxhFVvN=kROgHSpqg_MEZw4o=cwg@mail.gmail.com>
In-Reply-To: <94110a73-3c55-e87e-96ae-475014e45596@FreeBSD.org>
References:  <94110a73-3c55-e87e-96ae-475014e45596@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 8/12/19, Andriy Gapon <avg@freebsd.org> wrote:
>
> I am trying to debug a leak of a shared vnode lock and I noticed that
> there is no check for td_lk_slocks in userret.  There are checks for
> td_rw_rlocks and td_sx_slocks.  I wonder if there is any valid scenario
> where a thread is allowed to retain a shared lock manager lock across
> system calls.
>

These counters are not for debugging purposes. They are part of poor
man's starvation prevention for writers.

If the target lock is taken for reading and someone wants to take it for
writing, a bit will be set to denote this fact and prevent more readers
from showing up. However, this can lead to deadlocks so if someone
already has a read lock on something, they can bypass the bit and
grab the extra read lock anyway.

No locks are allowed to leak back to userspace and witness should
already handles checking this for readers as well.

-- 
Mateusz Guzik <mjguzik gmail.com>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHGm87sGxz5hkfpNONQxhFVvN=kROgHSpqg_MEZw4o=cwg>