linux-kernel - Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered against prior accesses

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: <20170608121944.yx7z7bv47it6zxpq@hirez.programming.kicks-ass.net>
Date:   Thu, 8 Jun 2017 14:19:44 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Will Deacon <will.deacon@....com>
Cc:     Vlastimil Babka <vbabka@...e.cz>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        mark.rutland@....com, akpm@...ux-foundation.org,
        Punit.Agrawal@....com, mgorman@...e.de, steve.capper@....com
Subject: Re: [PATCH 2/3] mm/page_ref: Ensure page_ref_unfreeze is ordered
 against prior accesses

On Thu, Jun 08, 2017 at 02:16:41PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 08, 2017 at 12:24:33PM +0100, Will Deacon wrote:

> > The horribly out-of-date atomic_ops.txt isn't so useful:
> > 
> > | If a caller requires memory barrier semantics around an atomic_t
> > | operation which does not return a value, a set of interfaces are
> > | defined which accomplish this::
> > | 
> > | 	void smp_mb__before_atomic(void);
> > | 	void smp_mb__after_atomic(void);
> > | 
> > | For example, smp_mb__before_atomic() can be used like so::
> > | 
> > | 	obj->dead = 1;
> > | 	smp_mb__before_atomic();
> > | 	atomic_dec(&obj->ref_count);
> > | 
> > | It makes sure that all memory operations preceding the atomic_dec()
> > | call are strongly ordered with respect to the atomic counter
> > | operation.  In the above example, it guarantees that the assignment of
> > | "1" to obj->dead will be globally visible to other cpus before the
> > | atomic counter decrement.
> > | 
> > | Without the explicit smp_mb__before_atomic() call, the
> > | implementation could legally allow the atomic counter update visible
> > | to other cpus before the "obj->dead = 1;" assignment.
> > 
> > which makes it sound more like the barrier is ordering all prior accesses
> > against the atomic operation itself (without going near cumulativity...),
> > and not with respect to anything later in program order.
> 
> This is correct.

Ah, my bad, It orders against everything later, the first of which is
(obviously) the atomic op itself.

It being a full barrier means both the Read and the Write of the RmW
must happen _after_ everything preceding.

> > Anyway, I think that's sufficient for what we want here, but we should
> > probably iron out the semantics of this thing.
> 
> s/smp_mb__\(before\|after\)_atomic/smp_mb/g
> 
> should not change the semantics of the code in _any_ way, just make it
> slower on architectures that already have SC atomic primitives (like
> x86).
>