On 26.07.19 10:44, Michal Hocko wrote: > On Fri 26-07-19 10:36:42, David Hildenbrand wrote: >> On 26.07.19 10:31, Michal Hocko wrote: > [...] >>> Anyway, my dislike of the device_hotplug_lock persists. I would really >>> love to see it go rather than grow even more to the hotplug code. We >>> should be really striving for mem hotplug internal and ideally range >>> defined locking longterm. >> >> Yes, and that is a different story, because it will require major >> changes to all add_memory() users. (esp, due to the documented race >> conditions). Having that said, memory hotplug locking is not ideal yet. > > I am really happy to hear that we are on the same page here. Do we have > any document (I am sorry but I am lacking behind recent development in > this area) that describes roadblocks to remove device_hotplug_lock? Only the core-api document I mentioned (I documented there quite some current conditions I identified back then). I am not sure if we can remove it completely from add_memory()/remove_memory(): We actually create/delete devices which can otherwise create races with user space. Besides that: - try_offline_node() needs the lock to synchronize against cpu hotplug - I *assume* try_online_node() needs it as well Then, there is the possible race condition with user space onlining memory avoided by the lock. Also, currently the lock protects the "online_type" when onlining memory. Then, there might be other global variables (eventually zone/node/section related) that might need this lock right now - no details known. IOW, we have to be very carefully and it is more involved than it might seem. Locking is definitely better (and more reliably!) than one year ago, but there is definitely a lot to do. (unfortunately, just like in many areas in memory hotplug code :( - say zone handling when offlining/failing to online memory). -- Thanks, David / dhildenb
