On Fri, Mar 16, 2007 at 01:38:31PM +0100, Robert Olsson wrote:
> 
> Hello, Just discussed this Patrick...
> 
> We have two users of trie_leaf_remove, fn_trie_flush and fn_trie_delete 
> both are holding RTNL. So there shouldn't be need for this preempt stuff. 
> This is assumed to a leftover from an older RCU-take.

True enough!  One request -- would it be reasonable to add to
trie_leaf_remove()'s comment to state that RTNL must be held
by the caller?

                                                Thanx, Paul

> > Mhh .. I think I just remembered something - me incorrectly suggesting
> > to add it there while we were talking about this at OLS :) IIRC the
> > idea was to make sure tnode_free (which at that time didn't use
> > call_rcu) wouldn't free memory while still in use in a rcu read-side
> > critical section. It should have been synchronize_rcu of course,
> > but with tnode_free using call_rcu it seems to be completely
> > unnecessary. So I guess we can simply remove it.
> 
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
> Signed-off-by: Robert Olsson <[EMAIL PROTECTED]>
> 
> Cheers.
>                                       --ro
> 
> 
> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
> --- a/net/ipv4/fib_trie.c
> +++ b/net/ipv4/fib_trie.c
> @@ -1534,7 +1534,6 @@ static int trie_leaf_remove(struct trie 
>       t->revision++;
>       t->size--;
> 
> -     preempt_disable();
>       tp = NODE_PARENT(n);
>       tnode_free((struct tnode *) n);
> 
> @@ -1544,7 +1543,6 @@ static int trie_leaf_remove(struct trie 
>               rcu_assign_pointer(t->trie, trie_rebalance(t, tp));
>       } else
>               rcu_assign_pointer(t->trie, NULL);
> -     preempt_enable();
> 
>       return 1;
>  }
> 
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to