All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ying Xue <ying.xue@windriver.com>
To: Thomas Graf <tgraf@suug.ch>, <davem@davemloft.net>
Cc: tipc-discussion@lists.sourceforge.net, Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] rhashtable: rhashtable_remove() must unlink in both tbl and future_tbl
Date: Wed, 21 Jan 2015 16:39:30 +0800	[thread overview]
Message-ID: <54BF65C2.9010404@windriver.com> (raw)
In-Reply-To: <20150120165826.GK20315@casper.infradead.org>

On 01/21/2015 12:58 AM, Thomas Graf wrote:
> As removals can occur during resizes, entries may be referred to from
> both tbl and future_tbl when the removal is requested. Therefore
> rhashtable_remove() must unlink the entry in both tables if this is
> the case. The existing code did search both tables but stopped when it
> hit the first match.
> 
> Failing to do so resulted in use after remove.
> 
> Fixes: 97defe1 ("rhashtable: Per bucket locks & deferred expansion/shrinking")
> Reported-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> ---
> 
> Ying: This should fix the panic that was at the end of your TIPC
>       related boot log. I'm still working on the use after free.
> 

Your below changes are reasonable for me. But after I applied the patch,
my reported two issues still happened :( And failure logs are completely
same before.

Regards,
Ying

>  lib/rhashtable.c | 24 +++++++++++++++---------
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
> index a4449c4..b1aa10e 100644
> --- a/lib/rhashtable.c
> +++ b/lib/rhashtable.c
> @@ -592,6 +592,7 @@ bool rhashtable_remove(struct rhashtable *ht, struct rhash_head *obj)
>  	struct rhash_head *he;
>  	spinlock_t *lock;
>  	unsigned int hash;
> +	bool ret = false;
>  
>  	rcu_read_lock();
>  	tbl = rht_dereference_rcu(ht->tbl, ht);
> @@ -609,17 +610,16 @@ restart:
>  		}
>  
>  		rcu_assign_pointer(*pprev, obj->next);
> -		atomic_dec(&ht->nelems);
> -
> -		spin_unlock_bh(lock);
> -
> -		rhashtable_wakeup_worker(ht);
> -
> -		rcu_read_unlock();
>  
> -		return true;
> +		ret = true;
> +		break;
>  	}
>  
> +	/* The entry may be linked in either 'tbl', 'future_tbl', or both.
> +	 * 'future_tbl' only exists for a short period of time during
> +	 * resizing. Thus traversing both is fine and the added cost is
> +	 * very rare.
> +	 */
>  	if (tbl != rht_dereference_rcu(ht->future_tbl, ht)) {
>  		spin_unlock_bh(lock);
>  
> @@ -632,9 +632,15 @@ restart:
>  	}
>  
>  	spin_unlock_bh(lock);
> +
> +	if (ret) {
> +		atomic_dec(&ht->nelems);
> +		rhashtable_wakeup_worker(ht);
> +	}
> +
>  	rcu_read_unlock();
>  
> -	return false;
> +	return ret;
>  }
>  EXPORT_SYMBOL_GPL(rhashtable_remove);
>  
> 


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

  parent reply	other threads:[~2015-01-21  8:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-19  8:03 [3.19.0-rc4+] rhashtable: BUG kmalloc-2048 (Not tainted): Poison overwritten Ying Xue
2015-01-19 12:59 ` Thomas Graf
2015-01-20  2:53   ` Ying Xue
2015-01-20 16:58     ` [PATCH net-next] rhashtable: rhashtable_remove() must unlink in both tbl and future_tbl Thomas Graf
2015-01-20 18:44       ` Sergei Shtylyov
2015-01-21 11:54         ` [PATCH net-next v2] " Thomas Graf
2015-01-26 19:57           ` David Miller
2015-01-21  8:39       ` Ying Xue [this message]
2015-01-21 11:56         ` [PATCH net-next] " Thomas Graf
2015-01-30  8:37           ` Ying Xue
2015-01-21  8:51       ` Ying Xue

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=54BF65C2.9010404@windriver.com \
    --to=ying.xue@windriver.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=tgraf@suug.ch \
    --cc=tipc-discussion@lists.sourceforge.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.