On Tue, Apr 23, 2019 at 01:01:58PM +0530, Anshuman Khandual wrote: > Generic usage for init_mm.pagetable_lock > > Unless I have missed something else these are the generic init_mm kernel page table > modifiers at runtime (at least which uses init_mm.page_table_lock) > > 1. ioremap_page_range() /* Mapped I/O memory area */ > 2. apply_to_page_range() /* Change existing kernel linear map */ > 3. vmap_page_range() /* Vmalloc area */ Internally, those all use the __p??_alloc() functions to handle racy additions by transiently taking the PTL when installing a new table, but otherwise walk kernel tables _without_ the PTL held. Note that none of these ever free an intermediate level of table. I believe that the idea is that operations on separate VMAs should never conflict at the leaf level, and operations on the same VMA should be serialised somehow w.r.t. that VMA. AFAICT, these functions are _never_ called on the linear/direct map or vmemmap VA ranges, and whether or not these can conflict with hot-remove is entirely dependent on whether those ranges can share a level of table with the vmalloc region. Do you know how likely that is to occur? e.g. what proportion of the vmalloc region may share a level of table with the linear or vmemmap regions in a typical arm64 or x86 configuration? Can we deliberately provoke this failure case? [...] > In all of the above. > > - Page table pages [p4d|pud|pmd|pte]_alloc_[kernel] settings are > protected with init_mm.page_table_lock Racy addition is protect in this manner. > - Should not it require init_mm.page_table_lock for all leaf level > (PUD|PMD|PTE) modification as well ? As above, I believe that the PTL is assumed to not be necessary there since other mutual exclusion should be in effect to prevent racy modification of leaf entries. > - Should not this require init_mm.page_table_lock for page table walk > itself ? > > Not taking an overall lock for all these three operations will > potentially race with an ongoing memory hot remove operation which > takes an overall lock as proposed. Wondering if this has this been > safe till now ? I suspect that the answer is that hot-remove is not thoroughly stress-tested today, and conflicts are possible but rare. As above, can we figure out how likely conflicts are, and try to come up with a stress test? Is it possible to avoid these specific conflicts (ignoring ptdump) by aligning VA regions such that they cannot share intermediate levels of table? Thanks, Mark.
