public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] inetpeer: Don't disable BH for initial fast RCU lookup.
Date: Sun, 13 Mar 2011 11:04:09 +0100	[thread overview]
Message-ID: <1300010649.2761.3.camel@edumazet-laptop> (raw)
In-Reply-To: <20110308.145954.59682618.davem@davemloft.net>

Le mardi 08 mars 2011 à 14:59 -0800, David Miller a écrit :
> If modifications on other cpus are ok, then modifications to
> the tree during lookup done by the local cpu are ok too.
> 
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>  net/ipv4/inetpeer.c |   18 +++++++++---------
>  1 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
> index f604ffd..6442c35 100644
> --- a/net/ipv4/inetpeer.c
> +++ b/net/ipv4/inetpeer.c
> @@ -206,16 +206,16 @@ static int addr_compare(const struct inetpeer_addr *a,
>  })
>  
>  /*
> - * Called with rcu_read_lock_bh()
> + * Called with rcu_read_lock()
>   * Because we hold no lock against a writer, its quite possible we fall
>   * in an endless loop.
>   * But every pointer we follow is guaranteed to be valid thanks to RCU.
>   * We exit from this function if number of links exceeds PEER_MAXDEPTH
>   */
> -static struct inet_peer *lookup_rcu_bh(const struct inetpeer_addr *daddr,
> -				       struct inet_peer_base *base)
> +static struct inet_peer *lookup_rcu(const struct inetpeer_addr *daddr,
> +				    struct inet_peer_base *base)
>  {
> -	struct inet_peer *u = rcu_dereference_bh(base->root);
> +	struct inet_peer *u = rcu_dereference(base->root);
>  	int count = 0;
>  
>  	while (u != peer_avl_empty) {
> @@ -231,9 +231,9 @@ static struct inet_peer *lookup_rcu_bh(const struct inetpeer_addr *daddr,
>  			return u;
>  		}
>  		if (cmp == -1)
> -			u = rcu_dereference_bh(u->avl_left);
> +			u = rcu_dereference(u->avl_left);
>  		else
> -			u = rcu_dereference_bh(u->avl_right);
> +			u = rcu_dereference(u->avl_right);
>  		if (unlikely(++count == PEER_MAXDEPTH))
>  			break;
>  	}
> @@ -470,11 +470,11 @@ struct inet_peer *inet_getpeer(struct inetpeer_addr *daddr, int create)
>  	/* Look up for the address quickly, lockless.
>  	 * Because of a concurrent writer, we might not find an existing entry.
>  	 */
> -	rcu_read_lock_bh();
> +	rcu_read_lock();
>  	sequence = read_seqbegin(&base->lock);
> -	p = lookup_rcu_bh(daddr, base);
> +	p = lookup_rcu(daddr, base);
>  	invalidated = read_seqretry(&base->lock, sequence);
> -	rcu_read_unlock_bh();
> +	rcu_read_unlock();
>  
>  	if (p) {
>  		/* The existing node has been found.

David, I am not sure this is safe, since we use call_rcu_bh() when
freeing one item. One cpu could decide to kfree() one item while another
cpu could still use it.

rcu_read_lock_bh() was signalling to others cpu we were in a softirq
section, so we were delaying a possible kfree().




  reply	other threads:[~2011-03-13 10:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-08 22:59 [PATCH] inetpeer: Don't disable BH for initial fast RCU lookup David Miller
2011-03-13 10:04 ` Eric Dumazet [this message]
2011-03-13 23:42   ` David Miller
2011-03-14  4:15     ` [PATCH net-next-2.6] inetpeer: should use call_rcu() variant Eric Dumazet
2011-03-14  6:22       ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1300010649.2761.3.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox