From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-21669-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
	RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham
	autolearn_force=no version=3.4.4
Received: from second.openwall.net (second.openwall.net [193.110.157.125])
	by inbox.vuxu.org (Postfix) with SMTP id B781B27A22
	for <ml@inbox.vuxu.org>; Sat,  1 Feb 2025 17:03:41 +0100 (CET)
Received: (qmail 8135 invoked by uid 550); 1 Feb 2025 16:03:36 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
x-ms-reactions: disallow
Received: (qmail 8100 invoked from network); 1 Feb 2025 16:03:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1738425807;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=jUa8SgyOsldpLa5/HFwwqyg1uik1NCZh4W1YuwsD5yg=;
	b=jRRJQuSLDeXrM6KGLbj2wK7nwMJDhF8WImykXbmCgpj0cA4+MwGPwIHn55RYJ9l7IHmNKm
	0x4PWAjMiposSMXFgPhBPGmH2qonCijquwKoknOkJDnZYUHNQfOc2leUL49YkRL2yVR4Jx
	x6l19pgodiUChVa1gbl0Cvdvd0nblsE=
X-MC-Unique: EYLPj-dAPA-UsB5RLtoZOQ-1
X-Mimecast-MFC-AGG-ID: EYLPj-dAPA-UsB5RLtoZOQ
From: Florian Weimer <fweimer@redhat.com>
To: Daniele Personal <d.dario76@gmail.com>
Cc: Rich Felker <dalias@libc.org>,  d.dario76@fmail.com,
  musl@lists.openwall.com
In-Reply-To: <455063b99060bfd0d01aff1666ebb3892e001256.camel@gmail.com>
	(Daniele Personal's message of "Fri, 31 Jan 2025 10:31:46 +0100")
References: <b602b57212d44e7f90708ba9ed6aad02597fc885.camel@gmail.com>
	<20250128150258.GS10433@brightrain.aerifal.cx>
	<87cyg6iyo8.fsf@oldenburg.str.redhat.com>
	<455063b99060bfd0d01aff1666ebb3892e001256.camel@gmail.com>
Date: Sat, 01 Feb 2025 17:03:20 +0100
Message-ID: <878qqpbqk7.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: mJkD9eRGmIaN9KVSFFctdx2F6iSB4zDBdRNKHtLrOH8_1738425805
X-Mimecast-Originator: redhat.com
Content-Type: text/plain
Subject: Re: [musl] pthread_mutex_t shared between processes with different
 pid namespaces

* Daniele Personal:

>> Is this required for implementing the unlock-if-not-owner error code
>> on mutex unlock?
>
> No, I don't see problems related to EOWNERDEAD.

Sorry, what I meant is that the TID is needed for efficient reporting of
usage errors.  It's not imposed by the robust list protocol as such.
There could be a PID-namespace-compatible robust mutex type that does
not have this problem (but with less error checking).

Thanks,
Florian