On Thu, Apr 06, 2023 at 04:42:02PM +0200, David Hildenbrand wrote: > On 06.04.23 16:04, Peter Zijlstra wrote: > > On Thu, Apr 06, 2023 at 03:29:28PM +0200, Peter Zijlstra wrote: > > > On Thu, Apr 06, 2023 at 09:38:50AM -0300, Marcelo Tosatti wrote: > > > > > > > > To actually hit this path you're doing something really dodgy. > > > > > > > > Apparently khugepaged is using the same infrastructure: > > > > > > > > $ grep tlb_remove_table khugepaged.c > > > > tlb_remove_table_sync_one(); > > > > tlb_remove_table_sync_one(); > > > > > > > > So just enabling khugepaged will hit that path. > > > > > > Urgh, WTF.. > > > > > > Let me go read that stuff :/ > > > > At the very least the one on collapse_and_free_pmd() could easily become > > a call_rcu() based free. > > > > I'm not sure I'm following what collapse_huge_page() does just yet. > > It wants to replace a leaf page table by a THP (Transparent Huge Page mapped > by a PMD). So we want to rip out a leaf page table while other code > (GUP-fast) might still be walking it. Right, I got that far. > In contrast to freeing the page table, > we put it into a list where it can be reuse when having to PTE-map a THP > again. Yeah, this is the bit I couldn't find, that code is a bit of a maze. > Now, similar to after freeing the page table, someone else could reuse that > page table and modify it. So ideally we'll RCU free the page instead of sticking it on that list.
