linux-kernel - Re: [PATCH RFC tip/core/rcu 12/15] lib/assoc_array: Remove smp_read_barrier

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+aMzyBeRpXR2DGY=AASxYUGT4N+-MWW4ykLFxCpY0pFAg@mail.gmail.com>
Date:   Wed, 11 Oct 2017 20:43:48 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Paul McKenney <paulmck@...ux.vnet.ibm.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        David Howells <dhowells@...hat.com>,
        Will Deacon <will.deacon@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-arch@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        Alexander Kuleshov <kuleshovmail@...il.com>
Subject: Re: [PATCH RFC tip/core/rcu 12/15] lib/assoc_array: Remove smp_read_barrier_depends()

On Wed, Oct 11, 2017 at 7:34 PM, Paul E. McKenney
<paulmck@...ux.vnet.ibm.com> wrote:
> On Wed, Oct 11, 2017 at 07:11:37PM +0200, Peter Zijlstra wrote:
>> On Wed, Oct 11, 2017 at 10:06:31AM -0700, Paul E. McKenney wrote:
>>
>> > This, you mean?
>> >
>> > data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data));
>>
>> Yep, that one. Although in my tree it now appears to look like:
>>
>>         data = rcu_dereference_sched(*per_cpu_ptr(&cpufreq_update_util_data,
>>                                                   cpu_of(rq)));
>
> So in the non-RCU case, we could simply replace rcu_dereference_sched()
> with ACCESS_ONCE(), right?  Thus no need to change the per-CPU
> primitives.  Especially given that most uses of per-CPU variables
> don't even need protection from load/store tearing, let alone
> protection from Alpha.

A long thread and I lost track somewhat, but, yes, from KTSAN (data
race detector) point of view we will need a way to understand when
things are ordered due to data and control dependencies
(i.e.effectively acquire but only wrt the dependent stuff).
There is a logic level and physical level, it's perfectly fine if on
physical level all these _DEP/_CTRL variants are no-op (the same as
READ_ONCE, at least on todays archs with todays compilers). But on
logical level they represent a well defined, meaningful thing. Say,
when you proof-read code for correctness, the fact that there is a
dependency can be important and crucial. But tools can's always figure
that out, and even if they can it's still useful to distinguish
between normal dependencies (that are all over the place) and the ones
that are important for correctness. It also makes code more explicit,
rather then relying on some tricky implicit guarantees. Say, like
__user annotations which we could wipe out from codegen point of view.