Re: [PATCH v2 06/20] rbtree: empty nodes have no color

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3782 bytes --]

On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote:
> Empty nodes have no color.  We can make use of this property to
> simplify
> the code emitted by the RB_EMPTY_NODE and RB_CLEAR_NODE
> macros.  Also,
> we can get rid of the rb_init_node function which had been introduced
> by
> commit 88d19cf37952 ("timers: Add rb_init_node() to allow for stack
> allocated rb nodes") to avoid some issue with the empty node's color
> not
> being initialized.
> 
> I'm not sure what the RB_EMPTY_NODE checks in rb_prev() / rb_next()
> are
> doing there, though.  axboe introduced them in commit 10fd48f2376d
> ("rbtree: fixed reversed RB_EMPTY_NODE and rb_next/prev").  The way I
> see it, the 'empty node' abstraction is only used by rbtree users to
> flag nodes that they haven't inserted in any rbtree, so asking the
> predecessor or successor of such nodes doesn't make any sense.
> 
> One final rb_init_node() caller was recently added in sysctl code to
> implement faster sysctl name lookups.  This code doesn't make use of
> RB_EMPTY_NODE at all, and from what I could see it only called
> rb_init_node() under the mistaken assumption that such initialization
> was
> required before node insertion.
> 
> [sfr@canb.auug.org.au: fix net/ceph/osd_client.c build]
> Signed-off-by: Michel Lespinasse <walken@google.com>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Acked-by: David Woodhouse <David.Woodhouse@intel.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Daniel Santos <daniel.santos@pobox.com>
> Cc: Jens Axboe <axboe@kernel.dk>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Cc: John Stultz <john.stultz@linaro.org>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> [Linux commit 4c199a93a2d36b277a9fd209a0f2793f8460a215]
> 
> Ported rbtree.h and rbtree.c changes which are relevant to Xen.
> 
> Signed-off-by: Praveen Kumar <kpraveen.lkml@gmail.com>
>
I was about to say:

Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>

Although...

> diff --git a/xen/include/xen/rbtree.h b/xen/include/xen/rbtree.h
> index 3eb527eb37..f74b68ce62 100644
> --- a/xen/include/xen/rbtree.h
> +++ b/xen/include/xen/rbtree.h
> @@ -52,9 +52,12 @@ static inline void rb_set_color(struct rb_node
> *rb, int color)
>  #define RB_ROOT (struct rb_root) { NULL, }
>  #define rb_entry(ptr, type, member) container_of(ptr, type, member)
>  
> -#define RB_EMPTY_ROOT(root) ((root)->rb_node == NULL)
> -#define RB_EMPTY_NODE(node) (rb_parent(node) == node)
> -#define RB_CLEAR_NODE(node) (rb_set_parent(node, node))
> +#define RB_EMPTY_ROOT(root)  ((root)->rb_node == NULL)
> +
> +/* 'empty' nodes are nodes that are known not to be inserted in an
> rbree */
> +#define RB_EMPTY_NODE(node)  ((node)->rb_parent_color == (unsigned
> long)(node))
> +#define RB_CLEAR_NODE(node)  ((node)->rb_parent_color = (unsigned
> long)(node))
> +
> 
...There's again divergence between this patch and Linux's commit (in
this case, there is one blank line added, which is not in Linux patch).

I'm again uncertain about the severity of this, and about the best
course of action, but please, try to avoid things like this... When
reviewing patches like this, it's very hard to spot the differences,
and these only add noise, and make it even harder :-/

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel