Hi Dave,
Further debugging, I found that tt->max_tasks are set properly, but where
as tt->running_tasks is set to 2, it is not incremented as expected in
function refresh_hlist_task_table_v2().
Regards
Hariharan T.S.
Dave Anderson
<anderson@redhat.
com> To
Hariharan S Reddy/India/IBM@IBMIN
12/04/07 11:53 PM cc
Crash-utility@xxxxxxxxxx, Sachin P
Sant/India/IBM@IBMIN, Chandru
Siddalingappa/India/IBM@IBMIN, Jeff
Layton <jlayton@xxxxxxxxxx>
Subject
Re: problems
running crash on recent rawhide
live kernels
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
