Hariharan S Reddy wrote:
Hi Dave, I also came across the same problem, tt->refresh_hash_table is set to refresh_hlist_task_table_v2(), after executing the function the tt->current is set to 0 (zero).
As Jeff mentioned, this must have something to do with the new pid_namespace changes (of which I have no familiarity), although it still seems that refresh_hlist_task_table_v2() should continue to work. To gather the set of tasks, refresh_hlist_task_table_v2() walks the pid_hash[] array. Each entry in the array is an hlist_head, which points to either a hlist_node, or NULL. If it contains a pointer to an hlist_node, it's a pointer to the hlist_node embedded in a pid_link (at least it *was* until 2.6.24): struct pid_link { struct hlist_node node; struct pid *pid; } and from the "pid" structure pointer -- which points into a task structure's task_struct.pids member -- the task can be readily determined by subtracting the task_struct.pids member offset. So, for example, on a 2.6.18 system, here's a non-NULL pid_hash entry at the 141'th entry: crash> p pid_hash[141] $6 = { first = 0xffff810037da51e8 } it's a pointer to the embedded hlist_node in a pid_link: crash> pid_link 0xffff810037da51e8 struct pid_link { node = { next = 0x0, pprev = 0xffff810009e53468 }, pid = 0xffff810037d0d9c0 } and from the pid pointer, the task can be determined by subtracting 352 (the task_struct.pids offset): crash> eval 0xffff810037d0d9c0 - 352 hexadecimal: ffff810037d0d860 decimal: 18446604436669257824 (-139637040293792) octal: 1777774020006764154140 binary: 1111111111111111100000010000000000110111110100001101100001100000 crash> ps ffff810037d0d860 PID PPID CPU TASK ST %MEM VSZ RSS COMM 13 1 3 ffff810037d0d860 IN 0.0 0 0 [watchdog/3] crash> Note that the next pointer above could point to another task in the chain, and the pprev pointer of the first entry points back to pid_hash[141]: crash> p &pid_hash[141] $7 = (struct hlist_head *) 0xffff810009e53468 crash> Now, I don't see why this won't work in 2.6.24, even with the pid_namespace changes. I hacked up a crash to only gather the swapper pid 0 task so I could see what's different about the pid_hash array. For example, here's a non-NULL entry at index 112: crash> p pid_hash[112] $11 = { first = 0xffff810018899b88 } And here's what it looks like as a pid_link: crash> pid_link 0xffff810018899b88 struct pid_link { node = { next = 0x0, pprev = 0xffff81000106ed80 }, pid = 0xcccccccccccccccc } Note that the pprev pointer is correct for that index: crash> p &pid_hash[112] $12 = (struct hlist_head *) 0xffff81000106ed80 crash> But the pid structure pointer is 0xcccccccccccccccc. And that is the case for every non-NULL entry in the pid_hash array. Does anybody have an idea what the significance of the 0xcccccccccccccccc is? Or what is wrong with gathering the tasks in that manner? Anyway, crash is pretty much dead in the water for 2.6.24 until a proper task-gathering function is written. Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility