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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19990 invoked from network); 20 Apr 2022 23:56:33 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Apr 2022 23:56:33 -0000 Received: (qmail 28181 invoked by uid 550); 20 Apr 2022 23:56:31 -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 28148 invoked from network); 20 Apr 2022 23:56:30 -0000 Date: Wed, 20 Apr 2022 19:56:17 -0400 From: Rich Felker To: Leonid Shamis Cc: musl@lists.openwall.com Message-ID: <20220420235617.GE7074@brightrain.aerifal.cx> References: 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 list not issuing FUTEX_WAKE 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). Rich