Date: Tue, 29 Sep 2020 14:48:05 -0400 From: Rich Felker <dalias@...c.org> To: Leonid Shamis <leonid.shamis@...il.com> Cc: musl@...ts.openwall.com Subject: Re: Robust mutex returning ESRCH On Tue, Sep 29, 2020 at 09:31:12AM -0700, Leonid Shamis wrote: > We had a bug in our code where a dying process released shared memory > (munmap) prior to exit. The process held ownership of a robust mutex within > the shared memory, and because the address was unmapped, the robust_list > wasn't able to set the appropriate flags. > > The next attempt to lock the mutex, in another process, returned ESRCH. > > Should ESRCH be caughtand converted to either a recoverable EOWNERDEAD or > ENOTRECOVERABLE? Was it also priority-inheritance? Otherwise I don't see where ESRCH should have come from. Unmapping the mutex while you hold is should almost surely be treated as undefined (though I don't think the standard spells this out explicitly anywhere). It probably would be nice to avoid returning a bogus error code to the non-erroneous caller sharing the robust mutex with a program that has UB, but I don't think Linux admits any efficient general solution here. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.