Re: code sections beyond .text skipped from alternatives_smp_module_add

From: Deep Debroy
Date: Wed Jun 22 2011 - 13:27:15 EST

On Wed, Jun 22, 2011 at 6:21 AM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
>> > Looking at the code, in module_finalize for x86, only .text seems to
>> > be getting picked for the patching of lock prefixes while other
>> > sections such as .exit.text or .init.text are not. Is there a reason
>> > we skip the other *.text code sections from the lock patches? Would
>> + Gerd Hoffmann who introduced the SMP patching code below back in Jan
>> 2006 as part of 2.6.15.
> Whoa, long time ago.
>> Any comments on why patching of smp_lock prefixes should be restricted
>> to .text and not other *.text code sections?
> It could be that at that time the .exit.text or .init.text did not exist.
> As in, the patching code just hasn't kept up. One way of checking that
> is just finding the ancient 2.6.15 code and seeing if there is any
> mention of those extra segments.

Thanks Konrad. One slight correction: after rechecking the kernel
sources, it appears the smp lock prefix code first made it's
appearance in the official trees during 2.6.18. In any case, going
back even to 2.6.16 sources, layout_sections in module.c specially
handled .init prefixed sections from the rest i.e. core sections.
Further, the module struct in include/module/linux.h seems to have had
members such as init_text_size which suggests atleast .init.text did
exit back then as well. While I didn't find any crumbs in the code
that point to the existence of a .exit.text (besides a function
pointer called exit which most likely ended up in the .exit.text), the
ELF headers for Centos 5.6 kernel objects (which uses the 2.6.18
kernel) typically have a .exit.text.

> Do you have a patch to fix this?

I can work on that. Just wanted to first make sure that there wasn't
any specific reason to avoid patching non .text sections.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at