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=-8.6 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28553 invoked from network); 5 Oct 2022 13:53:35 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 5 Oct 2022 13:53:35 -0000 Received: (qmail 7628 invoked by uid 550); 5 Oct 2022 13:53:32 -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 Received: (qmail 7583 invoked from network); 5 Oct 2022 13:53:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=ZlSGmkj3O6HRRCju8awyB3Kvrz/cwH4isZ8mLNZDxhA=; b=mkylSkcmuMBZuFRENSjvUu7xxsqXR7nrplPkfrg5pdoLHKhEZoWUIvHH++LO+UIRAv zT9sqR1LEZBxVOG64RtF96JrgPaywGxRlmk5U6G9JAZwtg0vvftAZ8FNTFFTr798WyJV ZiPAq/GKyPFDobx71NPtOUwpgQrTuRju+5iHa5SmYHYMoSPzA9le5Cd1pdEsU7ty+Lx6 HaQXkUnX8pDCDkryo8DfDGf00bdMKXflmD6Z/QxfejLKK39XWEytdAdKxuXbP/I5BJ+K o7z1yy2uzcf3J64bc7B+9AY8gYxrDVeBxTAHaGEojAgO8VG2FvgVscL0CpA50y5ukt0m WaZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=ZlSGmkj3O6HRRCju8awyB3Kvrz/cwH4isZ8mLNZDxhA=; b=xnvpuZtzb7m8ClnNaxaYggHjSRyW5KxgOzh9l1yzO7uNm4Ky3O8UHa7U4fniI7o6qG jWfXFeXZiUHFoOTVFLAUu6fOFZSvte690CeIXz/KH+cjYrwbZXryUWC41UgyQc0zmMKp WVwNVePg3ELLXXbg1Fz9EaIytjv8HPq9KYf8nzx3GpOrr+gmFk/YnHxhsTaqlxaVUslb dFY0XInjeTRq4CIQj4y2xf/P1q+Tg2nMnnalYulxjTe/irGcWLJZPEk4V0ob1QI/nM88 Nlj+4VGnCmMpOhhig1tjNoJsdTALk3Dqbl1XXDjw/gK3vDcNXkkiVHxGwRK2RDcSUYQY eX8A== X-Gm-Message-State: ACrzQf1oxYC8IepK4eCYOP2pLr8hu2kUGTe9/JrQzLBUlyU/jA6XJ8TO 2exgw1hRxUEMh4qy/s0JOU8d7oPFrbNkUgrYMYwOjQ== X-Google-Smtp-Source: AMsMyM72y+2JlX6Pem1Qas2XBHAZITZ+sBiJHdWZ5xNh3z9WY5fiSEFHncz0ciRXj0moKOnLp24XaX7qyuFRDyab+e4= X-Received: by 2002:a25:6610:0:b0:6bd:cd70:b6f6 with SMTP id a16-20020a256610000000b006bdcd70b6f6mr12889460ybc.68.1664977999678; Wed, 05 Oct 2022 06:53:19 -0700 (PDT) MIME-Version: 1.0 References: <20220919152937.GQ9709@brightrain.aerifal.cx> <20221003132615.GF2158779@port70.net> <20221003212705.GG2158779@port70.net> <20221003225416.GG29905@brightrain.aerifal.cx> <20221003230505.GH29905@brightrain.aerifal.cx> <2e77a700561a059e85daad5311306cfb@ispras.ru> <20221004141242.GL29905@brightrain.aerifal.cx> <20221004164557.GO29905@brightrain.aerifal.cx> In-Reply-To: <20221004164557.GO29905@brightrain.aerifal.cx> From: James Y Knight Date: Wed, 5 Oct 2022 09:52:53 -0400 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000003b65c005ea49e669" Subject: Re: [musl] Illegal killlock skipping when transitioning to single-threaded state --0000000000003b65c005ea49e669 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 4, 2022 at 12:46 PM Rich Felker wrote: > The atomics in musl implement the "POSIX memory model" which is much > simpler to understand and less error-prone than the C11 one (with the > tradeoff being that it admits a lot less optimization for > performance), and is a valid implementation choice for the C11 one. It > has only one relationship, "synchronizes memory", that all > synchronization primitives and atomics entail. Mmmm, maybe I'm weird, but I find it significantly easier to understand when code uses the standard atomics, because there is copious information available about that model -- what it means, the real-world implications of those semantics, and the correct instruction sequences to properly implement them on various architectures. Memory and concurrency models are _really_ _hard_ no matter what (as I think this thread demonstrates), and having a standardized model to base things on is a huge advantage. If musl's model was "C11 atomics, but we only use seq_cst operations", that would be wonderful...but it's not. It's something different -- with different guarantees, and different implications, and thus requires developers to do unique analysis. Atomics in musl are implemented > entirely in asm, because the compilers do not get theirs right and do > not support the runtime selection of methods necessary for some of the > archs we support (especially 32-bit arm and sh). Even if you need to provide a custom implementation to workaround compiler issues on some platforms, IMO it'd still be an improvement to mirror the standard API/semantics -- and to use the compiler support on all the platforms where it does work. Though, I do believe it ought to DTRT on ARM32 Linux targets. When targeting older CPUs that don't guarantee LLSC availability, the compiler will generate a function call to a libgcc function. That library function then calls the kernel-provided kuser_helper cmpxchg and barrier functions. (gcc/libgcc/config/arm/linux-atomic.c for the libgcc side). Then, which instruction sequence is used to implement the atomics is handled purely by the kernel helper. This design _should_ be correct for all ARM CPUs, but with a bit of overhead if running on a modern CPU (because operations like fetch_add get implemented on top of cmpxchg). But, I dunno, perhaps there's bugs. I've never looked at the situation on SuperH...but going by the GCC manual's description of -matomic-model...yikes...that does look like a complete mess of a situation all around. --0000000000003b65c005ea49e669 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 4, 2022 = at 12:46 PM Rich Felker <dalias@libc.= org> wrote:=C2=A0=C2=A0
The atomics in musl implement the &qu= ot;POSIX memory model" which is much
simpler to understand and less error-prone than the C11 one (with the
tradeoff being that it admits a lot less optimization for
performance), and is a valid implementation choice for the C11 one. It
has only one relationship, "synchronizes memory", that all
synchronization primitives and atomics entail.

<= div>Mmmm, maybe I'm weird, but I find it significantly easier to unders= tand when code uses the standard atomics, because there is=C2=A0copious inf= ormation available about that model -- what it means, the real-world implic= ations of those semantics, and the correct instruction sequences to properl= y implement them on various architectures. Memory and concurrency models ar= e _really_ _hard_ no matter what (as I think this thread demonstrates), and= having a standardized model to base things on is a huge advantage. If musl= 's model was "C11 atomics, but we only use seq_cst operations"= ;, that would be wonderful...but it's not. It's something different= -- with different guarantees, and different implications, and thus require= s developers to do unique analysis.

Atomics in musl are implemented
enti= rely in asm, because the compilers do not get theirs right and do
not su= pport the runtime selection of methods necessary for some of the
archs w= e support (especially 32-bit arm and sh).

Even if you need to provide a custom implementati= on to workaround compiler issues on some platforms, IMO it'd still be a= n improvement to mirror the standard API/semantics -- and to use the compil= er support on all the platforms where it does work.

Though, I do believe it ought to DTRT on ARM32 Linux targets.=C2=A0Wh= en targeting older CPUs that don't guarantee=C2=A0LLSC availability, th= e compiler will generate a function call to a libgcc function. That library= function then calls the kernel-provided kuser_helper cmpxchg and barrier f= unctions. (gcc/libgcc/config/arm/linux-atomic.c for the libgcc side). Then,= which instruction=C2=A0sequence is used to implement the atomics is handle= d purely by the kernel helper. This design _should_ be correct for all ARM = CPUs, but with a bit of overhead if running on a modern CPU (because operat= ions like fetch_add get implemented on top of cmpxchg). But, I dunno, perha= ps there's bugs.

I've never looked at the = situation on SuperH...but going by the GCC manual's description of -mat= omic-model...yikes...that does look like a complete mess of a situation all= around.

--0000000000003b65c005ea49e669--