Re: BUG: soft lockup - CPU#8 stuck for 22s!

[David Rientjes]

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@xxxxxxxxxxxxxxx>
> Signed-off-by: Mel Gorman <mgorman@xxxxxxx>
> 
> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/