On Fri 24-10-14 09:36:05, Johannes Weiner wrote: > On Fri, Oct 24, 2014 at 10:58:07AM +0200, Michal Hocko wrote: > > On Thu 23-10-14 14:19:29, Johannes Weiner wrote: > > > On Thu, Oct 23, 2014 at 06:47:45PM +0200, Jan Kara wrote: > > > > 'curr' pointer in task_in_mem_cgroup() can be NULL when we race with > > > > somebody clearing task->mm. Check for it before dereferencing the > > > > pointer. > > > > > > If task->mm is already NULL, we fall back to mem_cgroup_from_task(), > > > which definitely returns a memcg unless you pass NULL in there. So I > > > don't see how that could happen, and the NULL checks in the fallback > > > branch as well as in __mem_cgroup_same_or_subtree seem bogus to me. > > > > It came from 3a981f482cc2 (memcg: fix use_hierarchy css_is_ancestor oops > > regression). I do not see mem_cgroup_same_or_subtree called from > > page_referenced path so it is probably gone. > > It's still there in invalid_page_referenced_vma(). And it can still > pass NULL. Ohh, my bad. I wasn't careful enough to check mm_match_cgroup. > > task_in_mem_cgroup is just confused because curr can never be NULL as > > the task is never NULL. > > That's correct. > > My patches to clean all this up have been stress-tested over night, I > will send them out in a jiffy. Will wait for your patch. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
