[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zq8tv0Hjx5N4r8j0@voyager>
Date: Sun, 4 Aug 2024 09:29:03 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Memory lock needed for semaphores?
Hi all,
in the light of the recent thread about barriers I looked at the
semaphore implementation under the light of the sudden unmap issue
again. To recap, the issue is that multiple threads may interact with
the same pshared semaphore, and in particular one thread might unmap a
semaphore that another thread is currently still interacting with.
Is that an issue with semaphores? I'm thinking of the following
scenario:
Start: One thread of another process is blocked at the semaphore
(sem->__val = {INT_MIN, 1, 0}).
Thread 1: Calls sem_post(), gets until just after the a_cas() before
being preempted (sem->__val = {1, 1, 0}, but this thread saw val < 0 and
waiters <= 1, so broadcast wake will issue once thread resumes).
Thread 2: Calls sem_trywait(), sets sem->__val = {0, 1, 0}.
Thread 2: Calls sem_post(), sets sem->__val = {1, 1, 0}, does not wake.
Thread 2: Unmaps the semaphore.
Thread 1: Resumes. SYS_futex returns EFAULT. Other process remains
sleeping.
Am I missing something that makes this impossible? If not, do we maybe
need a vmlock for posting pshared semaphores? That would probably be the
easiest fix.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
