On Tue, Jun 3, 2025 at 12:45 PM Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> wrote: > On Tue, Jun 03, 2025 at 12:25:36AM +0200, Jann Horn wrote: > > The one way in which I think this is currently kinda yolo/broken is > > that vmap_try_huge_pud() can end up freeing page tables via > > pud_free_pmd_page(), while holding no MM locks AFAICS, so that could > > race with the ptdump debug logic such that ptdump walks into freed > > page tables? > > But those mappings would be kernel mappings? How could ptdump walk into > those? /sys/kernel/debug/page_tables/kernel dumps kernel page tables. And I think /sys/kernel/debug/page_tables/current_kernel dumps page tables for the entire address space including both userspace and kernel. > > (I think we should take all the vma locks in that ptdump code and get > > rid of this weird exception instead of documenting it.) > > We really need to be sure that there aren't some weird architectures doing > weird things or circumstances where this is meaningful. > > I mean people went to great lengths to make this possible, I find it hard > to believe there aren't some _weird_ real world use cases. FWIW, looking through the git logs for the x86 version of it, it seems to mainly be used by developers of arch-specific code trying to debug/validate kernel behavior.
