On 11/08/2016 10:03 PM, Mark Rutland wrote: > Hi, > > I see a while back [1] there was a discussion of what to do about KASAN > and vmapped stacks, but it doesn't look like that was solved, judging by > the vmapped stacks pull [2] for v4.9. > > I wondered whether anyone had looked at that since? >
Sadly, but I didn't have much time for this yet, so it's in an initial state. > I have an additional reason to want to dynamically allocate the vmalloc > area shadow: it turns out that KASAN currently interacts rather poorly > with the arm64 ptdump code. > > When KASAN is selected, we allocate shadow for the whole vmalloc area, > using common zero pte, pmd, pud tables. Walking over these in the ptdump > code takes a *very* long time (I've seen up to 15 minutes with > KASAN_OUTLINE enabled). For DEBUG_WX [3], this means boot hangs for that > long, too. > I didn't look at any code, but we probably could can remember last visited pgd and skip next pgd if it's the same as previous. Alternatively - just skip kasan_zero_p*d in ptdump walker. > If I don't allocate vmalloc shadow (and remove the apparently pointlesss > shadow of the shadow area), and only allocate shadow for the image, > fixmap, vmemmap and so on, that delay gets cut to a few seconds, which > is tolerable for a debug configuration... > > ... however, things blow up when the kernel touches vmalloc'd memory for > the first time, as we don't install shadow for that dynamically. > > Thanks, > Mark. > > [1] > https://lkml.kernel.org/r/CALCETrWucrYp+yq8RHSDqf93xtg793duByirurzJbLRhrz=t...@mail.gmail.com > [2] https://lkml.kernel.org/r/20161003092940.ga...@gmail.com > [3] > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/464191.html >
