On Thu, Jun 29, 2017 at 06:11:15PM +0200, Thomas Gleixner wrote: > Andrey reported a potential deadlock with the memory hotplug lock and the > cpu hotplug lock. > > The reason is that memory hotplug takes the memory hotplug lock and then > calls stop_machine() which calls get_online_cpus(). That's the reverse lock > order to get_online_cpus(); get_online_mems(); in mm/slub_common.c > > The problem has been there forever. The reason why this was never reported > is that the cpu hotplug locking had this homebrewn recursive reader writer > semaphore construct which due to the recursion evaded the full lock dep > coverage. The memory hotplug code copied that construct verbatim and > therefor has similar issues.
The only reason I copied get_online_cpus() implementation instead of using an rw semaphore was that I didn't want to deal with potential deadlocks caused by calling get_online_mems() from the memory hotplug code, like the one reported by Andrey below. However, these bugs should be pretty easy to fix, as you clearly demonstrated in response to Andrey's report. Apart from that, I don't see any problems with this patch, and the code simplification does look compelling. FWIW, Acked-by: Vladimir Davydov <vdavydov....@gmail.com> > > Two steps to fix this: > > 1) Convert the memory hotplug locking to a per cpu rwsem so the potential > issues get reported proper by lockdep. > > 2) Lock the online cpus in mem_hotplug_begin() before taking the memory > hotplug rwsem and use stop_machine_cpuslocked() in the page_alloc code > to avoid recursive locking. > > Reported-by: Andrey Ryabinin <aryabi...@virtuozzo.com> > Signed-off-by: Thomas Gleixner <t...@linutronix.de> > Cc: linux...@kvack.org > Cc: Andrew Morton <a...@linux-foundation.org> > Cc: Michal Hocko <mho...@kernel.org> > Cc: Vlastimil Babka <vba...@suse.cz>
