linux-kernel - Re: BUG: soft lockup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 7 Nov 2013 09:06:29 +0000
From:	Mel Gorman <mgorman@...e.de>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Don Morris <don.morris@...com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: 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@...r.kernel.org>
> > Signed-off-by: Mel Gorman <mgorman@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/