lkml.org 
[lkml]   [2013]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BUG: soft lockup - CPU#8 stuck for 22s!
On Wed, Nov 06, 2013 at 04:30:05PM -0800, David Rientjes wrote:
> 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?

I screwed up, patch is broken. I'll recheck for imbalances in the
handling of css_set_lock. Sorry for the noise.

--
Mel Gorman
SUSE Labs


\
 
 \ /
  Last update: 2013-11-07 10:21    [W:0.044 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site