On Mon, Mar 6, 2017 at 12:22 AM, Heiko Carstens <[email protected]> wrote: > Hello Dan, > >> > If you look at commit 5e33bc4165f3 ("driver core / ACPI: Avoid device hot >> > remove locking issues") then lock_device_hotplug_sysfs() was introduced to >> > avoid a different subtle deadlock, but it also sleeps uninterruptible, but >> > not for more than 5ms ;) >> > >> > However I'm not sure if the device hotplug lock should also be used to fix >> > an unrelated bug that was introduced with the get_online_mems() / >> > put_online_mems() interface. Should it? >> >> No, I don't think it should. >> >> I like your proposed direction of creating a new lock internal to >> mem_hotplug_begin() to protect active_writer, and stop relying on >> lock_device_hotplug to serve this purpose. >> >> > If so, we need to sprinkle around a couple of lock_device_hotplug() calls >> > near mem_hotplug_begin() calls, like Sebastian already started, and give it >> > additional semantics (protecting mem_hotplug.active_writer), and hope it >> > doesn't lead to deadlocks anywhere. >> >> I'll put your proposed patch through some testing. > > On s390 it _seems_ to work. Did it pass your testing too? > If so I would send a patch with proper patch description for inclusion.
Looks ok here. No lockdep warnings running it through it paces with the persistent memory use case.
