[Crash-utility] Adding a new command rbtree

[Dave Anderson]

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