linux-kernel - Re: Re: [RFC][PATCH 2/5] mips/atomic: Fix loongson_llsc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <201905152150256295825@loongson.cn>
Date:   Wed, 15 May 2019 21:50:27 +0800
From:   "huangpei@...ngson.cn" <huangpei@...ngson.cn>
To:     "Linus Torvalds" <torvalds@...ux-foundation.org>,
        "Peter Zijlstra" <peterz@...radead.org>
Cc:     "Paul Burton" <paul.burton@...s.com>,
        "stern@...land.harvard.edu" <stern@...land.harvard.edu>,
        "akiyks@...il.com" <akiyks@...il.com>,
        "andrea.parri@...rulasolutions.com" 
        <andrea.parri@...rulasolutions.com>,
        "boqun.feng@...il.com" <boqun.feng@...il.com>,
        "dlustig@...dia.com" <dlustig@...dia.com>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "j.alglave@....ac.uk" <j.alglave@....ac.uk>,
        "luc.maranget@...ia.fr" <luc.maranget@...ia.fr>,
        "npiggin@...il.com" <npiggin@...il.com>,
        "paulmck@...ux.ibm.com" <paulmck@...ux.ibm.com>,
        "will.deacon@....com" <will.deacon@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        陈华才 <chenhc@...ote.com>
Subject: Re: Re: [RFC][PATCH 2/5] mips/atomic: Fix loongson_llsc_mb() wreckage


>On Tue, May 14, 2019 at 8:58 AM Peter Zijlstra <peterz@...radead.org> wrote:
>>
>> So if two variables share a line, and one is local while the other is
>> shared atomic, can contention on the line, but not the variable, cause
>> issues for the local variable?
>>
>> If not; why not? Because so far the issue is line granular due to the
>> coherence aspect.
>
>If I understood the issue correctly, it's not that cache coherence
>doesn't work, it's literally that the sc succeeds when it shouldn't.
>
>In other words, it's not going to affect anything else, but it means
>that "ll/sc" isn't actually truly atomic, because the cacheline could
>have bounced around to another CPU in the meantime.
>
>So we *think* we got an atomic update, but didn't, and the "ll/sc"
>pair ends up incorrectly working as a regular "load -> store" pair,
>because the "sc' incorrectly thought it still had exclusive access to
>the line from the "ll".
>
>The added memory barrier isn't because it's a memory barrier, it's
>just keeping the subsequent speculative instructions from getting the
>cacheline back and causing that "sc" confusion.
>
>But note how from a cache coherency standpoint, it's not about the
>cache coherency being wrong, it's literally just about the ll/sc not
>giving the atomicity guarantees that the sequence is *supposed* to
>give. So an "atomic_inc()" can basically (under just the wrong
>circumstances) essentially turn into just a non-atomic "*p++".
> 
Agreed，that is exactly what I was learned.

>NOTE! I have no actual inside knowledge of what is going on. The above
>is purely my reading of this thread, and maybe I have mis-understood.
> 

you got it right.
>                  Linus