mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] Robust mutex returning ESRCH
@ 2020-09-29 16:31 Leonid Shamis
  2020-09-29 18:48 ` Rich Felker
  0 siblings, 1 reply; 4+ messages in thread
From: Leonid Shamis @ 2020-09-29 16:31 UTC (permalink / raw)
  To: musl

[-- 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 --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] Robust mutex returning ESRCH
  2020-09-29 16:31 [musl] Robust mutex returning ESRCH Leonid Shamis
@ 2020-09-29 18:48 ` Rich Felker
  2020-09-29 19:02   ` Leonid Shamis
  0 siblings, 1 reply; 4+ messages in thread
From: Rich Felker @ 2020-09-29 18:48 UTC (permalink / raw)
  To: Leonid Shamis; +Cc: musl

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] Robust mutex returning ESRCH
  2020-09-29 18:48 ` Rich Felker
@ 2020-09-29 19:02   ` Leonid Shamis
  2020-09-29 19:28     ` Rich Felker
  0 siblings, 1 reply; 4+ messages in thread
From: Leonid Shamis @ 2020-09-29 19:02 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

[-- 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 --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] Robust mutex returning ESRCH
  2020-09-29 19:02   ` Leonid Shamis
@ 2020-09-29 19:28     ` Rich Felker
  0 siblings, 0 replies; 4+ messages in thread
From: Rich Felker @ 2020-09-29 19:28 UTC (permalink / raw)
  To: Leonid Shamis; +Cc: musl

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-09-29 19:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-29 16:31 [musl] Robust mutex returning ESRCH Leonid Shamis
2020-09-29 18:48 ` Rich Felker
2020-09-29 19:02   ` Leonid Shamis
2020-09-29 19:28     ` Rich Felker

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ http://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git