Date: Mon, 12 Aug 2019 13:55:53 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Mateusz Guzik <mjguzik@gmail.com> 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: <ba67bed2-eded-437d-549a-4f409247397a@FreeBSD.org> In-Reply-To: <CAGudoHGm87sGxz5hkfpNONQxhFVvN=kROgHSpqg_MEZw4o=cwg@mail.gmail.com> References: <94110a73-3c55-e87e-96ae-475014e45596@FreeBSD.org> <CAGudoHGm87sGxz5hkfpNONQxhFVvN=kROgHSpqg_MEZw4o=cwg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/08/2019 13:49, Mateusz Guzik wrote: > 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. Yes, I realize that. > 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. Yes. But since we have those asserts for td_rw_rlocks and td_sx_slocks, wouldn't it make sense to add one for td_lk_slocks? If it's considered superfluous for FreeBSD, then at least I'll add it in the work's fork. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ba67bed2-eded-437d-549a-4f409247397a>