Received: by 2002:ac0:a874:0:0:0:0:0 with SMTP id c49csp128547ima; Thu, 14 Mar 2019 22:13:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqwQ8OCNwt8DOdSIsScpo2w1gPRPgw21tcLUcscZhtuN/qKfYo/cbOSqVYp/g2xYpW3ylGei X-Received: by 2002:a63:6c43:: with SMTP id h64mr1553426pgc.22.1552626783772; Thu, 14 Mar 2019 22:13:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552626783; cv=none; d=google.com; s=arc-20160816; b=NTJ80pAgMqRf6wxNSZChXGztFtubSba33ToIVVuTU5JWWIsLoaf/HOW7q8obNZ7jnE ZkGKTsZoCoWE1zLcVH4ypfynYC9I7U8xn74sMNdOIkCaX1nJVCwPXB+JgYDdUvL9RoBU bWm5j64h22qVaqvkYM1NwILPWrk38IynNOgdSEKQr+RMIrdfxBgG6rKpY12lBYGzSo+D daUUjK2HEu3RglbkFa5MtUV9B7y86ZBlZvFPOJEybktGOhmGnneQaCMoSm7pOoih1Ewe hQHSFnvKShDpD/jyPHdrH+lIP6I5Mecyji7pwOCdWPYk6Brk9yKeyigxsRJajRVl4SEH ysKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=AACzrE6Y6zsWTME8FEgNcS6onEvSwTq/xmAlaIKBQ+8=; b=LROATayA0d/IOe4O50lP3xn/HHzylf8Aiw2kS4GIZTNZWBa/pLpnmMYs+0WS4EMr0W smX32RSSWEZTi/71e1o8TDlI4ArTbW3ynhPIA9n7lj2zRQQg4I2J57EDBgjj9Xvy/VYX XbS3QDDLLC98Dfw+9hAdG3pExgfgchdOeEdLa86pYnmthnlocHAkriVsJY0NzWcBLBbI GIkd7jaR1YHhfFCTJFdg/4t9HFkOC5rauJkQEd9Q2KF2GfpQxMVsHHgI/cvXeedxQE/I BS0iTSC6xeL/1rGUBZ9hax8zucLI6ENh42G0yt0FaqTs+XtG/NzK6HSd3dmGkGNhA3vj OBTQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y8si996970pgr.109.2019.03.14.22.12.44; Thu, 14 Mar 2019 22:13:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727796AbfCOFKt (ORCPT + 99 others); Fri, 15 Mar 2019 01:10:49 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:51656 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726920AbfCOFKt (ORCPT ); Fri, 15 Mar 2019 01:10:49 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1h4f76-0006Y1-U4; Fri, 15 Mar 2019 13:10:36 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1h4f6z-0000Ud-G0; Fri, 15 Mar 2019 13:10:29 +0800 Date: Fri, 15 Mar 2019 13:10:29 +0800 From: Herbert Xu To: NeilBrown Cc: Thomas Graf , netdev@vger.kernel.org, "Paul E. McKenney" , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] rhashtable: use cmpxchg() in nested_table_alloc() Message-ID: <20190315051029.waqb3ohztl7w6zep@gondor.apana.org.au> References: <155253979234.5022.1840929790507376038.stgit@noble.brown> <155253992824.5022.10318044793639169265.stgit@noble.brown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <155253992824.5022.10318044793639169265.stgit@noble.brown> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Neil: On Thu, Mar 14, 2019 at 04:05:28PM +1100, NeilBrown wrote: > nested_table_alloc() relies on the fact that there is > at most one spinlock allocated for every slot in the top > level nested table, so it is not possible for two threads > to try to allocate the same table at the same time. > > This assumption is a little fragile (it is not explicit) and is > unnecessary. We can instead protect against > a race using cmpxchg() - if it the cmp fails, free the table > that was just allocated. > > Signed-off-by: NeilBrown > --- > lib/rhashtable.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) You probably explained it to me before but it's been long enough that I no longer remember why we need this change. So please explain in the commit log why this change is needed. Because on the face of it you are adding locking/sychronisation and not taking it away. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt