kasan_map_early_shadow() on Xen

[Luis R. Rodriguez]

Andrey,

I believe that on Xen we should disable kasan, would like confirmation
from someone on xen-devel though. Here's the thing though -- if true
-- I'd like to do it *properly*, where *properly* means addressing a
bit of architecture. A simple Kconfig slap seems rather reactive. I'd
like to address a way to properly ensure we don't run into this and
other similar issues in the future. The CR4 shadow issue was another
recent example issue, also introduced via v4.0 [0]. We can't keep
doing this reactively.

Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be
selected on x86 when:

if X86_64 && SPARSEMEM_VMEMMAP

Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable
distributions to be able to have a single binary kernels and let the
rest be figured out, so we can't just disable SPARSEMEM_VMEMMAP for
Xen alone, we want to build Xen.. or part of Xen and perhaps keep
SPARSEMEM_VMEMMAP, and only later figure things out.

How do we do this cleanly and avoid future reactive measures? If the
answer is not upon us, I'd like to at least highlight the issue so
that in case we do come up with something its no surprise PVOPs is
falling short for that single binary pipe dream right now.

[0] https://lkml.org/lkml/2015/2/23/328

 Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/