From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762913AbbA3Ro1 (ORCPT ); Fri, 30 Jan 2015 12:44:27 -0500 Received: from mailout3.w1.samsung.com ([210.118.77.13]:63028 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752723AbbA3Ro0 (ORCPT ); Fri, 30 Jan 2015 12:44:26 -0500 X-AuditID: cbfec7f5-b7fc86d0000066b7-a5-54cbc264d2de Message-id: <54CBC2EE.6050709@samsung.com> Date: Fri, 30 Jan 2015 20:44:14 +0300 From: Andrey Ryabinin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-version: 1.0 To: Andrew Morton Cc: linux-kernel@vger.kernel.org, Dmitry Vyukov , Konstantin Serebryany , Dmitry Chernenkov , Andrey Konovalov , Yuri Gribov , Konstantin Khlebnikov , Sasha Levin , Christoph Lameter , Joonsoo Kim , Dave Hansen , Andi Kleen , x86@kernel.org, linux-mm@kvack.org, Rusty Russell Subject: Re: [PATCH v10 16/17] module: fix types of device tables aliases References: <1404905415-9046-1-git-send-email-a.ryabinin@samsung.com> <1422544321-24232-1-git-send-email-a.ryabinin@samsung.com> <1422544321-24232-17-git-send-email-a.ryabinin@samsung.com> <20150129151314.8b3951ff70d67cde9223f927@linux-foundation.org> In-reply-to: <20150129151314.8b3951ff70d67cde9223f927@linux-foundation.org> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42I5/e/4Fd2UQ6dDDA7N1bL4vXcmq8Wc9WvY LI5c+85ucf3bG0aLTy8fMFo8f/iQ3WLCwzZ2i5XdzWwW25+9ZbJY2fmA1eLyrjlsFvfW/Ge1 uDntAovF4iO3mS3ePZvMbPFjw2NWBwGP+Ts/MnrsnHWX3WPBplKPxXteMnlsWtXJ5rHp0yR2 j663V5g8Tsz4zeLx5Mp0Jo+PT2+xeKzYcILZ4/MmuQCeKC6blNSczLLUIn27BK6MB+f0CrYL VBycz9fAuIe3i5GTQ0LARKJ7yzZGCFtM4sK99WxdjFwcQgJLGSV+vtjGBOE0M0ls+dDH0sXI wcEroCWx7aI8SAOLgKrE9YYFLCA2m4CexL9Z29lAbFGBCIkPq76C2bwCghI/Jt8DqxER0JVY 9XwXM4jNLDCNRaKjLQZkpLCAp8SqIywQqxqZJF4t+s0EUsMp4C3x+UgvI0gNM9D8+xe1IFrl JTavecs8gVFgFpINsxCqZiGpWsDIvIpRNLU0uaA4KT3XSK84Mbe4NC9dLzk/dxMjJPa+7mBc eszqEKMAB6MSD++NxNMhQqyJZcWVuYcYJTiYlUR4p0wCCvGmJFZWpRblxxeV5qQWH2Jk4uCU amCclvJ/X9Paz2zCskw21S/Vc+VNH3d3mN0R6pf9fjv86eYzx1h0Ls6ovRazyzHIs6lWSfDb 5VcLV6TX/mTYuVL40oLwpPw3cw/OKr7ds9FsjrPAjS1vcmr2yp9y/iTbabD06WZj/b9f78+8 a133UMTRy+4a/7nNNx+c0r7l3nVM1C0smXuW7F0GJZbijERDLeai4kQAGUVPrJsCAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/30/2015 02:13 AM, Andrew Morton wrote: > On Thu, 29 Jan 2015 18:12:00 +0300 Andrey Ryabinin 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. > For every global variable compiler calls __asan_register_globals() passing information about global variable (address, size, size with redzone, name ...) __asan_register_globals() poison symbols redzone so we could detect out of bounds access. If we have alias to symbol __asan_register_globals() will be called as for symbol so for alias. Compiler determines size of variable by its type. Alias and symbol have the same address, but if alias have the wrong size we will poison part of memory that actually belongs to the symbol, not the redzone. >> --- 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? > Lack of const is unintentional, but this should be harmless because this is just an alias to device table. I'll add const back.