linux-kernel - Re: [patch 1/3] mm: memcontrol: lockless page counters

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: <20141003154134.GG4816@dhcp22.suse.cz>
Date:	Fri, 3 Oct 2014 17:41:34 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	Vladimir Davydov <vdavydov@...allels.com>
Cc:	Johannes Weiner <hannes@...xchg.org>, linux-mm@...ck.org,
	Greg Thelen <gthelen@...gle.com>, Dave Hansen <dave@...1.net>,
	cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 1/3] mm: memcontrol: lockless page counters

On Fri 03-10-14 19:36:23, Vladimir Davydov wrote:
> On Thu, Oct 02, 2014 at 08:07:48AM -0400, Johannes Weiner wrote:
[...]
> > The barriers are implied in change-return atomics, which is why there
> > is an xchg.  But it's clear that this needs to be documented.  This?:
> 
> With the comments it looks correct to me, but I wonder if we can always
> rely on implicit memory barriers issued by atomic ops. Are there any
> archs where it doesn't hold?

xchg is explcitly mentioned in Documentation/memory-barriers.txt so it
is expected to be barrier on all archs. Besides that not all atomic ops
imply memory barriers. Only those that "modifies some state in memory
and returns information about the state" do.
 
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/