----- Original Message ----- Having radix_tree and rbtree enumerators is a good idea. But before you get started, please do *not* pollute the cmd_list() function with these two facilities. Make it a separate command ("tree" perhaps?) that can branch and handle the two different tree types. It would also be helpful if the interfaces could be made available for use by other commands, i.e., similar to the way that the "irq" command uses the do_radix_tree() function in filesys.c, or the way that do_list() is used by cmd_list(), but is also available as a general purpose function for other commands. Dave

----- Original Message ----- That's right. Given its general nature, a command that dumps the contents of the two tree variants would be a good candidate for a built-in command. Dave

----- Original Message ----- 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

The patch has been modified. At 2012-5-19 5:04, Dave Anderson wrote: -- -- Regards Qiao Nuohan

----- Original Message ----- 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

----- Original Message ----- 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

----- Original Message ----- 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. 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? 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. Again, what is a "radix_tree_node offset"? 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

----- Original Message ----- 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

----- Original Message ----- You have fixed the red-black tree issue, but now it seems that the radix tree dump no longer works. As a verification of a red-black tree list, let's again take the list of vm_area_structs that in a red-black list rooted at each mm_struct: crash> vm | head -3 PID: 16041 TASK: ffff8100100187a0 CPU: 1 COMMAND: "crash" MM PGD RSS TOTAL_VM ffff810039735ac0 ffff810001d8a000 111400k 190424k crash> So the mm_struct address is ffff810039735ac0, its rb_root is at offset "-r mm_struct.mm_rb", and each rb_node in the list can be found at the offset "-o vm_area_struct.vm_rb". To verify, the "-s vm_area_struct.vm_mm" of each entry should point back to the mm_struct: crash> tree -t rb -r mm_struct.mm_rb -o vm_area_struct.vm_rb ffff810039735ac0 -s vm_area_struct.vm_mm ffff810039eedef8 vm_mm = 0xffff810039735ac0 ffff810024e06978 vm_mm = 0xffff810039735ac0 ffff8100065b61e8 vm_mm = 0xffff810039735ac0 ffff810005322e48 vm_mm = 0xffff810039735ac0 ffff81000468b818 vm_mm = 0xffff810039735ac0 ffff810025041d98 vm_mm = 0xffff810039735ac0 ... But in fixing red-black tree list, it seems that you have broken radix tree lists, which worked OK in the previous patch. The address_space.page_tree example that you use in the help page, and that I used in my last email, now fails. For example, take an address_space structure address of ffff81000d1edb88: crash> vtop 400000 | tail -2 PAGE PHYSICAL MAPPING INDEX CNT FLAGS ffff8100009c4af8 d1e9000 ffff81000d1edb88 0 3 8080000000868 crash> Here is the radix_tree_root, and the topmost radix_tree_node: crash> address_space.page_tree ffff81000d1edb88 page_tree = { height = 0x3, gfp_mask = 0x220, rnode = 0xffff81002ac43090 } crash> kmem -s 0xffff81002ac43090 CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS SSIZE ffff810037c8a200 radix_tree_node 536 3182 6405 915 4k SLAB MEMORY TOTAL ALLOCATED FREE ffff81002ac43040 ffff81002ac43090 7 4 3 FREE / [ALLOCATED] [ffff81002ac43090] crash> It should dump its list of entries with the following command, but which fails like so: crash> tree -t radix -r address_space.page_tree ffff81000d1edb88 radix_tree_node at ffff81002ac43090 struct radix_tree_node { count = 0x2, slots = {0xffff8100197e8930, 0xffff810033bf9698, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x 0, 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, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, tags = {{0x0}, {0x0}} } tree: height 530 is greater than height_to_maxindex[] index 12 crash> Dave

----- Original Message ----- The reason that the command fails on RHEL5 is due to this part of your patch: 3766 void rdtree_iteration(ulong node_p, struct tree_data *td, char * ppos, ulong indexnum) 3767 { 3768 uint height; 3769 ulong slot; 3770 int index; 3771 int i; 3772 char pos[BUFSIZE]; 3773 3774 if (indexnum != -1) 3775 sprintf(pos, "%s/%ld", ppos, indexnum); 3776 else 3777 sprintf(pos, "%s", ppos); 3778 3779 readmem(node_p + MEMBER_OFFSET("radix_tree_node", "height"), KVADDR, 3780 &height, sizeof(uint), "radix_tree_node height", FAULT_ON_ERROR); 3781 3782 if (height > ARRAY_LENGTH(height_to_maxindex)) { 3783 fprintf(fp, "radix_tree_node at %lx\n", node_p); 3784 dump_struct("radix_tree_node", node_p, RADIX(16)); 3785 error(FATAL, "height %d is greater than height_to_maxindex[] \ 3786 index %ld\n", height, ARRAY_LENGTH(height_to_maxindex)); 3787 } In line 3779, you calculate "height" using: MEMBER_OFFSET("radix_tree_node", "height") which returns -1, because RHEL5's radix_tree_node does not have a "height" member: crash> radix_tree_node struct radix_tree_node { unsigned int count; void *slots[64]; long unsigned int tags[2][1]; } SIZE: 536 crash> In RHEL6, a radix_tree_node structure does have a "height" member: crash> radix_tree_node struct radix_tree_node { unsigned int height; unsigned int count; struct rcu_head rcu_head; void *slots[64]; long unsigned int tags[3][1]; } SIZE: 560 crash> In any case, I now see that your patch uses MEMBER_OFFSET(...) in 4 places: $ grep MEMBER_OFFSET 0001-add-a-new-command-tree.patch + readmem(node_p + MEMBER_OFFSET("radix_tree_node", "height"), KVADDR, + readmem(td->start + MEMBER_OFFSET("rb_root", "rb_node"), KVADDR, + readmem(node_p+MEMBER_OFFSET("rb_node", "rb_left"), KVADDR, &left_p, + readmem(node_p+MEMBER_OFFSET("rb_node", "rb_right"), KVADDR, &right_p, $ which is not acceptable, because it hides these kinds of programming errors. For each of the 4 structure members above, add them to the offset_table[] array, initialize them with MEMBER_OFFSET_INIT(), and use OFFSET(...) instead of MEMBER_OFFSET(). Then if your code is incorrect as above, it will fail immediately and show a meaningful error message. Dave

----- Original Message ----- This is getting tiresome... With this patch, both red-black or radix tree dumps fail when dumped from their roots, on RHEL5, RHEL6 and Fedora. Here are the results using the simple examples shown in your help page. RHEL5 red-black tree: crash> vm | head -3 PID: 15684 TASK: ffff81001b4c1820 CPU: 6 COMMAND: "crash" MM PGD RSS TOTAL_VM ffff81003b5beb00 ffff810014b43000 112352k 195584k crash> mm_struct.mm_rb ffff81003b5beb00 mm_rb = { rb_node = 0xffff8100110a1e78 } crash> tree -t rb -r mm_struct.mm_rb -o vm_area_struct.vm_rb ffff81003b5beb00 tree: "-r offset" is useless when specified "-N"ffff81003b5bead0 ffff810033522738 7fff36916fd0 tree: invalid kernel virtual address: 7fff36917010 type: "rb_node rb_left" crash> RHEL5 radix tree: crash> vtop 400000 | tail -2 PAGE PHYSICAL MAPPING INDEX CNT FLAGS ffff810000a58f88 fc47000 ffff81001d391518 0 3 808000000086c crash> address_space.page_tree ffff81001d391518 page_tree = { height = 3, gfp_mask = 544, rnode = 0xffff81000e2ec540 } crash> tree -t radix -r address_space.page_tree ffff81001d391518 tree: invalid structure member offset: radix_tree_node_height FILE: tools.c LINE: 3756 FUNCTION: do_rdtree() [./crash] error trace: 45a150 => 466d7e => 46571a => 4f8040 4f8040: OFFSET_verify+224 46571a: do_rdtree+570 466d7e: cmd_tree+670 45a150: exec_command+1328 tree: "-r offset" is useless when specified "-N"tree: invalid structure member offset: radix_tree_node_height FILE: tools.c LINE: 3756 FUNCTION: do_rdtree() crash> RHEL6 red-black tree: crash> vm | head -3 PID: 861 TASK: ffff880037309500 CPU: 0 COMMAND: "crash" MM PGD RSS TOTAL_VM ffff880037b4d280 ffff880015877000 154492k 291112k crash> mm_struct.mm_rb ffff880037b4d280 mm_rb = { rb_node = 0xffff880004d0ee40 } crash> tree -t rb -r mm_struct.mm_rb -o vm_area_struct.vm_rb ffff880037b4d280 tree: "-r offset" is useless when specified "-N"ffff880037b4d248 ffff88003a0dd750 7fff2fb5cfc8 tree: invalid kernel virtual address: 7fff2fb5d010 type: "rb_node rb_left" crash> RHEL6 radix tree: crash> vtop 400000 | tail -2 PAGE PHYSICAL MAPPING INDEX CNT FLAGS ffffea000070bde0 20364000 ffff880024da3de0 0 3 2000000000086c crash> address_space.page_tree ffff880024da3de0 page_tree = { height = 3, gfp_mask = 32, rnode = 0xffff88001da1c911 } crash> tree -t radix -r address_space.page_tree ffff880024da3de0 tree: "-r offset" is useless when specified "-N"tree: "-N" option is not supported or applicable for radix tree on this architecture or kernel crash> Fedora 3.3.1-3.fc16 red-black tree: crash> vm | head -3 PID: 1175 TASK: ffff88003acb9730 CPU: 2 COMMAND: "crash" MM PGD RSS TOTAL_VM ffff880038495c00 ffff88003ac5a000 181580k 335436k crash> mm_struct.mm_rb ffff880038495c00 mm_rb = { rb_node = 0xffff880036ae4668 } crash> tree -t rb -r mm_struct.mm_rb -o vm_area_struct.vm_rb ffff880038495c00 tree: "-r offset" is useless when specified "-N"ffff880038495bc8 ffff880036ae4968 4703fc8 tree: invalid kernel virtual address: 4704010 type: "rb_node rb_left" crash> Fedora 3.3.1-3.fc16 radix tree: crash> vtop 400000 | tail -2 PAGE PHYSICAL MAPPING INDEX CNT FLAGS ffffea0000ad2500 2b494000 ffff88003a209320 0 2 2000000002006c crash> address_space.page_tree ffff88003a209320 page_tree = { height = 2, gfp_mask = 32, rnode = 0xffff88003dff6e99 } crash> tree -t radix -r address_space.page_tree ffff88003a209320 tree: "-r offset" is useless when specified "-N"tree: "-N" option is not supported or applicable for radix tree on this architecture or kernel crash> Do you even test these patches before posting them? Dave

----- Original Message ----- No problem... OK, so here is my current test matrix and results: (1) tree -t rbtree -r mm_struct.mm_rb -o vm_area_struct.vm_rb <root> RHEL5: OK RHEL6: OK Fedora: OK (2) tree -t rbtree -o vm_area_struct.vm_rb -N <node> RHEL5: OK RHEL6: OK Fedora: OK (3) tree -t radix -r address_space.page_tree <root> RHEL5: OK RHEL6: OK Fedora: OK (4) tree -t radix -N <node> RHEL5: OK (not supported) RHEL6: OK (note caveat below) Fedora: OK (note caveat below) Caveat: for newer kernels that support -N for radix trees, a user might run into a situation where the radix_tree_node pointer has the "1-bit" set, and the node address is just cut-and-pasted. For example: crash> address_space.page_tree ffff88000990e5e0 page_tree = { height = 3, gfp_mask = 32, rnode = 0xffff880004682281 } crash> tree -t radix -N 0xffff880004682281 radix_tree_node at ffff880004682281 struct radix_tree_node { height = 0x2000000, count = 0xb8000000, rcu_head = { next = 0x40ffff8800046824, func = 0x70ffffffff812700 }, slots = {0x50ffff880017202d, 0xffff88003d60d0, 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, 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}, {0x100000000000000}} } tree: height 33554432 is greater than height_to_maxindex[] index 12 crash> I forget what the usage of the low-bit means w/respect to radix_tree_node pointers (?), but you've already got this in place in your do_rdtree() function: if (node_p & 1) node_p &= ~1; and I remember having to do the same thing in the currently existing radix_tree_lookup() function. So I believe that the 1-bit should be stripped off when a user inadvertently enters such an address as a -N radix_tree_node address. With this change to cmd_tree(): if (hexadecimal_only(args[optind], 0)) { value = htol(args[optind], FAULT_ON_ERROR, NULL); if (IS_KVADDR(value)) { td->start = value; + if ((td->start & 1) && + (td->flags & TREE_NODE_POINTER) && + (type_flag == RADIXTREE_REQUEST)) + td->start &= ~1; goto next_arg; } } it works OK regardless of the 1-bit setting: crash> address_space.page_tree ffff88000990e5e0 page_tree = { height = 3, gfp_mask = 32, rnode = 0xffff880022c1ab41 } crash> tree -t radix -N 0xffff880022c1ab41 ffffea0000327e28 ffffea00002ee0d8 ffffea00002ee110 ... crash> tree -t radix -N 0xffff880022c1ab40 ffffea0000327e28 ffffea00002ee0d8 ffffea00002ee110 ... I haven't tinkered with the -p option, although I don't think that it's a particularly important option. I may add a couple more error-handling additions, and perhaps some slight user interface changes, and the help page needs to be cleaned-up/clarified. But aside from that, this is looking pretty good for inclusion in crash-6.0.8. No further patch posting is required unless you find a new bug or other problem -- nice job! Thanks, Dave

At 2012-6-1 2:34, Dave Anderson wrote: Hello Dave, I have to point out that you only involved the situation that user input a hexadecimal number. The tree command can get starting address from three place. <cut> if ((sp = symbol_search(args[optind]))) { td->start = sp->value; goto next_arg; } if (!IS_A_NUMBER(args[optind])) { if (can_eval(args[optind])) { value = eval(args[optind], FAULT_ON_ERROR, NULL); if (IS_KVADDR(value)) { td->start = value; goto next_arg; } } error(FATAL, "invalid argument: %s\n", args[optind]); } if (hexadecimal_only(args[optind], 0)) { value = htol(args[optind], FAULT_ON_ERROR, NULL); if (IS_KVADDR(value)) { td->start = value; goto next_arg; } } <cut> So I prefer change like this. <cut> if (td->flags & TREE_NODE_POINTER) { node_p = td->start; + + if (node_p & 1) + node_p &= ~1; + if (VALID_MEMBER(radix_tree_node_height)) { readmem(node_p + OFFSET(radix_tree_node_height), KVADDR, &height, sizeof(uint), "radix_tree_node height", FAULT_ON_ERROR); <cut> -- -- Regards Qiao Nuohan

From: qiaonuohan <qiaonuohan(a)cn.fujitsu.com&gt; Subject: [Crash-utility] Adding a new command rbtree Date: Wed, 09 May 2012 16:47:58 +0800 Hello Qiaon, It seems natural to me to make output format of both new commands compatible to list as much as possible. For example, list command outputs list of address for each nodes at default. rbtree and rdtree should do like this at defalt? Other information specific to individual tree structures such as position of node within the tree could be useful if given. But the output examples you're showing above can easily violate 80 column rule. Instead, how about splitting the feature of indicating position from the default output? My quick idea here: First, given address of starting node, list all the nodes addresses connected to the starting node. crash> list 0xffff88003ef1f908 ffff88003ef1f908 ffff88003ef1eec8 ffff88003ef1e488 ffff88003ef2b948 ffff88003ef2af08 ffff88003ef2a4c8 ffff88003ef55988 ffff88003ef54f48 ffff88003ef899c8 Suppose that user wants to know where the node with ffff88003ef2a4c8 positions in the tree starting from 0xffff88003ef1f908; in other words, position of node ffff88003ef2a4c8 relative to 0xffff88003ef1f908. Then: crash> rbtree -p 0xffff88003ef1f908 ffff88003ef2a4c8 rlr where I choosed -p at random intending "p"osition. Maybe there's case where user wants to know many positions at the same time. It might be better to use "<" operator? like crash> list 0xffff88003ef1f908 > ADDRESS_list.txt crash> rbtree -p 0xffff88003ef1f908 < ADDRESS_list.txt Thanks. HATAYAMA, Daisuke

From: qiaonuohan <qiaonuohan(a)cn.fujitsu.com&gt; Subject: Re: [Crash-utility] Adding a new command rbtree Date: Thu, 10 May 2012 10:06:25 +0800 It seems better to me. Just one more thing: "NODE" is obvious and seems not necessary. Thanks. HATAYAMA, Daisuke