On 09/04/2019 01:46 PM, David Hildenbrand wrote: > On 03.09.19 11:45, Anshuman Khandual wrote: >> Memory hot remove uses get_nid_for_pfn() while tearing down linked sysfs >> entries between memory block and node. It first checks pfn validity with >> pfn_valid_within() before fetching nid. With CONFIG_HOLES_IN_ZONE config >> (arm64 has this enabled) pfn_valid_within() calls pfn_valid(). >> >> pfn_valid() is an arch implementation on arm64 (CONFIG_HAVE_ARCH_PFN_VALID) >> which scans all mapped memblock regions with memblock_is_map_memory(). This >> creates a problem in memory hot remove path which has already removed given >> memory range from memory block with memblock_[remove|free] before arriving >> at unregister_mem_sect_under_nodes(). Hence get_nid_for_pfn() returns -1 >> skipping subsequent sysfs_remove_link() calls leaving node <-> memory block >> sysfs entries as is. Subsequent memory add operation hits BUG_ON() because >> of existing sysfs entries. > Since > > commit 60bb462fc7adb06ebee3beb5a4af6c7e6182e248 > Author: David Hildenbrand <david@xxxxxxxxxx> > Date: Wed Aug 28 13:57:15 2019 +1000 > > drivers/base/node.c: simplify unregister_memory_block_under_nodes() > > that problem should be gone. There is no get_nid_for_pfn() call anymore. Yes, the problem is gone. The above commit is still not present on arm64 tree against which this series was rebased and tested while posting. > > So this patch should no longer be necessary - but as I said during > earlier versions of this patch, the re-ordering might still make sense > for consistency (removing stuff in the reverse order they were added). > You'll have to rephrase the description then. Sure will reword the commit message on these lines.
