summaryrefslogtreecommitdiff
path: root/firmware/emi26
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2015-06-24 23:58:23 (GMT)
committerLinus Torvalds <torvalds@linux-foundation.org>2015-06-25 00:49:45 (GMT)
commitc2b42d3cadbffbf5117ccdbcb3a2fc47c0d59bae (patch)
tree499feeac186fae24e36057206b51f3ca1a0bc016 /firmware/emi26
parentf4b90b70b7a4f5c29c442399ffd531332356e1f5 (diff)
downloadlinux-c2b42d3cadbffbf5117ccdbcb3a2fc47c0d59bae.tar.xz
memcg: convert mem_cgroup->under_oom from atomic_t to int
memcg->under_oom tracks whether the memcg is under OOM conditions and is an atomic_t counter managed with mem_cgroup_[un]mark_under_oom(). While atomic_t appears to be simple synchronization-wise, when used as a synchronization construct like here, it's trickier and more error-prone due to weak memory ordering rules, especially around atomic_read(), and false sense of security. For example, both non-trivial read sites of memcg->under_oom are a bit problematic although not being actually broken. * mem_cgroup_oom_register_event() It isn't explicit what guarantees the memory ordering between event addition and memcg->under_oom check. This isn't broken only because memcg_oom_lock is used for both event list and memcg->oom_lock. * memcg_oom_recover() The lockless test doesn't have any explanation why this would be safe. mem_cgroup_[un]mark_under_oom() are very cold paths and there's no point in avoiding locking memcg_oom_lock there. This patch converts memcg->under_oom from atomic_t to int, puts their modifications under memcg_oom_lock and documents why the lockless test in memcg_oom_recover() is safe. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Michal Hocko <mhocko@suse.cz> Cc: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'firmware/emi26')
0 files changed, 0 insertions, 0 deletions