FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 05-21-2012, 08:36 AM
qiaonuohan
 
Default Adding a new command rbtree

The patch has been modified.

At 2012-5-19 5:04, Dave Anderson wrote:



----- Original Message -----

Hello Dave,

The attachment is the code that adds two command, rbtree and rdtree. The
commands work well, but, onsidering some code is a copy of command list,
I think the code still need a big change.



Hi Qiao,

I haven't been able to spend much time looking at this patch, but
these are my initial impressions.

My suggestion of a single "tree" command was just that, where there
would be a single "tree" command, and that command would require an
option to make the differentiation between an red-black tree and a
radix tree.

I don't quite understand why you *only* have the "[-o] offset" advertised
for the rbtree command? Virtually every instance of a radix_tree_root
structure in the kernel is embedded in a data structure, similar to the
typical usage of an rb_root. Why the difference?

The "-H start" option should probably be something like "-R" for "root".
When -H is used in the list command, it refers to list_[H]ead.

The examples in the help pages are not particularly helpful.
I don't know what "tts.rb" refers to? Can you find better examples
that the user can relate to?

Also, a clear explanation of what the "position information" actually
means would be helpful.

Thanks,
Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility





--
--
Regards
Qiao Nuohan


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-21-2012, 07:56 PM
Dave Anderson
 
Default Adding a new command rbtree

----- Original Message -----
> The patch has been modified.


This command doesn't seem to work on RHEL5. When I try to mimic
the radix_tree example that your help page shows:

crash> help tree
...
Display radix tree's address and position information only:

crash> tree -t radix -o address_space.page_tree -p ffff88004e749de0
ffffea0000c3da60
position: root/0/0
ffffea0000062a48
position: root/0/1
ffffea0000062a10
position: root/0/2
ffffea0000c39f88
position: root/0/3
ffffea0000071ab0
position: root/0/4
...

The example above seems pretty straight-forward, where the address_space
structure has a radix_tree_root "page_tree" member:

crash> address_space.page_tree
struct address_space {
[0x8] struct radix_tree_root page_tree;
}

So if I pick out my own address_space structure by looking at the crash
utility's address space:

crash> vm -p
PID: 20739 TASK: ffff8100190330c0 CPU: 1 COMMAND: "crash"
MM PGD RSS TOTAL_VM
ffff81003ceaeb00 ffff810023f9f000 111440k 190736k
VMA START END FLAGS FILE
ffff8100346e88c8 400000 a32000 1875 /var/CVS/crash-6.0.6/crash
VIRTUAL PHYSICAL
400000 8d3e000
401000 3ec23000
402000 146a4000
...

If I do a "vtop" on the first user-space address above, its associated
address_space (page.mapping) is shown at the bottom:

crash> vtop 400000
VIRTUAL PHYSICAL
400000 8d3e000

PML: 23f9f000 => 2cda8067
PUD: 2cda8000 => 39f81067
PMD: 39f81010 => 1448d067
PTE: 1448d000 => 8d3e025
PAGE: 8d3e000

PTE PHYSICAL FLAGS
8d3e025 8d3e000 (PRESENT|USER|ACCESSED)

VMA START END FLAGS FILE
ffff8100346e88c8 400000 a32000 1875 /var/CVS/crash-6.0.6/crash

PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff8100008d4590 8d3e000 ffff81001b23eb08 0 3 808000000086c
crash>

which shows this:

crash> address_space ffff81001b23eb08
struct address_space {
host = 0xffff81001b23e9f8,
page_tree = {
height = 0x2,
gfp_mask = 0x220,
rnode = 0xffff81001d52f0d0
},
...

But using your example to dump the pages in the address_space,
I always see something like this:

crash> tree -t radix -o address_space.page_tree -p ffff81001b23eb08
radix_tree_node at ffff81001d52f0d0
struct radix_tree_node {
count = 0x18,
slots = {0xffff81001fa7dce0, 0xffff810025e266d8, 0xffff81000c939718, 0xffff81000ac41718, 0xffff81002eba3b48, 0xffff81002fc73050
, 0xffff81000ee6d2a8, 0xffff81000842a2e8, 0xffff81000ed5f500, 0xffff81003246cda0, 0xffff810016305da0, 0xffff81002008dce0, 0xffff8
1001fb02970, 0xffff81002aa77ce0, 0xffff81003292f090, 0xffff8100071e28b0, 0xffff8100364b3050, 0xffff810026d72ac8, 0xffff81000d6b04
c0, 0xffff810033eda480, 0xffff81000bad1540, 0x0, 0xffff8100392786d8, 0x0, 0xffff810036a85758, 0xffff810031b92698, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
tags = {{0x0}, {0x0}}
}
tree: height 6251 is greater than height_to_maxindex[] index 12
crash>

What's going on there? It happens on all RHEL5 dumpfiles I test.

Dave



--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-21-2012, 08:21 PM
Dave Anderson
 
Default Adding a new command rbtree

----- Original Message -----
> The patch has been modified.

Whereas the radix_tree problem I showed in my last email seems to
be RHEL5-related, I cannot dump a red-black tree from an rb_root on
RHEL5, RHEL6 or Fedora.

For example, taking an mm_struct, it has an "mm_rb" rb_root:

crash> mm_struct.mm_rb
struct mm_struct {
[0x8] struct rb_root mm_rb;
}

Therefore I should be able to dump it with:

crash> tree -t rb -o mm_struct.mm_rb <mm-struct-address>

I get the mm_struct address like so:

crash> vm
PID: 20739 TASK: ffff8100190330c0 CPU: 3 COMMAND: "crash"
MM PGD RSS TOTAL_VM
ffff81003ceaeb00 ffff810023f9f000 111452k 190736k
...

But it always fails like this on RHEL5:

crash> tree -t rb -o mm_struct.mm_rb ffff81003ceaeb00
ffff81003ceaeb08
ffffffff8006fe65
6508ec8348f38948
tree: invalid kernel virtual address: 6508ec8348f38958 type: "rb_node rb_left"
crash>

The same thing happens on RHEL6:

crash> vm
PID: 14353 TASK: ffff88003a93c080 CPU: 3 COMMAND: "crash"
MM PGD RSS TOTAL_VM
ffff880037b65840 ffff88001c31b000 153552k 288936k
...

crash> tree -t rb -o mm_struct.mm_rb ffff880037b65840
ffff880037b65848
ffffffff81010800
f075894ce86d894c
tree: invalid kernel virtual address: f075894ce86d895c type: "rb_node rb_left"
crash>

And on a Fedora 3.3.1-3.fc16 kernel:

crash> vm
PID: 1175 TASK: ffff88003acb9730 CPU: 2 COMMAND: "crash"
MM PGD RSS TOTAL_VM
ffff880038495c00 ffff88003ac5a000 181580k 335436k
...

crash> tree -t rb -o mm_struct.mm_rb ffff880038495c00
ffff880038495c08
ffffffff81018ce0
f075894ce86d894c
tree: invalid kernel virtual address: f075894ce86d895c type: "rb_node rb_left"
crash>

What's going on there?

Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-22-2012, 02:36 AM
qiaonuohan
 
Default Adding a new command rbtree

At 2012-5-22 4:21, Dave Anderson wrote:



----- Original Message -----

The patch has been modified.


Whereas the radix_tree problem I showed in my last email seems to
be RHEL5-related, I cannot dump a red-black tree from an rb_root on
RHEL5, RHEL6 or Fedora.


I didn't explain the address clearly.

<cut>
The meaning of the "start" argument, which can be expressed either
symbolically or in hexadecimal format, depends upon whether the -N
option is pre-pended or not:
start The address of the structure where radix_tree_root(radix
tree) or rb_node(red-black tree) is embeded.
-N start The address of the structure radix_tree_node(radix tree)
or rb_node(red-black tree)
<cut>

So you can only specified rb_node's related address. The following is
about why the command doesn't support your situation.

In your situation, the offset you offered is the offset of rb_root.

struct rb_root
{
struct rb_node *rb_node;
};

So I can get the address of root node, then get the address of its
offspring nodes. But now, I cannot convert the address of an
rb_node(offspring node) to its related structure's information. In
details, the rb_node may be embeded in a structure, but the offset of
rb_node is not offered. So the offset should be the offset of rb_node.



For example, taking an mm_struct, it has an "mm_rb" rb_root:

crash> mm_struct.mm_rb
struct mm_struct {
[0x8] struct rb_root mm_rb;
}

Therefore I should be able to dump it with:

crash> tree -t rb -o mm_struct.mm_rb<mm-struct-address>

I get the mm_struct address like so:

crash> vm
PID: 20739 TASK: ffff8100190330c0 CPU: 3 COMMAND: "crash"
MM PGD RSS TOTAL_VM
ffff81003ceaeb00 ffff810023f9f000 111452k 190736k
...

But it always fails like this on RHEL5:

crash> tree -t rb -o mm_struct.mm_rb ffff81003ceaeb00
ffff81003ceaeb08
ffffffff8006fe65
6508ec8348f38948
tree: invalid kernel virtual address: 6508ec8348f38958 type: "rb_node rb_left"
crash>

The same thing happens on RHEL6:

crash> vm
PID: 14353 TASK: ffff88003a93c080 CPU: 3 COMMAND: "crash"
MM PGD RSS TOTAL_VM
ffff880037b65840 ffff88001c31b000 153552k 288936k
...

crash> tree -t rb -o mm_struct.mm_rb ffff880037b65840
ffff880037b65848
ffffffff81010800
f075894ce86d894c
tree: invalid kernel virtual address: f075894ce86d895c type: "rb_node rb_left"
crash>

And on a Fedora 3.3.1-3.fc16 kernel:

crash> vm
PID: 1175 TASK: ffff88003acb9730 CPU: 2 COMMAND: "crash"
MM PGD RSS TOTAL_VM
ffff880038495c00 ffff88003ac5a000 181580k 335436k
...

crash> tree -t rb -o mm_struct.mm_rb ffff880038495c00
ffff880038495c08
ffffffff81018ce0
f075894ce86d894c
tree: invalid kernel virtual address: f075894ce86d895c type: "rb_node rb_left"
crash>

What's going on there?

Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility





--
--
Regards
Qiao Nuohan



--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-22-2012, 03:15 PM
Dave Anderson
 
Default Adding a new command rbtree

----- Original Message -----
> At 2012-5-22 4:21, Dave Anderson wrote:
> >
> >
> > ----- Original Message -----
> >> The patch has been modified.
> >
> > Whereas the radix_tree problem I showed in my last email seems to
> > be RHEL5-related, I cannot dump a red-black tree from an rb_root on
> > RHEL5, RHEL6 or Fedora.
>
> I didn't explain the address clearly.
>
> <cut>
> The meaning of the "start" argument, which can be expressed either
> symbolically or in hexadecimal format, depends upon whether the -N
> option is pre-pended or not:
> start The address of the structure where
> radix_tree_root(radix
> tree) or rb_node(red-black tree) is embeded.
> -N start The address of the structure radix_tree_node(radix
> tree)
> or rb_node(red-black tree)
> <cut>
>
> So you can only specified rb_node's related address. The following is
> about why the command doesn't support your situation.
>
> In your situation, the offset you offered is the offset of rb_root.
>
> struct rb_root
> {
> struct rb_node *rb_node;
> };
>
> So I can get the address of root node, then get the address of its
> offspring nodes. But now, I cannot convert the address of an
> rb_node(offspring node) to its related structure's information. In
> details, the rb_node may be embeded in a structure, but the offset of
> rb_node is not offered. So the offset should be the offset of
> rb_node.

OK, so this is what you currently have:

[-o] offset The offset within the structure to the radix_tree_root(radix tree)
or rb_node(red-black tree), default is 0.If non-zero, the offset
may be entered in either of two manners:

1. In "structure.member" format; the "-o" is not necessary.
2. A number of bytes; the "-o" is only necessary on processors
where the offset value could be misconstrued as a kernel
virtual address.

Doing it that way really confuses two different "offset" issues that are associated
with this command:

(1) the offset of an rb_root or radix_tree_node within a containing
data structure, and
(2) the offset of an rb_node within a containing data structure.

With respect to (1), typically the rb_root or radix_tree_root structure is
embedded within another containing data structure. The user will know the
containing structure's address, for example, the address of an mm_struct.
But the user should not have to first determine the mm_struct.mm_rb member
offset, and then have to add it to the mm_struct address in order to
pre-calulate the "start" parameter.

So for the "start" address, there needs to be an accompanying option that
indicates that the rb_root or radix_tree_root is embedded in another data
structure. Something like:

-r offset If the "start" argument is the address of a data structure that
contains the radix_tree_root or rb_root structure, then this is
the offset to that structure member. If the offset is non-zero,
then this option is required. The offset may be entered in either
of two manners:

1. In "structure.member" format.
2. A number of bytes.

If the "start" argument is the actual address of an rb_root or radix_tree_root,
or if the radix_tree_root or rb_root member offset is 0, then the -r option would
be unnecessary.

With respect to (2), there needs to be second option for embedded rb_node structures,
something like:

-n offset The offset of the rb_node within its containing data structure. If the
offset is non-zero, then this option is required. The offset may be
entered in either of two manners:

1. In "structure.member" format.
2. A number of bytes.

If the rb_node member offset is 0, then the -n option would be unnecessary.

And in both cases, forget trying to implement the "the -o is not necessary" and
"the -o is only necessary..." optimizations, because it would be almost impossible
to do.

Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-23-2012, 03:38 AM
qiaonuohan
 
Default Adding a new command rbtree

At 2012-5-22 23:15, Dave Anderson wrote:

Doing it that way really confuses two different "offset" issues that are associated
with this command:

(1) the offset of an rb_root or radix_tree_node within a containing
data structure, and
(2) the offset of an rb_node within a containing data structure.





And in both cases, forget trying to implement the "the -o is not necessary" and
"the -o is only necessary..." optimizations, because it would be almost impossible
to do.


Hello Dave,

I will list all the situations I was concerning.

First red-black tree:
1. rb_node is embedded in a structure. Address is the address of the
structure, and -o shows the offset of rb_node to the structure.


2. same as 1., but the address is the address of rb_node when using -N
in command line.


rb_root was not concering. I will recall the reason. I can get the root
node from rb_root. And then the offspring of the root node. Then I still
need a offset that shows the offset of the offspring node to its related
structure to get the structure's information.


Then radix tree:
3. radix_tree_root's address is specified.

4. radix_tree_node's address is specified.

According to your reply, "-r offset" indicates rb_root and
radix_tree_root, and "-n offset" indicates rb_node and radix_tree_node.
And if I use "-r offset", then I need another option to show the offset
of rb_node. And when using "-n offset" together with an address, which
can only be one of rb_node's address and address of the structure
rb_node embedded in, I may need another option to indicate the address's
type.


So I think "tree -t type -r offset -n offset -m addr..." is a good
choice. "-r offset" indicates the rb_root or radix_tree_root's offset,
and "-n offset" indicates the rb_node or radix_tree_node's offset. When
only using "-n offset" indicates the addr is related to rb_node or
radix_tree_node, but if "-r offset" is also specified, the addr is
related to rb_root or radix_tree_root. When "-m" is specified, the addr
is the address of the root(when specified "-r offset") or the node. If
"-m" is not specified, the addr is the address of the structure that
containing the root(when specified "-r offset") or the node.


Do you think it's OK?

--
--
Regards
Qiao Nuohan



--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-23-2012, 02:06 PM
Dave Anderson
 
Default Adding a new command rbtree

----- Original Message -----
> At 2012-5-22 23:15, Dave Anderson wrote:
> > Doing it that way really confuses two different "offset" issues that are associated
> > with this command:
> >
> > (1) the offset of an rb_root or radix_tree_node within a containing
> > data structure, and
> > (2) the offset of an rb_node within a containing data structure.
> >
> > And in both cases, forget trying to implement the "the -o is not necessary" and
> > "the -o is only necessary..." optimizations, because it would be almost impossible
> > to do.
>
> Hello Dave,
>
> I will list all the situations I was concerning.
>
> First red-black tree:
> 1. rb_node is embedded in a structure. Address is the address of the
> structure, and -o shows the offset of rb_node to the structure.
>
> 2. same as 1., but the address is the address of rb_node when using -N
> in command line.
>
> rb_root was not concering. I will recall the reason. I can get the root
> node from rb_root. And then the offspring of the root node. Then I still
> need a offset that shows the offset of the offspring node to its related
> structure to get the structure's information.
>
> Then radix tree:
> 3. radix_tree_root's address is specified.
>
> 4. radix_tree_node's address is specified.
>
> According to your reply, "-r offset" indicates rb_root and radix_tree_root,

Correct, but only if the rb_root or radix_tree_root are embedded in a
data structure, and the address argument points to the data stucture.

> and "-n offset" indicates rb_node and radix_tree_node.

No -- the "-n offset" would only applicable to rb_nodes.

radix_tree_node structures data are standalone entities that are allocated
from the "radix_tree_node" slab cache, correct? When would a radix_tree_node
ever be embedded in a containing data structure?

> And if I use "-r offset", then I need another option to show the offset
> of rb_node. And when using "-n offset" together with an address, which
> can only be one of rb_node's address and address of the structure
> rb_node embedded in, I may need another option to indicate the address's
> type.

The address is either that of an rb_root or radix_tree_root, or the
address of the containing data structure, in which case it would
require the "-r offset" option.

>
> So I think "tree -t type -r offset -n offset -m addr..." is a good
> choice. "-r offset" indicates the rb_root or radix_tree_root's offset,
> and "-n offset" indicates the rb_node or radix_tree_node's offset.

Again, what is a "radix_tree_node offset"?

> only using "-n offset" indicates the addr is related to rb_node or
> radix_tree_node, but if "-r offset" is also specified, the addr is
> related to rb_root or radix_tree_root. When "-m" is specified, the addr
> is the address of the root(when specified "-r offset") or the node. If
> "-m" is not specified, the addr is the address of the structure that
> containing the root(when specified "-r offset") or the node.
>
> Do you think it's OK?

No, that confuses the hell out me...

I really don't understand the need for the additional "-m" option?

To me it's simple -- but I may be missing something. The address argument
can be either:

(1) A pointer to an rb_root or radix_tree_root.
The "-r offset" is not required.

(2) A pointer to a data structure containing an rb_root or radix_tree_root.
The "-r offset" option is required if the member offset is non-zero.

That being the case, this should work:

red-black tree: tree -t type [-r offset] [-n offset] address
radix tree: tree -t type [-r offset] address

In the case of a red-black tree, it seems that you are also trying to
support the bypassing of the rb_root entirely, and point to an rb_node
directly? That would seem to be an odd-ball case, because the list
would be truncated if you don't point to the topmost rb_node. Is that
what you have in mind? If so, I suppose that you could also have a
additional "-N" option or something like that to signal that the address
argument is a pointer to an rb_node (and not applicable to radix trees).

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-24-2012, 10:38 AM
qiaonuohan
 
Default Adding a new command rbtree

At 2012-5-23 22:06, Dave Anderson wrote:



----- Original Message -----

At 2012-5-22 23:15, Dave Anderson wrote:

Doing it that way really confuses two different "offset" issues that are associated
with this command:

(1) the offset of an rb_root or radix_tree_node within a containing
data structure, and
(2) the offset of an rb_node within a containing data structure.

And in both cases, forget trying to implement the "the -o is not necessary" and
"the -o is only necessary..." optimizations, because it would be almost impossible
to do.


Hello Dave,

I will list all the situations I was concerning.

First red-black tree:
1. rb_node is embedded in a structure. Address is the address of the
structure, and -o shows the offset of rb_node to the structure.

2. same as 1., but the address is the address of rb_node when using -N
in command line.

rb_root was not concering. I will recall the reason. I can get the root
node from rb_root. And then the offspring of the root node. Then I still
need a offset that shows the offset of the offspring node to its related
structure to get the structure's information.

Then radix tree:
3. radix_tree_root's address is specified.

4. radix_tree_node's address is specified.

According to your reply, "-r offset" indicates rb_root and radix_tree_root,


Correct, but only if the rb_root or radix_tree_root are embedded in a
data structure, and the address argument points to the data stucture.


and "-n offset" indicates rb_node and radix_tree_node.


No -- the "-n offset" would only applicable to rb_nodes.

radix_tree_node structures data are standalone entities that are allocated
from the "radix_tree_node" slab cache, correct? When would a radix_tree_node
ever be embedded in a containing data structure?


And if I use "-r offset", then I need another option to show the offset
of rb_node. And when using "-n offset" together with an address, which
can only be one of rb_node's address and address of the structure
rb_node embedded in, I may need another option to indicate the address's
type.


The address is either that of an rb_root or radix_tree_root, or the
address of the containing data structure, in which case it would
require the "-r offset" option.



So I think "tree -t type -r offset -n offset -m addr..." is a good
choice. "-r offset" indicates the rb_root or radix_tree_root's offset,
and "-n offset" indicates the rb_node or radix_tree_node's offset.


Again, what is a "radix_tree_node offset"?


only using "-n offset" indicates the addr is related to rb_node or
radix_tree_node, but if "-r offset" is also specified, the addr is
related to rb_root or radix_tree_root. When "-m" is specified, the addr
is the address of the root(when specified "-r offset") or the node. If
"-m" is not specified, the addr is the address of the structure that
containing the root(when specified "-r offset") or the node.

Do you think it's OK?


No, that confuses the hell out me...

I really don't understand the need for the additional "-m" option?

To me it's simple -- but I may be missing something. The address argument
can be either:

(1) A pointer to an rb_root or radix_tree_root.
The "-r offset" is not required.

(2) A pointer to a data structure containing an rb_root or radix_tree_root.
The "-r offset" option is required if the member offset is non-zero.

That being the case, this should work:

red-black tree: tree -t type [-r offset] [-n offset] address
radix tree: tree -t type [-r offset] address

In the case of a red-black tree, it seems that you are also trying to
support the bypassing of the rb_root entirely, and point to an rb_node
directly? That would seem to be an odd-ball case, because the list
would be truncated if you don't point to the topmost rb_node. Is that
what you have in mind? If so, I suppose that you could also have a
additional "-N" option or something like that to signal that the address
argument is a pointer to an rb_node (and not applicable to radix trees).


I still add "-N" option to make it possible to start from node.



Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility





--
--
Regards
Qiao Nuohan


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-24-2012, 07:12 PM
Dave Anderson
 
Default Adding a new command rbtree

----- Original Message -----

> I still add "-N" option to make it possible to start from node.

Hello Qiao,

We're getting closer, but there is still a problem with red-black
tree dumps.

For this command to be useful, the "tree" command should do what the
"list" command does when dumping a list of structures that have embedded
list_head members -- which is to dump the addresses of the data structures
in the list.

In the case of radix tree lists, your patch does the right thing, which
is to dump the addresses of the items found in the lowest radix_tree_node
slots[] array. Taking an address_space address of ffff8805f5a73580, the
address_space.page_tree radix tree dump shows the page struct addresses,
and therefore the "-s page.mapping" option works -- confirming that each
page struct has a reference back to the address_space:

crash> tree -t radix -r address_space.page_tree ffff8805f5a73580 -s page.mapping
ffffea00178472c0
mapping = 0xffff8805f5a73580
ffffea0017869240
mapping = 0xffff8805f5a73580
ffffea0017869280
mapping = 0xffff8805f5a73580
ffffea00178692c0
mapping = 0xffff8805f5a73580
ffffea0017869300
mapping = 0xffff8805f5a73580
ffffea0017869340
mapping = 0xffff8805f5a73580
ffffea0017869380
...

But in the case of red-black trees, your patch is not consistent, because
it dumps the addresses of the embedded rb_node structure in each data
structure in the list. A user would typically want to see the addresses
of the containing data structure, *not* the embedded rb_node addresses.

For example, suppose we want to see the list of vm_area_structs that
are members of the red-black tree whose root is in an mm_struct. Using
your latest patch, this is what I see, where the mm_struct address
is ffff880828163180:

crash> vm | head -3
PID: 8426 TASK: ffff88042bd9cd00 CPU: 3 COMMAND: "crash"
MM PGD RSS TOTAL_VM
ffff880828163180 ffff880828f7a000 193048k 344404k
crash>

Therefore, this command should dump the address of each vm_area_struct
in the tree:

crash> tree -t rb -r mm_struct.mm_rb -o vm_area_struct.vm_rb ffff880828163180
ffff880828a82d80
ffff880828a82798
ffff880828a83758
ffff880828a81bc8
ffff880828a83560
ffff880828a821b0
ffff88081c5a57d8
ffff88081c5a7170
ffff880828a80038
ffff880828a80230
...

However, the addresses above are the addresses of the vm_area_struct.vm_rb
rb_node members -- not the addresses of the containing vm_area_structs.
Confusing the issue even more, if I remove the "-o vm_area_struct.vm_rb"
option from the command line, I see the exact same output as above:

crash> tree -t rb -r mm_struct.mm_rb ffff880828163180
ffff880828a82d80
ffff880828a82798
ffff880828a83758
ffff880828a81bc8
ffff880828a83560
ffff880828a821b0
ffff88081c5a57d8
ffff88081c5a7170
ffff880828a80038
ffff880828a80230
...

For red-black trees, the "-o offset" option is always required unless
the rb_node member in the containing data structure has a member
offset of 0.

And presuming that I want a list of vm_area_struct addresses, your patch
doesn't do that.

I do note that "-s struct[.member,member]" will work correctly if
the "-o vm_area_struct.vm_rb" is applied, so you're on the right track.

But again, the red-black tree dump should be similar to the radix tree
dump, and both of them should be similar to the "list" command.

Another minor nit -- you should disallow the usage of "-o offset" when
a radix tree is being dumped. Although your patch apparently ignores it,
it should display an error message and fail the command.

Thanks,
Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 05-25-2012, 05:22 AM
qiaonuohan
 
Default Adding a new command rbtree

At 2012-5-25 3:12, Dave Anderson wrote:

But again, the red-black tree dump should be similar to the radix tree
dump, and both of them should be similar to the "list" command.


Fixed. I misunderstood the address printed by list command. I thought I
need to print the address of tree node.



Another minor nit -- you should disallow the usage of "-o offset" when
a radix tree is being dumped. Although your patch apparently ignores it,
it should display an error message and fail the command.


Print ""-o offset" is supported for radix tree" and then fail the
command.


--
--
Regards
Qiao Nuohan


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 10:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org