[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150129151314.8b3951ff70d67cde9223f927@linux-foundation.org>
Date: Thu, 29 Jan 2015 15:13:14 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Andrey Ryabinin <a.ryabinin@...sung.com>
Cc: linux-kernel@...r.kernel.org, Dmitry Vyukov <dvyukov@...gle.com>,
Konstantin Serebryany <kcc@...gle.com>,
Dmitry Chernenkov <dmitryc@...gle.com>,
Andrey Konovalov <adech.fo@...il.com>,
Yuri Gribov <tetra2005@...il.com>,
Konstantin Khlebnikov <koct9i@...il.com>,
Sasha Levin <sasha.levin@...cle.com>,
Christoph Lameter <cl@...ux.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Dave Hansen <dave.hansen@...el.com>,
Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
linux-mm@...ck.org, Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH v10 16/17] module: fix types of device tables aliases
On Thu, 29 Jan 2015 18:12:00 +0300 Andrey Ryabinin <a.ryabinin@...sung.com> wrote:
> MODULE_DEVICE_TABLE() macro used to create aliases to device tables.
> Normally alias should have the same type as aliased symbol.
>
> Device tables are arrays, so they have 'struct type##_device_id[x]'
> types. Alias created by MODULE_DEVICE_TABLE() will have non-array type -
> 'struct type##_device_id'.
>
> This inconsistency confuses compiler, it could make a wrong
> assumption about variable's size which leads KASan to
> produce a false positive report about out of bounds access.
The changelog describes the problem but doesn't describe how the patch
addresses the problem. Some more details would be useful.
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -135,7 +135,7 @@ void trim_init_extable(struct module *m);
> #ifdef MODULE
> /* Creates an alias so file2alias.c can find device table. */
> #define MODULE_DEVICE_TABLE(type, name) \
> - extern const struct type##_device_id __mod_##type##__##name##_device_table \
> +extern typeof(name) __mod_##type##__##name##_device_table \
> __attribute__ ((unused, alias(__stringify(name))))
We lost the const? If that's deliberate then why? What are the
implications? Do the device tables now go into rw memory?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists