Hi,
I noticed kobject_uevent was failing to init on my box. It looks like
both netlink and kobject_uevent are marked core_initcall and we may not
do them in the correct order.
I guess the recent changes to netlink caused this:
http://linux.bkbits.net:8080/linux-2.5/cset@41896b1dIiNgXpwhgimeurIqPpofbw?nav=index.html|ChangeSet@-2d
Anton
On Fri, Nov 05, 2004 at 02:43:17AM +1100, Anton Blanchard wrote:
>
> Hi,
>
> I noticed kobject_uevent was failing to init on my box. It looks like
> both netlink and kobject_uevent are marked core_initcall and we may not
> do them in the correct order.
>
> I guess the recent changes to netlink caused this:
>
> http://linux.bkbits.net:8080/linux-2.5/cset@41896b1dIiNgXpwhgimeurIqPpofbw?nav=index.html|ChangeSet@-2d
Hm, I don't think that patch caused the reversal, it seems like we've
always linked this in the opposite order as my System.map before this
patch went in shows:
c04b016c t __initcall_kobject_uevent_init
c04b0170 t __initcall_netlink_proto_init
So, Robert and Kay, any thoughts as to how this has ever worked at boot
time in the past?
thanks,
greg k-h
On Thu, 2004-11-04 at 10:05 -0800, Greg KH wrote:
> So, Robert and Kay, any thoughts as to how this has ever worked at boot
> time in the past?
Weird. I don't have a clue, but clearly it did work.
Similar thing here:
c04b60cc t __initcall_kobject_uevent_init
c04b60d0 t __initcall_netlink_proto_init
Dunno why it ever worked, but it at least used to.
Robert Love
Greg!
Looks like kobject_uevent_init is executed before netlink_proto_init and
consequently always fails. Not cool.
Attached patch switches the initialization over from core_initcall (init
level 1) to postcore_initcall (init level 2). Netlink's initialization
is done in core_initcall, so this should fix the problem. We should be
fine waiting until postcore_initcall.
Also a couple white space changes mixed in, because I am anal.
Robert Love
fix kobject_uevent init ordering
lib/kobject_uevent.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff -urN linux-2.6.10-rc1/lib/kobject_uevent.c linux/lib/kobject_uevent.c
--- linux-2.6.10-rc1/lib/kobject_uevent.c 2004-10-25 16:17:09.000000000 -0400
+++ linux/lib/kobject_uevent.c 2004-11-04 13:20:32.731836880 -0500
@@ -54,7 +54,7 @@
* gfp_mask:
*/
static int send_uevent(const char *signal, const char *obj, const void *buf,
- int buflen, int gfp_mask)
+ int buflen, int gfp_mask)
{
struct sk_buff *skb;
char *pos;
@@ -105,9 +105,8 @@
sprintf(attrpath, "%s/%s", path, attr->name);
rc = send_uevent(signal, attrpath, NULL, 0, gfp_mask);
kfree(attrpath);
- } else {
+ } else
rc = send_uevent(signal, path, NULL, 0, gfp_mask);
- }
exit:
kfree(path);
@@ -133,7 +132,6 @@
{
return do_kobject_uevent(kobj, action, attr, GFP_ATOMIC);
}
-
EXPORT_SYMBOL_GPL(kobject_uevent_atomic);
static int __init kobject_uevent_init(void)
@@ -149,7 +147,7 @@
return 0;
}
-core_initcall(kobject_uevent_init);
+postcore_initcall(kobject_uevent_init);
#else
static inline int send_uevent(const char *signal, const char *obj,
On Thu, 2004-11-04 at 13:27 -0500, Robert Love wrote:
> Greg!
>
> Looks like kobject_uevent_init is executed before netlink_proto_init and
> consequently always fails. Not cool.
>
> Attached patch switches the initialization over from core_initcall (init
> level 1) to postcore_initcall (init level 2). Netlink's initialization
> is done in core_initcall, so this should fix the problem. We should be
> fine waiting until postcore_initcall.
Looks good. Don't know why this never failed on any kernel I used.
Does the failure happens on a SMP kernel?
> static int send_uevent(const char *signal, const char *obj, const void *buf,
> - int buflen, int gfp_mask)
> + int buflen, int gfp_mask)
^^^^^^^^^^
This has changed and will not apply.
Best,
Kay
On Thu, 2004-11-04 at 13:27 -0500, Robert Love wrote:
> Looks like kobject_uevent_init is executed before netlink_proto_init and
> consequently always fails. Not cool.
>
> Attached patch switches the initialization over from core_initcall (init
> level 1) to postcore_initcall (init level 2). Netlink's initialization
> is done in core_initcall, so this should fix the problem. We should be
> fine waiting until postcore_initcall.
>
> Also a couple white space changes mixed in, because I am anal.
Greg, sir, here is a patch rediff'ed off current BK.
Robert Love
fix init call ordering for kobject_uevent
Signed-Off-By: Robert Love <[email protected]>
lib/kobject_uevent.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff -urN linux-2.6.10-rc1-bk14/lib/kobject_uevent.c linux/lib/kobject_uevent.c
--- linux-2.6.10-rc1-bk14/lib/kobject_uevent.c 2004-11-04 14:20:10.431943792 -0500
+++ linux/lib/kobject_uevent.c 2004-11-04 14:26:54.056583520 -0500
@@ -120,9 +120,8 @@
sprintf(attrpath, "%s/%s", path, attr->name);
rc = send_uevent(signal, attrpath, NULL, gfp_mask);
kfree(attrpath);
- } else {
+ } else
rc = send_uevent(signal, path, NULL, gfp_mask);
- }
exit:
kfree(path);
@@ -148,7 +147,6 @@
{
return do_kobject_uevent(kobj, action, attr, GFP_ATOMIC);
}
-
EXPORT_SYMBOL_GPL(kobject_uevent_atomic);
static int __init kobject_uevent_init(void)
@@ -164,7 +162,7 @@
return 0;
}
-core_initcall(kobject_uevent_init);
+postcore_initcall(kobject_uevent_init);
#else
static inline int send_uevent(const char *signal, const char *obj,
On Thu, 04 Nov 2004 13:13:53 -0500
Robert Love <[email protected]> wrote:
> On Thu, 2004-11-04 at 10:05 -0800, Greg KH wrote:
>
> > So, Robert and Kay, any thoughts as to how this has ever worked at boot
> > time in the past?
>
> Weird. I don't have a clue, but clearly it did work.
It might have really failing recently because nl_table in
net/netlink/af_netlink.c has become dynamically allocated
memory setup by netlink_proto_init().
On Thu, Nov 04, 2004 at 02:28:52PM -0500, Robert Love wrote:
> On Thu, 2004-11-04 at 13:27 -0500, Robert Love wrote:
>
> > Looks like kobject_uevent_init is executed before netlink_proto_init and
> > consequently always fails. Not cool.
> >
> > Attached patch switches the initialization over from core_initcall (init
> > level 1) to postcore_initcall (init level 2). Netlink's initialization
> > is done in core_initcall, so this should fix the problem. We should be
> > fine waiting until postcore_initcall.
> >
> > Also a couple white space changes mixed in, because I am anal.
>
> Greg, sir, here is a patch rediff'ed off current BK.
"Sir"? Geesh, I'm not that old looking am I? :)
applied, thanks.
greg k-h
On Thu, 2004-11-04 at 20:04 +0100, Kay Sievers wrote:
Hey, Kay.
> Looks good. Don't know why this never failed on any kernel I used.
> Does the failure happens on a SMP kernel?
In the original patches, I had the initialization done as module_init(),
which is done very late in the init ordering. At some point it was
changed to core_initcall(), which is the very first things initialized.
> > static int send_uevent(const char *signal, const char *obj, const void *buf,
> > - int buflen, int gfp_mask)
> > + int buflen, int gfp_mask)
Ugh. I am sure Greg can sort it out, but following patch has just the
init call ordering change.
Robert Love
fix kobject_uevent init ordering
lib/kobject_uevent.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff -urN linux-2.6.10-rc1/lib/kobject_uevent.c linux/lib/kobject_uevent.c
--- linux-2.6.10-rc1/lib/kobject_uevent.c 2004-10-25 16:17:09.000000000 -0400
+++ linux/lib/kobject_uevent.c 2004-11-04 13:20:32.731836880 -0500
@@ -149,7 +147,7 @@
return 0;
}
-core_initcall(kobject_uevent_init);
+postcore_initcall(kobject_uevent_init);
#else
static inline int send_uevent(const char *signal, const char *obj,