On 7 November 2016 at 19:49, Mark Rutland <mark.rutland@xxxxxxx> wrote: > On Mon, Nov 07, 2016 at 03:38:02PM +0000, Mark Rutland wrote: >> On Sun, Oct 30, 2016 at 03:03:07PM +0000, Catalin Marinas wrote: >> > On Thu, Oct 27, 2016 at 09:27:30AM -0700, Laura Abbott wrote: >> > > Laura Abbott (4): >> > > arm64: dump: Make ptdump debugfs a separate option >> > > arm64: dump: Make the page table dumping seq_file optional >> > > arm64: dump: Remove max_addr >> > > arm64: dump: Add checking for writable and exectuable pages >> > >> > Queued for 4.10. Thanks. >> >> Catalin mentioned to me that he saw some KASAN splats when testing; it >> looks like need a fixup something like the below. > > As an aside, it looks like any ptdump usage when KASAN is enabled takes > several minutes, which at boot time looks like a hang. > > AFAICT, this is because KASAN allocates *huge* VA ranges (4TB+) worth of > zeroed shadow memory at pte granularity (reusing the same pmd, pud, > tables), and the ptdump code dutifully walks this with, with the added > KASAN instrumentation overhead. > > I'll try to dig into that tomorrow; I suspect/hope it's not necessary to > keep all of that mapped. > I have noticed that in the past, but I see how this delay at boot time is an issue. However, I don't think there is a huge cost involved in terms of memory footprint: AFAIK, the same PMD/PTE/kasan zero page are mapped over and over across the range. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
