Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932116AbXBPDKu (ORCPT ); Thu, 15 Feb 2007 22:10:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932564AbXBPDKu (ORCPT ); Thu, 15 Feb 2007 22:10:50 -0500 Received: from smtp110.sbc.mail.mud.yahoo.com ([68.142.198.209]:26177 "HELO smtp110.sbc.mail.mud.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S932116AbXBPDKt (ORCPT ); Thu, 15 Feb 2007 22:10:49 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=5y2zrXFHlOtsUVp0tem7XRQUhgXooCAfFAO3+XCdudYLo7lfURJkzhrVakU3wnW7PNkipchjIMXzWV0lg2xLyb+tIE8IVfcJhsaiG1ZIYoEcoPTTa6XTU5Gu20pm0F5Mawl7f/ApC070NDwc4QlIRKRSL0RgPZdpSndXwhDzlqU= ; X-YMail-OSG: Rw5tB2MVM1mtIWYvJ5Uerux2K93xIuJKE1eFAiVoy.ddiGs3SCNqhOoN.ONQrZrzrYeoa2_RvD3ipmBZNHMt2TtXWKRWpLqZ47UhYMrweS8azqbIBh1jNDeONtwr7uveVGdFCfwTfCdwR8s- From: David Brownell To: Linux Kernel list Subject: [patch 2.6.20-git] remove modpost false warnings on ARM Date: Thu, 15 Feb 2007 19:10:45 -0800 User-Agent: KMail/1.7.1 Cc: Andi Kleen , Andrew Morton , ebiederm@xmission.com, kai@germaschewski.name, Russell King , sam@ravnborg.org, rusty@rustcorp.com.au References: <200701120831.37513.david-b@pacbell.net> In-Reply-To: <200701120831.37513.david-b@pacbell.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200702151910.46397.david-b@pacbell.net> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4375 Lines: 115 This patch stops "modpost" from issuing erroneous modpost warnings on ARM builds, which it's been doing since since maybe last summer. A canonical example would be driver method table entries: WARNING: - Section mismatch: reference to .exit.text:_remove from .data after '$d' (at offset 0x4) That "$d" symbol is generated by tools conformant with ARM ABI specs; in this case it's a symbol **in the middle of** a "_driver" struct. The erroneous warnings appear to be issued because "modpost" whitelists references from "_driver" data into init and exit sections ... but doesn't know should also include those "$d" mapping symbols, which are not otherwise associated with "_driver" symbols. This patch prevents the modpost symbol lookup code from ever returning those mapping symbols, so it will return a whitelisted symbol instead. Then things work as expected. Now to revert various code-bloating "fixes" that got merged because of this modpost bug.... Signed-off-by: David Brownell --- NOTE: this is a **RESEND** of a patch against 2.6.20-rc4 ... it's past time to merge a fix, please!! I don't see an entry for "modpost" in the MAINTAINERS file, so I'm trying to CC anyone who "git" says has been involved recently... However, it also seems to me that these modpost checks are wrong: ? * Lingering pointers that point into sections modprobe removes are ? ? *always* unsafe ... including probe() methods marked "__init" ? ? on hotpluggable busses. ?Trivial fix: ?use __devinit instead; ? ? or maybe platform_driver_probe(). ? * Lingering pointers that point into sections that aren't removed ? ? are *never* unsafe ... including this remove() method case, since ? ? module unloading is configured and the __exit stuff must stay. Whitelisting the former means not reporting potential oopsing cases; dangerous. ?Whereas even *checking* the latter is a waste of effort. Index: at91/scripts/mod/modpost.c =================================================================== --- at91.orig/scripts/mod/modpost.c 2007-02-15 18:20:15.000000000 -0800 +++ at91/scripts/mod/modpost.c 2007-02-15 18:22:50.000000000 -0800 @@ -686,6 +686,30 @@ static Elf_Sym *find_elf_symbol(struct e return NULL; } +static inline int is_arm_mapping_symbol(const char *str) +{ + return str[0] == '$' && strchr("atd", str[1]) + && (str[2] == '\0' || str[2] == '.'); +} + +/* + * If there's no name there, ignore it; likewise, ignore it if it's + * one of the magic symbols emitted used by current ARM tools. + * + * Otherwise if find_symbols_between() returns those symbols, they'll + * fail the whitelist tests and cause lots of false alarms ... fixable + * only by merging __exit and __init sections into __text, bloating + * the kernel (which is especially evil on embedded platforms). + */ +static inline int is_valid_name(struct elf_info *elf, Elf_Sym *sym) +{ + const char *name = elf->strtab + sym->st_name; + + if (!name || !strlen(name)) + return 0; + return !is_arm_mapping_symbol(name); +} + /* * Find symbols before or equal addr and after addr - in the section sec. * If we find two symbols with equal offset prefer one with a valid name. @@ -714,16 +738,15 @@ static void find_symbols_between(struct symsec = secstrings + elf->sechdrs[sym->st_shndx].sh_name; if (strcmp(symsec, sec) != 0) continue; + if (!is_valid_name(elf, sym)) + continue; if (sym->st_value <= addr) { if ((addr - sym->st_value) < beforediff) { beforediff = addr - sym->st_value; *before = sym; } else if ((addr - sym->st_value) == beforediff) { - /* equal offset, valid name? */ - const char *name = elf->strtab + sym->st_name; - if (name && strlen(name)) - *before = sym; + *before = sym; } } else @@ -733,10 +756,7 @@ static void find_symbols_between(struct *after = sym; } else if ((sym->st_value - addr) == afterdiff) { - /* equal offset, valid name? */ - const char *name = elf->strtab + sym->st_name; - if (name && strlen(name)) - *after = sym; + *after = sym; } } } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/