> Yes, the hotplug lock was part of the original issue. However that > starts to drift into the area I believe Oscar was working on as a part > of his patch set in encapsulating the move_pfn_range_to_zone and other > calls that were contained in the hotplug lock into their own functions. While reworking it for my patchset, I thought that we can move move_pfn_range_to_zone out of hotplug lock. But then I __think__ we would have to move init_currently_empty_zone() within the span lock as zone->zone_start_pfn is being touched there. At least that is what the zone locking rules say about it. Since I saw that Dan was still reworking his patchset about unify HMM/devm code, I just took one step back and I went simpler [1]. The main reason for backing off was I felt a bit demotivated due to the lack of feedback, and I did not want to interfer either with your work or Dan's work. Plus I also was unsure about some other things like whether it is ok calling kasan_add_zero_shadow/kasan_remove_zero_shadow out of the lock. So I decided to make less changes in regard of HMM/devm. Unfortunately, I did not get a lot of feedback there yet. Just some reviews from David and a confirmation that fixes one of the issues Jonathan reported [2]. > > I was hoping to wait until after Dan's HMM patches and Oscar's changes > had been sorted before I get into any further refactor of this specific > code. I plan to ping the series, but I wanted to give more time to people since we are in the merge window now. [1] https://patchwork.kernel.org/cover/10642049/ [2] https://patchwork.kernel.org/patch/10642057/#22275173
