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.3 required=5.0 tests=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 10851 invoked from network); 29 Sep 2020 19:28:43 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 29 Sep 2020 19:28:43 -0000 Received: (qmail 18281 invoked by uid 550); 29 Sep 2020 19:28:38 -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 18260 invoked from network); 29 Sep 2020 19:28:37 -0000 Date: Tue, 29 Sep 2020 15:28:25 -0400 From: Rich Felker To: Leonid Shamis Cc: musl@lists.openwall.com Message-ID: <20200929192825.GG17637@brightrain.aerifal.cx> References: <20200929184803.GF17637@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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 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.