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 18114 invoked from network); 21 Apr 2022 12:25:29 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 21 Apr 2022 12:25:29 -0000 Received: (qmail 7812 invoked by uid 550); 21 Apr 2022 12:25:26 -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 7777 invoked from network); 21 Apr 2022 12:25:25 -0000 Date: Thu, 21 Apr 2022 08:25:13 -0400 From: Rich Felker To: Leonid Shamis Cc: musl@lists.openwall.com Message-ID: <20220421122512.GF7074@brightrain.aerifal.cx> References: <20220420235617.GE7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220420235617.GE7074@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] robust list not issuing FUTEX_WAKE On Wed, Apr 20, 2022 at 07:56:17PM -0400, Rich Felker wrote: > On Wed, Apr 20, 2022 at 04:46:23PM -0700, Leonid Shamis wrote: > > Hey Musl Folks, > > > > I'm trying to understand the futex robust list and it's not quite working > > how I would expect it to from a reading of the man pages. > > > > In a minimal example, I'm getting the futex changed to FUTEX_OWNER_DIED > > instead of FUTEX_OWNER_DIED|tid and I'm not getting a FUTEX_WAKE event. > > Any idea why this might be? > > > > Happy to share the minimal example. > > Can you clarify if you're trying to use robust mutexes under musl or > roll your own thing using the kernel robust list directly? I don't > think I'm understanding what you're confused about. If the owner of a > robust mutex dies, its tid can no longer be in the futex word because > that tid is immediately available to be assigned to a new task, and > the next thread trying to lock the mutex would not be able to > distinguish whether it's owned by a new thread with that tid, or > available. > > So as far as the kernel is concerned, FUTEX_OWNER_DIED is more of a > value than a flag. It's what the futex word gets set to when the owner > dies with it held. In musl, we use FUTEX_OWNER_DIED as a flag as well > for a robust mutex whose old owner died and who has a new owner but > hasn't yet called pthread_mutex_consistent (in which case it would > become unrecoverable on unlock). Also: you only get the FUTEX_WAIT if the waiters but (bit 31) was set when the owner died.