Messages in this thread | | | Date | Wed, 6 Nov 2013 16:30:05 -0800 (PST) | From | David Rientjes <> | Subject | Re: BUG: soft lockup - CPU#8 stuck for 22s! |
| |
On Mon, 4 Nov 2013, Mel Gorman wrote:
> This maybe? > > ---8<--- > mm: memcontrol: Release css_set_lock when aborting an OOM scan > > css_task_iter_start acquires the css_set_lock and it must be released with > a call to css_task_iter_end. Commmit 9cbb78bb (mm, memcg: introduce own > oom handler to iterate only over its own threads) introduced a loop that > was not guaranteed to call css_task_iter_end. > > Cc: stable <stable@vger.kernel.org> > Signed-off-by: Mel Gorman <mgorman@suse.de> > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 5ef8929..941f67d 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -1795,6 +1795,7 @@ static void mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t gfp_mask, > mem_cgroup_iter_break(memcg, iter); > if (chosen) > put_task_struct(chosen); > + css_task_iter_end(&it); > return; > case OOM_SCAN_OK: > break;
What tree is this?
I'm afraid I don't understand this at all, I thought css_task_iter_end() was added to take over for cgroup_task_iter_end() and mem_cgroup_out_of_memory() was modified with 72ec7029937f ("cgroup: make task iterators deal with cgroup_subsys_state instead of cgroup") correctly. Why do we need to call css_task_iter_end() twice with your patch?
| |