From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932738Ab2DZAls (ORCPT ); Wed, 25 Apr 2012 20:41:48 -0400 Received: from mail-iy0-f174.google.com ([209.85.210.174]:51563 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932697Ab2DZAlq (ORCPT ); Wed, 25 Apr 2012 20:41:46 -0400 Date: Wed, 25 Apr 2012 19:41:32 -0500 From: Jonathan Nieder To: Greg KH Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, "David S. Miller" , Sam Ravnborg , Michal Marek Subject: Re: [ 30/62] Fix modpost failures in fedora 17 Message-ID: <20120426004131.GA8556@burratino> References: <20120424223305.GA7748@kroah.com> <20120424223244.539071890@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120424223244.539071890@linuxfoundation.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Greg KH wrote: > 3.3-stable review patch. [...] > commit e88aa7bbbe3046a125ea1936b16bb921cc9c6349 upstream. > > The symbol table on x86-64 starts to have entries that have names > like: > > _GLOBAL__sub_I_65535_0___mod_x86cpu_device_table [...] > FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18. I haven't tested this, but I suspect 3.0.y has the same problem --- v3.3-rc1~66^2~12 ("modpost: use a table rather than a giant if/else statement") just clarified the code a little and does not seem to have gone wrong. In other words, the conflict encountered when applying this to 3.0.y looks like a textual and not a meaningful one. Backport follows. -- >8 -- From: David Miller Date: Thu, 12 Apr 2012 14:37:30 -0400 commit e88aa7bbbe3046a125ea1936b16bb921cc9c6349 upstream. The symbol table on x86-64 starts to have entries that have names like: _GLOBAL__sub_I_65535_0___mod_x86cpu_device_table They are of type STT_FUNCTION and this one had a length of 18. This matched the device ID validation logic and it barfed because the length did not meet the device type's criteria. -------------------- FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18. Fix definition of struct x86cpu_device_id in mod_devicetable.h -------------------- These are some kind of compiler tool internal stuff being emitted and not something we want to inspect in modpost's device ID table validation code. So skip the symbol if it is not of type STT_OBJECT. Signed-off-by: David S. Miller Acked-by: Sam Ravnborg Signed-off-by: Michal Marek Signed-off-by: Jonathan Nieder --- Thanks, Jonathan scripts/mod/file2alias.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c index e26e2fb462d4..f210eae9bd7e 100644 --- a/scripts/mod/file2alias.c +++ b/scripts/mod/file2alias.c @@ -905,6 +905,10 @@ void handle_moddevtable(struct module *mod, struct elf_info *info, if (!sym->st_shndx || get_secindex(info, sym) >= info->num_sections) return; + /* We're looking for an object */ + if (ELF_ST_TYPE(sym->st_info) != STT_OBJECT) + return; + /* Handle all-NULL symbols allocated into .bss */ if (info->sechdrs[get_secindex(info, sym)].sh_type & SHT_NOBITS) { zeros = calloc(1, sym->st_size); -- 1.7.10