2015-01-22 3:22 GMT+03:00 Sasha Levin <sasha.levin@oracle.com>:
> 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.
>

To be sure, that this is really false positives, could you try with
patches in attachment?
That should fix some bugs in several platform drivers.

> I suspect we'd need to mark that memory region somehow to prevent
> accesses to it from triggering warnings?
>
>
> Thanks,
> Sasha
>