Re: mm: deadlock between get_online_cpus/pcpu_alloc
From: Mel Gorman <hidden>
Date: 2017-02-07 16:22:29
Also in:
lkml
On Tue, Feb 07, 2017 at 04:34:59PM +0100, Michal Hocko wrote:
quoted
But we do not care about the whole cpu hotplug code. The only part we really do care about is the race inside drain_pages_zone and that will run in an atomic context on the specific CPU. You are absolutely right that using the mutex is safe as well but the hotplug path is already littered with locks and adding one more to the picture doesn't sound great to me. So I would really like to not use a lock if that is possible and safe (with a big fat comment of course).And with the full changelog. I hope I haven't missed anything this time. --- From 8c6af3116520251cc4ec2213f0a4ed2544bb4365 Mon Sep 17 00:00:00 2001 From: Michal Hocko <mhocko@suse.com> Date: Tue, 7 Feb 2017 16:08:35 +0100 Subject: [PATCH] mm, page_alloc: do not depend on cpu hotplug locks inside the allocator <SNIP> Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Michal Hocko <mhocko@suse.com>
Not that I can think of. It's almost identical to the diff I posted with the exception of the mutex in the cpu hotplug teardown path. I agree that in the current implementation that it should be unnecessary even if I thought it would be more robust against any other hotplug churn. Acked-by: Mel Gorman <redacted> -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>