Message ID | CACRpkdYbbtJFcAugz6rBMHNihz3pnY9O4mVzwLsFY_CjBb9K=A@mail.gmail.com |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL] KASan for Arm, v12 | expand |
Hi Linus, On 7/20/20 2:40 AM, Linus Walleij wrote: > Hi Russell, > > please consider pulling in these changes to bring KASan > support to Arm. > > Certainly there will be bugs like with all new code, but I > think we are in such good shape that in-tree development > is the best way to go from now so that interested people > can test this out. > > I have tested it extensively on classic MMUs from ARMv4 > to ARMv7 and also on LPAE. But now I need the help of > linux-next and the broader community to iron out any > remaining corner cases. > > I will of course respect a "no" but then some direction would > be sweet. I could for example ask linux-next to include > this branch separately from v5.9-rc1 or so to get some > coverage. I am still seeing crashes similar to the ones reported before with this pull request, but maybe we can get it merged and address it later on since this has been waiting forever to be merged.
On Mon, Jul 20, 2020 at 8:01 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > I am still seeing crashes similar to the ones reported before with this > pull request, but maybe we can get it merged and address it later on > since this has been waiting forever to be merged. We definitely need it fixed, my current working assumption is that at least some of it is a result of the kernel growing big as a result of enabling KASan. Can you try to inspect the early memblock.memory.regions[0] mapping debug prints as I pointed out here: https://lore.kernel.org/linux-arm-kernel/CACRpkdYoMiVtnQEUiXy3Ezf3Z0dEQSVyA-9emDeewRKwonoUHQ@mail.gmail.com/#t On the APQ8060 it seems the first memblock does not fit the kernel+attached devicetree and the devicetree ends up in the unmapped memory that is cleared by prepare_page_table() but the Broadcom problem may be another one altogether. Yours, Linus Walleij