Re: 2.6.17-mm2

Andrew Morton
2006-06-25T10:26:24Z

On Sun, 25 Jun 2006 10:51:55 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> > >
> >
> > My guess would be that cpufreq_register_driver() is being called after it
> > has been unloaded from the kernel.
> >
> > Do you have CONFIG_CPU_FREQ=y?
>
> Yes.
>
> > Does removal of the __cpuinit from cpufreq_register_driver() fix it (or
> > move the crash elsewhere)?
>
> Yes (makes it go away).

Well it would appear that the new __cpuinit on cpufreq_register_driver() is
causing the problem, although I'm surprised that you don't have
CONFIG_HOTPLUG_CPU set, if it's a swsusp requirement??

> > Do you get any section mismatch warnings at build-time?
>
> Only this one:
> WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0x1164) and 'acpi_processor_power_exit'
>

That's a false-positive - the code in there is, I think, OK:

static int first_run;

...

if (!first_run) {
dmi_check_system(processor_power_dmi_table);
...
first_run++;
}

The warning is about the reference to processor_power_dmi_table. But as
long as the first call to acpi_processor_power_init() happens prior to
free_initmem(), we won't actually try to touch the unloaded memory.

It's fragile and nasty though - it'd be nice to sort it out.

Anyway. It's regrettable that the new section-checking code didn't
complain about the bug. It looks like this is because the call to
cpufreq_register_driver() happened at modprobe-time, and we don't check for
that. Which is rather bad.

Sam, would it be possible to check for references from modules into
statically-linked __init code? It's always wrong...

Rusty/Randy/whoever looks after modules: it also seems wrong that it's
possible to load a module which refers to now-unloaded symbols. In fact,
it's surprising - sorry if I'm misinterpreting this. If I'm not, it should
be pretty easy to barf if a module is trying to get at symbols which lie
between __init_begin and __init_end?

Chandra, this is scary stuff. I'll tempdrop those patches until we can get
the kbuild/modprobe infrastructure in place which will allow us to fully
check your sectioning changes at depmod/modprobe time.

<thinks>

Actually, it should still be possible to do this - simply do a `make
allyesconfig; make' with the patches unapplied, then do it with the patches
applied and then look for the differences in the warnings.

Need to do this with various combinations of CONFIG_MODULES,
CONFIG_HOTPLUG, CONFIG_HOTPLUG_CPU, CONFIG_MEMORY_HOTPLUG,
CONFIG_ACPI_HOTPLUG_MEMORY and CONFIG_ACPI_HOTPLUG_MEMORY_MODULE.