[Top] [All Lists]

[xfs-masters] Re: Linux 2.6.17-rc2 - notifier chain problem?

To: sekharan@xxxxxxxxxx
Subject: [xfs-masters] Re: Linux 2.6.17-rc2 - notifier chain problem?
From: Andrew Morton <akpm@xxxxxxxx>
Date: Mon, 24 Apr 2006 15:03:14 -0700
Cc: herbert@xxxxxxxxxxxx, torvalds@xxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx, xfs-masters@xxxxxxxxxxx, stern@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1145913967.1400.59.camel@linuxchandra>
References: <Pine.LNX.4.64.0604182013560.3701@xxxxxxxxxxx> <20060421110140.GC14841@xxxxxxxxxxxxxxxxx> <1145655097.15389.12.camel@linuxchandra> <20060422005851.GA22917@xxxxxxxxxxxxxxxxx> <1145913967.1400.59.camel@linuxchandra>
Reply-to: xfs-masters@xxxxxxxxxxx
Sender: xfs-masters-bounce@xxxxxxxxxxx
Chandra Seetharaman <sekharan@xxxxxxxxxx> wrote:
> Thanks for the steps. With that i was able to reproduce the problem and
> i found the bug.
> While i go ahead and generate the patch, i wanted to hear if my
> conclusion is correct.
> The problem is due to the fact that most notifier registrations
> incorrectly use __devinitdata to define the callback structure, as in:
> static struct notifier_block __devinitdata hrtimers_nb = {
>         .notifier_call = hrtimer_cpu_notify,
> };
> devinitdata'd  data is not _expected to be available_ after the
> initialization(unless CONFIG_HOTPLUG is defined).
> I do not know how it was working until now :), anybody has a theory that
> can explain it (or my conclusion is wrong) ?

That sounds right.  There are several __devinitdata notifier_blocks in the
tree - please be sure to check them all.

btw, it'd be pretty trivial to add runtime checking for this sort of thing:

int addr_in_init_section(void *addr)
        return addr >= __init_begin && addr < __init_end;

(need to add __init_end to vmlinux.lds.S)

then we could use that to check various things in various places...

<Prev in Thread] Current Thread [Next in Thread>