public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* borked sysfs system devices in 2.5.72
@ 2003-06-17 22:12 Dave Hansen
  2003-06-17 22:26 ` Patrick Mochel
  0 siblings, 1 reply; 5+ messages in thread
From: Dave Hansen @ 2003-06-17 22:12 UTC (permalink / raw)
  To: mochel; +Cc: Linux Kernel Mailing List

The per-node numa meminfo files in 2.5.72 are broken, the only display
node0's information.  The devices are being properly registered:
Registering sys device 'node0':c0423844 id:0 kobj:c042384c
Registering sys device 'node1':c0423888 id:1 kobj:c0423890
Registering sys device 'node2':c04238cc id:2 kobj:c04238d4
Registering sys device 'node3':c0423910 id:3 kobj:c0423918

When I look at the 4 nodes files with:
"cat /sys/devices/system/node/*/meminfo", I printed out some
information:
subsys_attr_show(kobj: c042384c, attr: c033ea30, page: e76ba000)
subsys_attr_show(kobj: c0423890, attr: c033ea30, page: e76ba000)
subsys_attr_show(kobj: c04238d4, attr: c033ea30, page: e76ba000)
subsys_attr_show(kobj: c0423918, attr: c033ea30, page: e76ba000)

As you can see, the kobj is the one which belongs to the sys device, yet
you do a to_subsys() on it.  Why?
struct subsystem * s = to_subsys(kobj);

I'm getting a 0 as the node ID out of pure dumb luck.  Is the NUMA code
broken or is sysfs?

-- 
Dave Hansen
haveblue@us.ibm.com


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: borked sysfs system devices in 2.5.72
  2003-06-17 22:12 borked sysfs system devices in 2.5.72 Dave Hansen
@ 2003-06-17 22:26 ` Patrick Mochel
  2003-06-17 22:31   ` Dave Hansen
  0 siblings, 1 reply; 5+ messages in thread
From: Patrick Mochel @ 2003-06-17 22:26 UTC (permalink / raw)
  To: Dave Hansen; +Cc: Linux Kernel Mailing List


On 17 Jun 2003, Dave Hansen wrote:

> The per-node numa meminfo files in 2.5.72 are broken, the only display
> node0's information.  The devices are being properly registered:
> Registering sys device 'node0':c0423844 id:0 kobj:c042384c
> Registering sys device 'node1':c0423888 id:1 kobj:c0423890
> Registering sys device 'node2':c04238cc id:2 kobj:c04238d4
> Registering sys device 'node3':c0423910 id:3 kobj:c0423918
> 
> When I look at the 4 nodes files with:
> "cat /sys/devices/system/node/*/meminfo", I printed out some
> information:
> subsys_attr_show(kobj: c042384c, attr: c033ea30, page: e76ba000)
> subsys_attr_show(kobj: c0423890, attr: c033ea30, page: e76ba000)
> subsys_attr_show(kobj: c04238d4, attr: c033ea30, page: e76ba000)
> subsys_attr_show(kobj: c0423918, attr: c033ea30, page: e76ba000)
> 
> As you can see, the kobj is the one which belongs to the sys device, yet
> you do a to_subsys() on it.  Why?
> struct subsystem * s = to_subsys(kobj);

Where exactly is that happening? 

> I'm getting a 0 as the node ID out of pure dumb luck.  Is the NUMA code
> broken or is sysfs?

It's taking the ID from the system device of the node that's passed to 
->show(). That is set in register_node(), so I'm not sure how they could 
get out of sync, unless I'm missing something obvious. 

BTW, I did request that the NUMA topology people take a look at these 
patches when I sent them a couple of weeks ago, so as to avoid this. :) 



	-pat


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: borked sysfs system devices in 2.5.72
  2003-06-17 22:26 ` Patrick Mochel
@ 2003-06-17 22:31   ` Dave Hansen
  2003-06-17 22:54     ` Patrick Mochel
  0 siblings, 1 reply; 5+ messages in thread
From: Dave Hansen @ 2003-06-17 22:31 UTC (permalink / raw)
  To: Patrick Mochel; +Cc: Linux Kernel Mailing List, Matthew Dobson

On Tue, 2003-06-17 at 15:26, Patrick Mochel wrote:
> On 17 Jun 2003, Dave Hansen wrote:
> 
> > The per-node numa meminfo files in 2.5.72 are broken, the only display
> > node0's information.  The devices are being properly registered:
> > Registering sys device 'node0':c0423844 id:0 kobj:c042384c
> > Registering sys device 'node1':c0423888 id:1 kobj:c0423890
> > Registering sys device 'node2':c04238cc id:2 kobj:c04238d4
> > Registering sys device 'node3':c0423910 id:3 kobj:c0423918
> > 
> > When I look at the 4 nodes files with:
> > "cat /sys/devices/system/node/*/meminfo", I printed out some
> > information:
> > subsys_attr_show(kobj: c042384c, attr: c033ea30, page: e76ba000)
> > subsys_attr_show(kobj: c0423890, attr: c033ea30, page: e76ba000)
> > subsys_attr_show(kobj: c04238d4, attr: c033ea30, page: e76ba000)
> > subsys_attr_show(kobj: c0423918, attr: c033ea30, page: e76ba000)
> > 
> > As you can see, the kobj is the one which belongs to the sys device, yet
> > you do a to_subsys() on it.  Why?
> > struct subsystem * s = to_subsys(kobj);
> 
> Where exactly is that happening? 

Look in subsys_attr_show().  It is being passed a kobject, which is a
member of a "struct sys_device".  We can tell this because I printed out
the address of the sys device in sys_device_register().  A to_subsys()
is being performed on that object, which is wrong, because the kobject
is not a member of a "struct subsystem".

> > I'm getting a 0 as the node ID out of pure dumb luck.  Is the NUMA code
> > broken or is sysfs?
> 
> It's taking the ID from the system device of the node that's passed to 
> ->show(). That is set in register_node(), so I'm not sure how they could 
> get out of sync, unless I'm missing something obvious. 

They're not out of sync, it's getting garbage because of the bogus
to_subsys().

> BTW, I did request that the NUMA topology people take a look at these 
> patches when I sent them a couple of weeks ago, so as to avoid this. :) 

I'll cc him to make him feel bad :)

-- 
Dave Hansen
haveblue@us.ibm.com


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: borked sysfs system devices in 2.5.72
  2003-06-17 22:31   ` Dave Hansen
@ 2003-06-17 22:54     ` Patrick Mochel
  2003-06-17 22:58       ` Dave Hansen
  0 siblings, 1 reply; 5+ messages in thread
From: Patrick Mochel @ 2003-06-17 22:54 UTC (permalink / raw)
  To: Dave Hansen; +Cc: Linux Kernel Mailing List, Matthew Dobson


> Look in subsys_attr_show().  It is being passed a kobject, which is a
> member of a "struct sys_device".  We can tell this because I printed out
> the address of the sys device in sys_device_register().  A to_subsys()
> is being performed on that object, which is wrong, because the kobject
> is not a member of a "struct subsystem".

My question was how the hell it was getting there in the first place, and 
I see that the type of the object isn't getting set properly, so it 
defaults to treat it as a struct subsystem. 

Could you please try the following patch, and let me know if it works? 

Thanks,


	-pat

===== drivers/base/sys.c 1.25 vs edited =====
--- 1.25/drivers/base/sys.c	Mon Jun 16 10:07:04 2003
+++ edited/drivers/base/sys.c	Tue Jun 17 15:50:48 2003
@@ -170,6 +172,9 @@
 
 	/* Make sure the kset is set */
 	sysdev->kobj.kset = &cls->kset;
+
+	/* But make sure we point to the right type for sysfs translation */
+	sysdev->kobj.ktype = &ktype_sysdev;
 
 	/* set the kobject name */
 	snprintf(sysdev->kobj.name,KOBJ_NAME_LEN,"%s%d",


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: borked sysfs system devices in 2.5.72
  2003-06-17 22:54     ` Patrick Mochel
@ 2003-06-17 22:58       ` Dave Hansen
  0 siblings, 0 replies; 5+ messages in thread
From: Dave Hansen @ 2003-06-17 22:58 UTC (permalink / raw)
  To: Patrick Mochel; +Cc: Linux Kernel Mailing List, Matthew Dobson

On Tue, 2003-06-17 at 15:54, Patrick Mochel wrote:
> > Look in subsys_attr_show().  It is being passed a kobject, which is a
> > member of a "struct sys_device".  We can tell this because I printed out
> > the address of the sys device in sys_device_register().  A to_subsys()
> > is being performed on that object, which is wrong, because the kobject
> > is not a member of a "struct subsystem".
> 
> My question was how the hell it was getting there in the first place, and 
> I see that the type of the object isn't getting set properly, so it 
> defaults to treat it as a struct subsystem. 

Stack dump from si_meminfo_node():
Call Trace:
 [<c0133f39>] si_meminfo_node+0x4d/0x54
 [<c02029ac>] node_read_meminfo+0x1c/0x80
 [<c013385a>] __alloc_pages+0x82/0x2b4
 [<c011c8fb>] release_console_sem+0x9b/0xa4
 [<c0175ead>] subsys_attr_show+0x1d/0x28
 [<c0175f7a>] fill_read_buffer+0x96/0xb4
 [<c01ebf5e>] opost_block+0x18e/0x19c
 [<c01eed92>] pty_write+0x156/0x168
 [<c0154d8c>] do_lookup+0x18/0x8c
 [<c0151a2f>] cp_new_stat64+0xe7/0x100
 [<c017604b>] sysfs_read_file+0x1b/0x3c
 [<c014960c>] vfs_read+0x9c/0xcc
 [<c01497ed>] sys_read+0x31/0x4c
 [<c0108bd7>] syscall_call+0x7/0xb


> Could you please try the following patch, and let me know if it works? 

That fixed it, thanks.  

-- 
Dave Hansen
haveblue@us.ibm.com


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-06-17 22:46 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-06-17 22:12 borked sysfs system devices in 2.5.72 Dave Hansen
2003-06-17 22:26 ` Patrick Mochel
2003-06-17 22:31   ` Dave Hansen
2003-06-17 22:54     ` Patrick Mochel
2003-06-17 22:58       ` Dave Hansen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox