On 01/21/2015 11:51 AM, Andrey Ryabinin wrote: > Changes since v8: > - Fixed unpoisoned redzones for not-allocated-yet object > in newly allocated slab page. (from Dmitry C.) > > - Some minor non-function cleanups in kasan internals. > > - Added ack from Catalin > > - Added stack instrumentation. With this we could detect > out of bounds accesses in stack variables. (patch 12) > > - Added globals instrumentation - catching out of bounds in > global varibles. (patches 13-17) > > - Shadow moved out from vmalloc into hole between vmemmap > and %esp fixup stacks. For globals instrumentation > we will need shadow backing modules addresses. > So we need some sort of a shadow memory allocator > (something like vmmemap_populate() function, except > that it should be available after boot). > > __vmalloc_node_range() suits that purpose, except that > it can't be used for allocating for shadow in vmalloc > area because shadow in vmalloc is already 'allocated' > to protect us from other vmalloc users. So we need > 16TB of unused addresses. And we have big enough hole > between vmemmap and %esp fixup stacks. So I moved shadow > there. I'm not sure which new addition caused it, but I'm getting tons of false positives from platform drivers trying to access memory they don't "own" - because they expect to find hardware there. I suspect we'd need to mark that memory region somehow to prevent accesses to it from triggering warnings? Thanks, Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>