From mboxrd@z Thu Jan 1 00:00:00 1970 From: Herbert Xu Subject: Re: [PATCH net-next 1/5] rhashtable: Don't reset walker table in rhashtable_walk_start Date: Sat, 2 Dec 2017 09:18:09 +1100 Message-ID: <20171201221809.GA6972@gondor.apana.org.au> References: <20171201000305.2392-1-tom@quantonium.net> <20171201000305.2392-2-tom@quantonium.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: davem@davemloft.net, netdev@vger.kernel.org, rohit@quantonium.net To: Tom Herbert Return-path: Received: from [128.1.224.119] ([128.1.224.119]:41752 "EHLO ringil.hmeau.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1750921AbdLAWST (ORCPT ); Fri, 1 Dec 2017 17:18:19 -0500 Content-Disposition: inline In-Reply-To: <20171201000305.2392-2-tom@quantonium.net> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Nov 30, 2017 at 04:03:01PM -0800, Tom Herbert wrote: > Remove the code that resets the walker table. The walker table should > only be initialized in the walk init function or when a future table is > encountered. If the walker table is NULL this is the indication that > the walk has completed and this information can be used to break a > multi-call walk in the table (e.g. successive calls to nelink_dump > that are dumping elements of an rhashtable). > > This also allows us to change rhashtable_walk_start to return void > since the only error it was returning was -EAGAIN for a table change. > This patch changes all the callers of rhashtable_walk_start to expect > void which eliminates logic needed to check the return value for a > rare condition. Note that -EAGAIN will be returned in a call > to rhashtable_walk_next which seems to always follow the start > of the walk so there should be no behavioral change in doing this. > > Signed-off-by: Tom Herbert Doesn't this mean that if a walk encounters a rehash you may end up missing half or more of the hash table? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt