Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp45534imm; Mon, 14 May 2018 20:37:56 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqdFwwkXyBeAt8OZGdtD7Wu+8qdOObGpMnjhKrOqQAe7HCTvXGQsRnW8f0Sf/cBnogcsuzS X-Received: by 2002:a65:5042:: with SMTP id k2-v6mr6723502pgo.122.1526355476693; Mon, 14 May 2018 20:37:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526355476; cv=none; d=google.com; s=arc-20160816; b=Qi1Dm16m24oC4lmjxCaB0ALlCkPM1HnMBIUbALbvQOZDganKIwmA9EoopkI6v9q1fT 09DCkl+njgtdukfM/qJf8R4mX5o4EJv/g14ln6rJXoP9iVzI19Uf3URV6FSqOXSsDo1Q 8OD7P8N4k7qRdt///ZXCWpOgXkNSbLDqWYA3ne80n4xNSOalf30d73m8Ejuy584bC6L7 TTKGnLUMx0SJuc9bp98UwYYY+fiR6/Fi79Lu648mKgYQySh4QURTeMl2uSkVmqgmxHC4 32GksE/+VWJ0o3zZGRWSKmPF3eTHuTLW5eLeUs9L+I+UZtt9f49XLcbaeh+aTRv7rYo9 voyA== 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:arc-authentication-results; bh=unLtcFxcKZQOrGWlitVXpIXc7mIbQ5X88CClC3zkyTc=; b=EznqzTBLZC2n8kciAOO0C3DnVe+TvamIDEsBJDIF2qZvloA8MBf6EKlpEKAPyQxE3S /a8VGxj+YBg69XLfGA7kiZ7A2J0PGdVEeUo4AqejtIXVCOLqFI3BOt85X0HqlQyAZA+A /NhhGiJEHfrsefRzZRPXh6h5tkfAxryKqAe0ePDIMw+7cCk5Jtlc0r73OYvUHtNL/SYq A7LK5SDc69xTY/VKUABlLtr6BVacjVjhXApjeuEL0YNvwfUXJCCVir73KPN5xybGXa6m unEivAIs6gW2XRgYV9+2hO327pwXv0i3opkAuaynybxRECP1KW60fPB6G5OfNVbCMJ2s VcaQ== 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 t10-v6si10591081plq.547.2018.05.14.20.37.40; Mon, 14 May 2018 20:37:56 -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 S1752129AbeEODhc (ORCPT + 99 others); Mon, 14 May 2018 23:37:32 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:45518 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752054AbeEODhb (ORCPT ); Mon, 14 May 2018 23:37:31 -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 1fIQmF-0003QI-LH; Tue, 15 May 2018 11:37:27 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1fIQm8-0000QF-43; Tue, 15 May 2018 11:37:20 +0800 Date: Tue, 15 May 2018 11:37:20 +0800 From: Herbert Xu To: David Miller Cc: dave@stgolabs.net, akpm@linux-foundation.org, tgraf@suug.ch, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, dbueso@suse.de Subject: Re: [PATCH] lib/rhashtable: reorder some inititalization sequences Message-ID: <20180515033719.t2jphtfjofc5v7ag@gondor.apana.org.au> References: <20180514151332.31352-1-dave@stgolabs.net> <20180514.225213.1789810083198383905.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180514.225213.1789810083198383905.davem@davemloft.net> 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 On Mon, May 14, 2018 at 10:52:13PM -0400, David Miller wrote: > From: Davidlohr Bueso > Date: Mon, 14 May 2018 08:13:32 -0700 > > > rhashtable_init() allocates memory at the very end of the > > call, once everything is setup; with the exception of the > > nelems parameter. However, unless the user is doing something > > bogus with params for which -EINVAL is returned, memory > > allocation is the only operation that can trigger the call > > to fail. > > > > Thus move bucket_table_alloc() up such that we fail back to > > the caller asap, instead of doing useless checks. This is > > safe as the the table allocation isn't using the halfly > > setup 'ht' structure and bucket_table_alloc() call chain only > > ends up using the ht->nulls_base member in INIT_RHT_NULLS_HEAD. > > > > Also move the locking initialization down to the end. > > > > Signed-off-by: Davidlohr Bueso > > The user potentially "doing something bogus" is why the most > expensive part of the initialization (the memory allocation) > is done after everything else is validated. > > I think it's best to keep things as-is. I agree. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt