On 05/21/2019 03:44 PM, Michal Hocko wrote: > On Mon 20-05-19 10:48:35, Anshuman Khandual wrote: >> The arm64 page table dump code can race with concurrent modification of the >> kernel page tables. When a leaf entries are modified concurrently, the dump >> code may log stale or inconsistent information for a VA range, but this is >> otherwise not harmful. >> >> When intermediate levels of table are freed, the dump code will continue to >> use memory which has been freed and potentially reallocated for another >> purpose. In such cases, the dump code may dereference bogus addresses, >> leading to a number of potential problems. >> >> Intermediate levels of table may by freed during memory hot-remove, >> which will be enabled by a subsequent patch. To avoid racing with >> this, take the memory hotplug lock when walking the kernel page table. > > I've had a comment on this patch in the previous version which didn't > get answered completely AFAICS. If you really insist then please make > sure to describe why does this really matter because this will make > any further changes to the hotplug locking harder and I would to see > that it is worth the additional trouble. Hello Michal, I was under the impression (seems wrongful now) that the previous discussion was complete. Nonetheless we can still discuss it further. Mark has responded on the previous V3 thread [1] and because this particular patch does not have any changes from last time, we can continue discussing this in that thread. [1] https://lkml.org/lkml/2019/5/22/613 - Anshuman
