diff options
author | Hugh Dickins <hugh@veritas.com> | 2008-03-04 14:29:12 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2008-03-04 16:35:15 -0800 |
commit | 6d48ff8bcfd403ec8d3ef7a56538ea9e6f773b9c (patch) | |
tree | 9331ed70405f4933ac923a7595268ee7e773018e /Documentation/rfkill.txt | |
parent | b9c565d5a29a795f970b4a1340393d8fc6722fb9 (diff) | |
download | linux-exynos-6d48ff8bcfd403ec8d3ef7a56538ea9e6f773b9c.tar.gz linux-exynos-6d48ff8bcfd403ec8d3ef7a56538ea9e6f773b9c.tar.bz2 linux-exynos-6d48ff8bcfd403ec8d3ef7a56538ea9e6f773b9c.zip |
memcg: css_put after remove_list
mem_cgroup_uncharge_page does css_put on the mem_cgroup before uncharging from
it, and before removing page_cgroup from one of its lru lists: isn't there a
danger that struct mem_cgroup memory could be freed and reused before
completing that, so corrupting something? Never seen it, and for all I know
there may be other constraints which make it impossible; but let's be
defensive and reverse the ordering there.
mem_cgroup_force_empty_list is safe because there's an extra css_get around
all its works; but even so, change its ordering the same way round, to help
get in the habit of doing it like this.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Hirokazu Takahashi <taka@valinux.co.jp>
Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Cc: Paul Menage <menage@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation/rfkill.txt')
0 files changed, 0 insertions, 0 deletions