LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>, rusty@rustcorp.com.au
Subject: Re: [patch 2.6.20-rc4-git] remove modpost false warnings on ARM
Date: Fri, 12 Jan 2007 12:13:30 -0800 [thread overview]
Message-ID: <200701121213.31028.david-b@pacbell.net> (raw)
In-Reply-To: <20070112163852.GA16511@flint.arm.linux.org.uk>
On Friday 12 January 2007 8:38 am, Russell King wrote:
> A more correct test would be that found in kallsyms.c:
Good point. Updated patch appended.
- Dave
=============== CUT HERE
This patch stops "modpost" from issuing erroneous modpost warnings on ARM
builds, which it's been doing simce since maybe last summer. A canonical
example would be driver method table entries:
WARNING: <path> - Section mismatch: reference to .exit.text:<name>_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 relocation in the middle of a "<name>_driver" struct.
The erroneous warnings appear to be issued because "modpost" whitelists
references from "<name>_driver" data into init and exit sections ... but
does NOT whitelist them from "$d" (and can't).
This patch prevents the modpost symbol lookup code from ever returning
those symbols, so it will return a whitelisted symbol instead.
Now to revert various code-bloating "fixes" that got merged because of
this modpost bug....
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
Likely this patch can be improved on, but there's another issue.
It 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 2006-12-15 10:08:57.000000000 -0800
+++ at91/scripts/mod/modpost.c 2007-01-12 12:09:29.000000000 -0800
@@ -655,6 +655,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 shrinking __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.
@@ -683,16 +707,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
@@ -702,10 +725,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;
}
}
}
next prev parent reply other threads:[~2007-01-12 20:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-12 16:31 David Brownell
2007-01-12 16:38 ` Russell King
2007-01-12 20:13 ` David Brownell [this message]
2007-02-16 3:10 ` [patch 2.6.20-git] " David Brownell
2007-02-16 3:28 ` Rusty Russell
2007-02-16 8:26 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200701121213.31028.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=rusty@rustcorp.com.au \
--subject='Re: [patch 2.6.20-rc4-git] remove modpost false warnings on ARM' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).