[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 29 Sep 2020 15:28:25 -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 12:02:47PM -0700, Leonid Shamis wrote:
> It was priority-inheritance.
>
> Is it worth adding a check for ESRCH and converting it to
> EOWNERDEAD? Or should it stay UB?
It's not either/or. There's no way to guarantee getting ESRCH here
because the pid can be reused, and there's no way to get the kernel to
fix the ownership when the owner unmaps it. The question is just
whether we can improve the situation meaningfully, and I'm not sure.
Rich
> On Tue, Sep 29, 2020 at 11:48 AM Rich Felker <dalias@...c.org> wrote:
>
> > 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.
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.
