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>