Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp280053imu; Mon, 10 Dec 2018 21:47:46 -0800 (PST) X-Google-Smtp-Source: AFSGD/W8xtWVETYmrDwTT29fdnrzOxG0rJLFojRrXRuJxzw0/LmI7i5JKeK/dpRVp/xpvms24PZT X-Received: by 2002:a63:2744:: with SMTP id n65mr13345801pgn.65.1544507266326; Mon, 10 Dec 2018 21:47:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544507266; cv=none; d=google.com; s=arc-20160816; b=xHBucoHjWQcCZBT8HvENDquPWXX9axirSz3jSFoS0hi/k7GZQ+27fnnXtiI2gStWgq t3CbqCSEjE9XDH9uB004SlC0EWxz0lNg3UtuxhkJbirCDVxlC+A7tQTgg/b5zEir6T9k 1tYaHf35ag8kQc/+EInUEl5solHbVCmeiaJ5zMDjH123rH8BzSY5UQZT1hrWj2JyL5r1 vuEHsgMcjEjRfhGd08W2/VIb/sh6gfUHc9du7fHBZ2wycdkA+thbgX5hSJq7o5ZsT3yU T6M9Bqs5PWC3yZscbk2ladgz8v7hGbwlVo8r3awiuLVR1/pelak43lhSMZujyjgPo3RK a0fA== 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=7UHm8Rjp8rR27+OqVSbOzMxm7xaibLdFYQafQFKCdDY=; b=vEnUFI7qGL01gg/201cTSLaNOMx36K1CxXlnHxcwdVA0KV59KPtVHVXSMHXYy9ItUc otatb/DghnrpNBQyUo9npM/ckqyJqFOLfXRGajaZMTp/U/hCUw3w2/YSScYsCkMNJLuv bY5MNicTs6IoOsY8nzGNcE09GzEZLTv0MQ5eJlmaIcdMM90E1OwE9yUZU1LCKJpAWhfH Ddw+JXQn3PzS9E/2pDnkhnxlLbyhcOwgsDBTBFVP3fpDkFhKggCa0gDIRWUamNkfPTcE 5+Aluuiidl+yWaqlakWL+r0MTNhxPeG1m+EcM2X6s9lRvJweZR38jd/XKewnQHqRYkQ9 8+RQ== 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 f24si10679113pgj.315.2018.12.10.21.47.30; Mon, 10 Dec 2018 21:47:46 -0800 (PST) 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 S1728974AbeLKFSI (ORCPT + 99 others); Tue, 11 Dec 2018 00:18:08 -0500 Received: from orcrist.hmeau.com ([104.223.48.154]:43262 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725993AbeLKFSH (ORCPT ); Tue, 11 Dec 2018 00:18:07 -0500 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 1gWaQi-0004PB-IA; Tue, 11 Dec 2018 13:18:00 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1gWaQd-0002U4-9j; Tue, 11 Dec 2018 13:17:55 +0800 Date: Tue, 11 Dec 2018 13:17:55 +0800 From: Herbert Xu To: NeilBrown Cc: Thomas Graf , Tom Herbert , David Miller , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next] rhashtable: further improve stability of rhashtable_walk Message-ID: <20181211051755.modgomqzszkbiihe@gondor.apana.org.au> References: <153086101070.2825.6850140624411927465.stgit@noble> <153086109256.2825.15329014177598382684.stgit@noble> <87zhtkeimx.fsf@notabene.neil.brown.name> <20181207053943.7zacyn5uvqkfnfoi@gondor.apana.org.au> <87k1kico1o.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k1kico1o.fsf@notabene.neil.brown.name> 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 Mon, Dec 10, 2018 at 09:50:43AM +1100, NeilBrown wrote: > I think it was agreed that I would not pursue features that were only > of use to out-of-tree code, but I don't think that applies here. This > is not a feature, this is a quality-of-implementation improvement. > There are users in the kernel today which use > rhashtable_walk_stop()/rhashtable_walk_start() > to drop out of RCU protection for periods during the walk. > Any such user might miss seeing an object that has been in the table > for a while - sure that is less than optimal, and should be fixed if > the cost is small. > > There are currently no rhlist users which use stop/start to drop out > of RCU, so there is no clear value in fixing that case, or cost in not > fixing it. I think the complexities of this patch outweighs any benefit. Walking an rhashtable is inherently unreliable, due to rehashing. If you need an 100% reliable walking mechanism, then add your own linked list alongside the hash table like xfrm does. Having said that, if the current code is missing items that existed prior to the start of the walk (in the absence of a rehash) then that would be a bug that we should fix. Anything else like duplicates just needs to be accepted by the caller. So please explain how can an object be missed then we can work on fixing that and that only. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt