From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 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 9DB3326325 for ; Mon, 3 Feb 2025 18:26:03 +0100 (CET) Received: (qmail 1092 invoked by uid 550); 3 Feb 2025 17:25:58 -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 x-ms-reactions: disallow Received: (qmail 1072 invoked from network); 3 Feb 2025 17:25:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738603549; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Zi1VDrWNl6RunCimDrtW4XarRvhrunSInasMcrYHsDU=; b=jD9xUth6mLUZcaf1jH8q8y99BUgZZqD9t5pzcBMcFNwOJ6nnCjhwDEHrxHv7W/Dd28e1vz 2158YNPa5hvQYDyhsYwLNfmdpCgc122G63w7FwNoROnEd3k3QFPiFvmOjpEx8kBOT6q4C1 UsM30aAmTxl3ugX46dkUlX478CPu+s4= X-MC-Unique: 1jKohCJUM1Csd92C9Fht8Q-1 X-Mimecast-MFC-AGG-ID: 1jKohCJUM1Csd92C9Fht8Q From: Florian Weimer To: Daniele Personal Cc: d.dario76@fmail.com, Rich Felker , musl@lists.openwall.com In-Reply-To: <1bd9cb5599cbc4d55b342b1b4cb4b138b9c48a5b.camel@gmail.com> (Daniele Personal's message of "Mon, 03 Feb 2025 13:58:21 +0100") References: <20250128150258.GS10433@brightrain.aerifal.cx> <87cyg6iyo8.fsf@oldenburg.str.redhat.com> <455063b99060bfd0d01aff1666ebb3892e001256.camel@gmail.com> <878qqpbqk7.fsf@oldenburg.str.redhat.com> <1bd9cb5599cbc4d55b342b1b4cb4b138b9c48a5b.camel@gmail.com> Date: Mon, 03 Feb 2025 18:25:41 +0100 Message-ID: <87ed0fj5yi.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.4 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Oy_-FkkrnZm-lnzHTGxJLgcqF31p4P1EXb_q1CxXZiA_1738603547 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] pthread_mutex_t shared between processes with different pid namespaces * Daniele Personal: > On Sat, 2025-02-01 at 17:03 +0100, Florian Weimer wrote: >> * Daniele Personal: >>=20 >> > > Is this required for implementing the unlock-if-not-owner error >> > > code >> > > on mutex unlock? >> >=20 >> > No, I don't see problems related to EOWNERDEAD. >>=20 >> Sorry, what I meant is that the TID is needed for efficient reporting >> of >> usage errors.=C2=A0 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). >>=20 >> Thanks, >> Florian >>=20 > > Are you saying that there are pthread_mutexes which can be shared > across processes run on different pid namespaces? If yes I'm definitely > interested on this. Can you tell me something more? You would have to add a new mutex type that is a mix of PTHREAD_MUTEX_NORMAL amd PTHREAD_MUTEX_ROBUST. Closer to the latter, but without the ownership checks. Thanks, Florian