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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 D1A662533D for ; Tue, 28 Jan 2025 14:22:48 +0100 (CET) Received: (qmail 18123 invoked by uid 550); 28 Jan 2025 13:22:42 -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 18091 invoked from network); 28 Jan 2025 13:22:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738070553; x=1738675353; darn=lists.openwall.com; h=mime-version:user-agent:content-transfer-encoding:date:to:reply-to :from:subject:message-id:from:to:cc:subject:date:message-id:reply-to; bh=XgRFjod5JXo4+KivXUQa0+oifUyu2HpcPsIUp4AHZJc=; b=l7UsnUWmE/JSH99wXdZO6nN0KihkBgYsdBpt7ltyr+Drpuccy3GSoNR+z+4SfSuZpe bJ9cUml/PhhlamrtY751KEONZl80g70dT+wAUS3Kq8ZQM39jhvp7sKr/TMWfsOPQGrK8 7E7fqScSBuClFEO90yxNTpFKPmtcSLZlxGDfCJq7Z8BZsaVZsQGIxShF2O+ZWl1gPW7Q ZvcGlqfly0m5cNm5T9zidsSznjBoZFSXENb2hIKZnP2m00yfJSc2NpXtfkY+rTCFaOze YBIGrFBwpLiFyusdtvEipAJl3WyIGL0tENgHB6qofqG6sWt12RDuK5HmF0Nd/cp7zdSH 4yzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738070553; x=1738675353; h=mime-version:user-agent:content-transfer-encoding:date:to:reply-to :from:subject:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XgRFjod5JXo4+KivXUQa0+oifUyu2HpcPsIUp4AHZJc=; b=LxXH2IQNbYePH0WNP1P8sKuKfWYIwbO3qVYC9ccZHTPzRb+68DYDttlv5iRALljOip gsav5D5+b7Rox7QLJQXaGFrJpV20NIekXYOqOPKG0D7lflDu12PGGnqgXsDM3QS/sjX2 4HUE6UZmcpK5jkY0NxSaoHPz5+80WcdyEXdEaGfx4Mh5ChVYoYmGGh+HikeUUCjOCP4Q QMjWTKS5hiIZhsNf2iGrr/rs/GEEBUWc8WXTuD09WRb+tUzO95XiRvI5Sk/ZkuGMyASR p84KxgNxRk6foHKvdRG+E5Pf0IE15QdcY/EY1ZG5Nf0OTDrEVDqXBx+UfdhSB7hCeG1j kF6g== X-Gm-Message-State: AOJu0YzM80Lqa4lbZtHIUwD3Jk5pZklFB/N2m2uaUTiK1OqFmJ4SRt0v Gq6HMGApfg5YyeMG0sl/tE5RKkKcXPOZ1Ocp8z0f14dFmhzdyztH3fKgUA== X-Gm-Gg: ASbGncsvb38aCBZGUK6pnwaxkDEU/uaBF4PJsenAGE3UXpE6ojRpDFv21cAsWbevRUM 0P7H41/B//TFJMKLq21qfA42LPyhtxTzMb/7dhcknZtXPOcGIynpXxT+3UEKnBc+3yrkSQ77/38 7FwlwdtQOuTbbWGK8l3H/gtlLxfIWPGu/NR46iJFu7M2ZYQS+VHW5I/n6D29QD+movIWFVyDkdX sMueiN4C4BKvaJvL2enftYSeW1Vz/fTKvOeOgCxnxApsJdfPQ9NjQW4ffhuVKaZX9k0Jh5oSccZ Ihbuk5TbxIr/0g/l0MKwCCbvNr96faryUOrormFvclXjDNFy/fjtYsh7h61/lie7OI1VigCqk2U ZM35Ki0HpjI0w X-Google-Smtp-Source: AGHT+IGwqhQ483vOwIxUt7P0q4KlNYfSU06hYSzrIx2BMO3HXV6LEHvgRz7jb0T15p76DEwfIQjp0w== X-Received: by 2002:a05:6402:13d2:b0:5da:d76:7b3f with SMTP id 4fb4d7f45d1cf-5db7d0f8663mr41974000a12.0.1738070553137; Tue, 28 Jan 2025 05:22:33 -0800 (PST) Message-ID: From: Daniele Personal To: musl@lists.openwall.com Date: Tue, 28 Jan 2025 14:22:31 +0100 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.3-0ubuntu1 MIME-Version: 1.0 Subject: [musl] pthread_mutex_t shared between processes with different pid namespaces Hello everyone, I'm working on a library linked by some processes in order to exchange information. Such library uses some pthread_mutex_t instances to safely read/write the information to exchange: the mutexes are created with the PTHREAD_PROCESS_SHARED and PTHREAD_MUTEX_ROBUST attributes and shared through shared memory mmapped by the processes. Now, for certain reasons, I have to run one of the processes in a container and I found that, after a random interval of time, the process in the container got stuck in a pthread_mutex_lock without any reason. After some investigation I figured out that if the container is started without pid namespace isolation everithing works like a charm. So the questions: is the pid namespace isolation a problem when working with shared mutexes or should I investigate in other directions? If the problem is pid namespace isolation, what could be done to make it working apart from sharing the same pid namespace? The actual development is based on musl 1.2.4 built with Yocto Scarthgap for aarch64 and arm. Thanks in advance for any help, Daniele.