lkml.org 
[lkml]   [2015]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patches in this message
/
Date
SubjectRe: [PATCH v9 00/17] Kernel address sanitizer - runtime memory debugger.
From
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
>
diff --git a/drivers/video/backlight/da9052_bl.c b/drivers/video/backlight/da9052_bl.c
index d4bd74bd..b1943e7 100644
--- a/drivers/video/backlight/da9052_bl.c
+++ b/drivers/video/backlight/da9052_bl.c
@@ -165,6 +165,7 @@ static struct platform_device_id da9052_wled_ids[] = {
.name = "da9052-wled3",
.driver_data = DA9052_TYPE_WLED3,
},
+ { },
};

static struct platform_driver da9052_wled_driver = {diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index c6e6171..ca29c12 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -583,6 +583,7 @@ bool ccp_queues_suspended(struct ccp_device *ccp)
#ifdef CONFIG_X86
static const struct x86_cpu_id ccp_support[] = {
{ X86_VENDOR_AMD, 22, },
+ { },
};
#endif
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index b5e7c46..89ac1d5 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -832,6 +832,7 @@ static SIMPLE_DEV_PM_OPS(s5m_rtc_pm_ops, s5m_rtc_suspend, s5m_rtc_resume);
static const struct platform_device_id s5m_rtc_id[] = {
{ "s5m-rtc", S5M8767X },
{ "s2mps14-rtc", S2MPS14X },
+ { },
};

static struct platform_driver s5m_rtc_driver = {
\
 
 \ /
  Last update: 2015-01-22 06:41    [W:0.249 / U:5.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site