aboutsummaryrefslogtreecommitdiffstats
path: root/fs/cramfs
diff options
context:
space:
mode:
authorHugh Dickins <hugh@veritas.com>2008-03-04 14:29:12 -0800
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2008-03-04 16:35:15 -0800
commit6d48ff8bcfd403ec8d3ef7a56538ea9e6f773b9c (patch)
tree9331ed70405f4933ac923a7595268ee7e773018e /fs/cramfs
parentb9c565d5a29a795f970b4a1340393d8fc6722fb9 (diff)
downloadkernel_samsung_smdk4412-6d48ff8bcfd403ec8d3ef7a56538ea9e6f773b9c.zip
kernel_samsung_smdk4412-6d48ff8bcfd403ec8d3ef7a56538ea9e6f773b9c.tar.gz
kernel_samsung_smdk4412-6d48ff8bcfd403ec8d3ef7a56538ea9e6f773b9c.tar.bz2
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 'fs/cramfs')
0 files changed, 0 insertions, 0 deletions