[musl] Robust mutex returning ESRCH

[musl] Robust mutex returning ESRCH

[Leonid Shamis]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 475 bytes --]

Re: [musl] Robust mutex returning ESRCH

[Rich Felker]

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

Re: [musl] Robust mutex returning ESRCH

[Leonid Shamis]

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

It was priority-inheritance.

Is it worth adding a check for ESRCH and converting it to EOWNERDEAD? Or
should it stay UB?

On Tue, Sep 29, 2020 at 11:48 AM Rich Felker <dalias@libc.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.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 1610 bytes --]

Re: [musl] Robust mutex returning ESRCH

[Rich Felker]

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@libc.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.