Messages in this thread |  | | | Date | Sun, 28 May 2006 22:55:06 -0700 | | From | "Randy.Dunlap" <> | | Subject | Re: gcc 4.1.1 issues with 2.6.17-rc5 |
| |
On Mon, 29 May 2006 14:52:25 +1000 Con Kolivas wrote:
> On Monday 29 May 2006 02:32, Atsushi Nemoto wrote: > > On Sat, 27 May 2006 22:39:45 -0700, "Randy.Dunlap" <rdunlap@xenotime.net> > wrote: > > > > and a missed one: > > > > WARNING: drivers/usb/storage/usb-storage.o - Section mismatch: > > > > reference to .exit.text: from .smp_locks after '' (at offset 0x40) > > > > > > Yep, Jesper posted that one. > > > I also see it in ieee1394.o. > > > > > > So where does the .smp_locks section come from? > > > Is this just a section checker bug/issue? > > > > The .smp_locks section comes from LOCK_PREFIX on x86. I think the > > warnings was not shown previously just because the modpost did not > > check SHT_REL sections. > > > > Maybe we should fix the modpost to ignore it, but I'm not sure. Is it > > really safe to ignore? I'm not a x86 expert ... > > A "scary but harmless" comment from someone in the know would be nice.
Yes, I understand your remark. I have looked at the twisty maze of alternatives code, but Gerd (added to To:) is really who needs to reply IMO.
Based on my source code reading, it is just scary but harmless. alternatives_smp_unlock() and alternatives_smp_lock() are passed beginning and end addresses of text sections and they ignore (init/exit) code addresses that are outside of the text code range. One comment says: /* .text segment, needed to avoid patching init code ;) */ and the code does appear to implement that. I would make one small change to the code, however. In alternatives_smp_lock() and alternatives_smp_unlock(), change
if (*ptr > text_end) continue; to if (*ptr >= text_end) continue; because text_end is text_start + text_size, so text_end could be the beginning of the next section. However, in practice this may not matter. --- ~Randy - 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/
|  |