From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7944 invoked from network); 29 Sep 2020 19:03:12 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 29 Sep 2020 19:03:12 -0000 Received: (qmail 27954 invoked by uid 550); 29 Sep 2020 19:03:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 27935 invoked from network); 29 Sep 2020 19:03:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NF5awc+T/MvHMDzDxuAvwkshFPADlIYbiKnOft7uL7M=; b=GrBJkpAZzp1TL9q90komxKa5uQQQEBHm0yAWFMA8Z36fUpb/egzo5ZZLOcZI7/XKLG mUszrnqYzd0OV+KnrTkwQm+FVYNB5LzA0NqMdGPSjlzqbZJAXYyoViU3kGHpdXyEKKyb tFDNz3ZXDLbqWM5ZHzP72y7ky/VttGo/C8tVkOGmeCOURnjXLSRfngZU76ktCkjO/lTb MlV5+DBFDWT8ZrwISqLgshOrfUXP4i3r3svlkLdCDN8awRpUtpdVeXN0F5hFZ+OMYDa2 22xDmQxiKNKIr1bjUNtUJOpy7iZMxXVu7S/4xE8abmtGnqiI3Q64UYOPS9NlAsFCgqJF 6SMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NF5awc+T/MvHMDzDxuAvwkshFPADlIYbiKnOft7uL7M=; b=rjWMYqEkggLQ/0DhS7EbBdIGQOYoNigQR9XbXoCAhL9jEsHK/y1EIV1iJBnz4OB8PB xTt6J67khjtwIjO4xQiNeGCefQo06ghbPn0SS2JmvDN7rBS9Mz9cUFwFHsFo9DRXXzFJ 1tfwuKVQwBHydWyWWhvdcSOG1d0NL0w+rzKmb5QTwKRdHQa7ARbJLz4vkVwQ0AA8ytox vV2euFSdnMyvKetw3PLOfgJ4ia1j8oAYjZX53aDqNuWheU1HkwqButVbPlUZ2xAyn+/4 NeaI0+SQ69/lNQUVMrDuuMK5e++klONf/Jz5Hbtu9pLeN7TqAabxtwTfwl0yswkQz9bJ C7+A== X-Gm-Message-State: AOAM532WO28W54EyUSUZcdRbwrQmTalSJaXKHd7kYGnhfIr5jms5QWEW e3KTtdFJRs2CyblQAv9E43oSXoxFQSoey4xr/7mOJjoAsdIXLQ== X-Google-Smtp-Source: ABdhPJy20hkRfmt0z9LXCjjQW50U6ZpqyQF71+q6hLw8fh6N7wuMI1rwtDkOdl01Q0wTIgOcfrWYCMZiw3s7zD4UTnw= X-Received: by 2002:a17:906:5812:: with SMTP id m18mr5608646ejq.204.1601406178530; Tue, 29 Sep 2020 12:02:58 -0700 (PDT) MIME-Version: 1.0 References: <20200929184803.GF17637@brightrain.aerifal.cx> In-Reply-To: <20200929184803.GF17637@brightrain.aerifal.cx> From: Leonid Shamis Date: Tue, 29 Sep 2020 12:02:47 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="00000000000069997c05b0786e53" Subject: Re: [musl] Robust mutex returning ESRCH --00000000000069997c05b0786e53 Content-Type: text/plain; charset="UTF-8" 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 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 > --00000000000069997c05b0786e53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It was priority-inheritance.

Is it wort= h adding a check for ESRCH and converting it to EOWNERDEAD? Or should it st= ay 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 -070= 0, Leonid Shamis wrote:
> We had a bug in our code where a dying process released shared memory<= br> > (munmap) prior to exit. The process held ownership of a robust mutex w= ithin
> the shared memory, and because the address was unmapped, the robust_li= st
> 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<= br> Linux admits any efficient general solution here.

Rich
--00000000000069997c05b0786e53--