Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751709AbbLQRA3 (ORCPT ); Thu, 17 Dec 2015 12:00:29 -0500 Received: from shards.monkeyblade.net ([149.20.54.216]:54453 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751348AbbLQRA0 (ORCPT ); Thu, 17 Dec 2015 12:00:26 -0500 Date: Thu, 17 Dec 2015 12:00:24 -0500 (EST) Message-Id: <20151217.120024.1598833629356298916.davem@davemloft.net> To: lucien.xin@gmail.com Cc: herbert@gondor.apana.org.au, phil@nwl.cc, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, tgraf@suug.ch, fengguang.wu@intel.com, wfg@linux.intel.com, lkp@01.org Subject: Re: rhashtable: Prevent spurious EBUSY errors on insertion From: David Miller In-Reply-To: References: <20151217084809.GC9239@gondor.apana.org.au> X-Mailer: Mew version 6.6 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 17 Dec 2015 09:00:25 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1313 Lines: 36 From: Xin Long Date: Thu, 17 Dec 2015 17:00:35 +0800 > On Thu, Dec 17, 2015 at 4:48 PM, Herbert Xu wrote: >> On Thu, Dec 17, 2015 at 04:46:00PM +0800, Xin Long wrote: >>> >>> sorry for late test, but unfortunately, my case with rhashtalbe still >>> return EBUSY. >>> I added some debug code in rhashtable_insert_rehash(), and found: >>> *future_tbl is null* >>> >>> fail: >>> /* Do not fail the insert if someone else did a rehash. */ >>> if (likely(rcu_dereference_raw(tbl->future_tbl))) { >>> printk("future_tbl is there\n"); >>> return 0; >>> } else { >>> printk("future_tbl is null\n"); >>> } >>> >>> any idea why ? >> >> That's presumably because you got a genuine double rehash. >> >> Until you post your code we can't really help you. >> > i wish i could , but my codes is a big patch for sctp, and this issue > happens in a special stress test based on this patch. > im trying to think how i can show you. :) Simply post it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/