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=-1.5 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 19700 invoked from network); 25 May 2023 16:53:36 -0000
Received: from second.openwall.net (193.110.157.125)
  by inbox.vuxu.org with ESMTPUTF8; 25 May 2023 16:53:36 -0000
Received: (qmail 14227 invoked by uid 550); 25 May 2023 16:53:32 -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
Received: (qmail 14182 invoked from network); 25 May 2023 16:53:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417;
	t=1685033600; i=nullplan@gmx.net;
	bh=F0GIgujQOSXBWQfvZDNYYXSwdZMG+TGR2Hxg6Ed4j80=;
	h=X-UI-Sender-Class:Date:From:To:Subject;
	b=UO6kP+x9nsRd2VwU39zV9SbiKbaM720svkCwL1nxHcgLh21H0QrHnMldbXqGqgLqT
	 iTQw7+R5wnIp4FzbmmSyGXLTbDgPqw/qLJjN7Rx+sqb8t+y1dGJemNx+S+R0Vnx6ZP
	 xkABMWqiDJu0KeOgXwxndzDiZ4wosFd6PCkBeMxuvLEyUI9tp84xniJyfKXp7FS9se
	 2fTPyyWyIrzC2nSd7oFflX9nXZSyhswJZUzppATStjNRQRFVzM3g6Q5lCZlBBR0VFI
	 a79nnlgvykWxGyYaG1mNRc81KLEcRDZ6JNcJXuPk8Fr+HLSe7Arg/ABkjsvTR2KjRE
	 sGMu330ysnmAw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Date: Thu, 25 May 2023 18:53:19 +0200
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Message-ID: <ZG+Sfzr1ZK0FQ1W/@voyager>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Provags-ID: V03:K1:vovEsRXbnk0EFx/mSJVPs5aw6nFYhmmo12danCtfNJW2K8FIFVF
 JrZRER4VS2Ja6ggD0E/IX/fPhoQQ26QvXel5/3JzN/c9syLQGgsOjZ6DXMmVzI2guIoYLbG
 Q9BLkBPBGzHrvZWwmVcPoY5yZkl6TshbQbfwvbt2oGWX604JgOCweKuSNdaNEEewbBy/wIj
 7fDZPii9uTf8cC0QM1iwA==
UI-OutboundReport: notjunk:1;M01:P0:ffRbxlEDUk4=;cmFK1Nm6Tto1d0KJxi5I0q1jKcO
 ES9gTTLWiY4yjWJE9UQb4kkCg37GXikKYYUc+2vHH1WpWSrB3kyhBGljdXyEiC1lgttxKVw7B
 ZaBuQtRF4ra7sG/JWJjRRcJgnMbkZT5y9ulb0IQ0TyReATpWrnBtZVwbE0k6lRrSq5tu4KuRR
 Hadp0RiEXYhaViWBKIl3ZprTWGUvSBHBG2mf3Dzbt+Z8P5NX7djSPXCQDLHOHZmmT7Km3bt/B
 Nk9f9IoBaic9Jb6LdssKEaSKmRIsQ3WWx9GV/bruC06SsMvbe1BdZ+oCvPFVu382EUSSJpoJR
 oHyDQJ60blz1nNmJIHGvZFQdOq4uNgYwvU3OzLkI1WJy32DSPvYm+ItO8iQ1EquvT/1kehxTU
 g0ZW+EvF1fttCCfYyV+XWKbMWtpLpzQOII/4si20faIrerVm3vT8IAFjyK7ex/DJEi5tMQ2ld
 GeGGN0flZOnjkcSfYNLKM7dWe6RmsHqbMmE1U/0d6tgeuOUYodbtJrZc+4EFmnfOCSg+sbn7a
 TZfd/2iZsZnDu8NI5MPhUibfamKePQFaF6HhASpDOgcuTBlrMT1hM9zDos4dzewmclghJalVU
 HAxJNfIjwsUB6hPRyLVA5I6UO7PuAqrqKusSJM4OYxc/rQsaPH7rJwTt3s4WSNYUTYVZP3Ik7
 GuGrZNzjs05woFUUF4hp4w/6MYiOsLLUs9/TwTHgbOYLhkfn9uufF2f2Kln6X4XLot3Ej8lmf
 PbdFxoJj0jkzv9+3AntG0f5zwLebxa18jzfsUdz0bzm887j2ZYDbzST0Y70mapTgWUx3XzxbC
 3KWh2apmO7r9I6w2pwu/AM21ygL6eRssJOSwN6CpwhjZEWT0gXyvRNFmIgAXE4Oq+eDllYUWM
 4jQmBrj7qlkQFX9HKdovrmzAMO9Mj7w3xHAV2T53RsR/PV1LwUzRLctMJ5TIlMYwLQq4jJkuY
 P2tlOA==
Subject: [musl] vm lock needed in mprotect?

Hi all,

I'm wondering if the vm lock is needed in mprotect(), similar to
munmap(). Reason for the vm lock was that if an application had two
threads waiting on a process-shared barrier, and one thread came out of
it to immediately unmap the SHM segment, then the other thread might not
yet have had a change to exit pthread_barrier_wait(), and since that
function accesses the barrier object after the last futex wait call, it
would crash.

So what if that first thread, instead of unmapping the SHM, just changes
its protection to read-only? That would also crash. Or is that somehow
not valid? If so, why?

Ciao,
Markus