Re: [PATCH v9 00/17] Kernel address sanitizer - runtime memory debugger.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]