On Wed, 12 Oct 2022 at 19:16, Peter Xu <pet...@redhat.com> wrote: > > On Tue, Oct 11, 2022 at 06:41:52PM -0400, Peter Xu wrote: > > NOTE: mark patchset RFC because "make check" will easily fail; but I didn't > > yet dig into why as I'm not familiar with the code paths that triggers, it > > can be bugs hidden or something I missed. So RFC to just have some > > thoughts. > > I just noticed (after reminded from Dave) that the reclock was actually the > recursive lock, which definitely won't work with patch 2 at all. > > OTOH I also noticed PTHREAD_MUTEX_ERRORCHECK which does the same unlock > check that we can leverage (and it'll also check re-lock from the same > thread which causes deadlock). I'll give that a shot instead.
We used to use PTHREAD_MUTEX_ERRORCHECK, but stopped because it does not work with the idiom we use for handling mutexes across fork() where you take the lock in the parent, and then unlock it in the child after the fork. With glibc's implementation of PTHREAD_MUTEX_ERRORCHECK the unlock in the child fails. See commit 24fa90499f8b24bcba29 from 2015. thanks -- PMM
