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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19099 invoked from network); 4 Oct 2022 10:28:48 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Oct 2022 10:28:48 -0000 Received: (qmail 24116 invoked by uid 550); 4 Oct 2022 10:28:45 -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 24075 invoked from network); 4 Oct 2022 10:28:45 -0000 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 9ACED40D403D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1664879313; bh=KUJ8TnHKNDgNzIfTKAaR1zr7E4KrENqF+OIZk+tfAqQ=; h=Date:From:To:Subject:Reply-To:In-Reply-To:References:From; b=OqJka+uoEGveJzHQibS5bJKQoywGaZC8mABgy5rgt2unc4YgePhIkBs96unsKDpUC kdST1cERHTu1AvXu3+s2UMThmKNpjsKrL3yojrmgAV6Ge4Kzw4Z8qNuCrotItEFCMM te8YWf3u4Cqk3CefP16qEFZOI/kZqRiOOi8WD5Qs= MIME-Version: 1.0 Date: Tue, 04 Oct 2022 13:28:33 +0300 From: Alexey Izbyshev To: musl@lists.openwall.com Mail-Followup-To: musl@lists.openwall.com In-Reply-To: <20221004083120.GI2158779@port70.net> References: <20220919152937.GQ9709@brightrain.aerifal.cx> <20221003132615.GF2158779@port70.net> <20221003212705.GG2158779@port70.net> <20221004083120.GI2158779@port70.net> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <24e0c9a0f9ebc5741d1967a793f2aa82@ispras.ru> X-Sender: izbyshev@ispras.ru Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] Illegal killlock skipping when transitioning to single-threaded state On 2022-10-04 11:31, Szabolcs Nagy wrote: > * Alexey Izbyshev [2022-10-04 08:16:16 +0300]: > >> On 2022-10-04 00:27, Szabolcs Nagy wrote: >> > * Szabolcs Nagy [2022-10-03 15:26:15 +0200]: >> > i think i was wrong and you are right. >> > >> > so with your suggested swap of UNLOCK(killlock) and need_locks=-1 and >> > starting with 'something == 0' the exiting E and remaining R threads: >> > >> > E:something=1 // protected by killlock >> > E:UNLOCK(killlock) >> > E:need_locks=-1 >> > >> > R:LOCK(unrelated) // reads need_locks == -1 >> > R:need_locks=0 >> > R:UNLOCK(unrelated) >> > R:LOCK(killlock) // does not lock >> > R:read something // can it be 0 ? >> > >> > and here something can be 0 (ie. not protected by killlock) on aarch64 >> > because >> > >> > T1 >> > something=1 >> > ldaxr ... killlock >> > stlxr ... killlock >> > need_locks=-1 >> > >> > T2 >> > x=need_locks >> > ldaxr ... unrelated >> > stlxr ... unrelated >> > y=something >> > >> > can end with x==-1 and y==0. >> > >> Yes, overall this matches my understanding. However, your UNLOCK >> expansion >> (in T1/T2) omits the branch instruction between stlxr and the >> following >> store, and, as I mentioned, I'm not sufficiently knowledgeable to >> understand >> the effects of this branch on the order of visibility of "stlxr >> killlock" >> (and preceding stores) and "need_locks=-1". > > i don't know the answer, but i think in musl we don't want to rely on > control dependcies in the architectural memory model anyway (in some > cases the compiler can break it and it's hard to reason about). > I agree. The answer appears to be that the reordering can occur even in the presence of the branch instruction[1], though I haven't confirmed it with tools that show valid executions yet. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697#c23 Thanks, Alexey