Received: by 10.213.65.68 with SMTP id h4csp114260imn; Tue, 27 Mar 2018 23:26:49 -0700 (PDT) X-Google-Smtp-Source: AIpwx48iGtUAiVNTJUIKcG8fFU+PCPp9aaCUNs5Zt3sum64SbaFmySceW5+MbOJeBD97PSqbqTtu X-Received: by 10.99.117.78 with SMTP id f14mr1645188pgn.382.1522218409926; Tue, 27 Mar 2018 23:26:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522218409; cv=none; d=google.com; s=arc-20160816; b=o8pXVMypll6ee4hPSx7qzUIri1X56u3fHhcbQySYb2MAcLgJZPzhm8BUpnR6EdrzCZ kFXqqdazJhNMBnMgxsWbCmJdyrL9eu5b6ZDXiNj+d/Wmkglx8rP+P/zh91R5sgbmXV8d /0BvETRJPo2p1yEK/6KH75a17xycvLiO/Y1Bh+SIkaWsWeA6UFvYCHSN6YjDILdTk4Ak 3NAjj+0e5qAhbmpxdO01OqlUWraY6Pr1d5PsXuV810Afx/lplurb/nMsxlfcNDjQslPO FGlOhD1ndM/on4Fz7H7PtDgyEzhrzyo3f7ztzN21dxVzd4Np9wpNcygrlc7hsw9/QS/3 67OA== 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=9B7oFHl4CkWQRACIRbvRD4AXN2oOCiiwDSlMCLjdKyg=; b=XJH9SEIfILDMxxS9jvUODmORvSZ1LM6W201Y5rEfnHa0zeUlmSEDZjcax8d6WGOaze M0C8TMllnheiLbQ5MeawBgetCZRBRbfnE9lJ4FG/Qjq0yminuGzgC+P2d0xHFB4Ocx2Z bC4X5BemHWVFhyQhNrKVQ0oKVCLapjSpO1PmFiUssV5kLijAMPGCAyY96viwlQUg4d/e AGdurI/ab2du+edLkT1Fy1VCOUeVwQRU0eE408i8vomi2C7zrHdLUsE6SsJba2Oc+SSJ +aqdS4JKIQAMN+pipBtkIRdGU46UaREjmcnu6MdlNjkydPWlP24t/wkCiENAH+qnHvZs ufoQ== 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 t14si2019810pgc.92.2018.03.27.23.26.35; Tue, 27 Mar 2018 23:26:49 -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 S1751968AbeC1GHq (ORCPT + 99 others); Wed, 28 Mar 2018 02:07:46 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:46536 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750732AbeC1GHp (ORCPT ); Wed, 28 Mar 2018 02:07:45 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtp (Exim 4.84_2 #2 (Debian)) id 1f14FE-0006i0-QD; Wed, 28 Mar 2018 14:07:36 +0800 Received: from herbert by gondobar with local (Exim 4.84_2) (envelope-from ) id 1f14FC-0004IQ-7H; Wed, 28 Mar 2018 14:07:34 +0800 Date: Wed, 28 Mar 2018 14:07:34 +0800 From: Herbert Xu To: NeilBrown Cc: Thomas Graf , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/6] rhashtable: allow a walk of the hash table without missing objects. Message-ID: <20180328060734.GB16291@gondor.apana.org.au> References: <152210688405.11435.13010923693146415942.stgit@noble> <152210718430.11435.5761213978298714527.stgit@noble> <20180327155118.GB14001@gondor.apana.org.au> <87po3p421q.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87po3p421q.fsf@notabene.neil.brown.name> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 28, 2018 at 08:54:41AM +1100, NeilBrown wrote: > > Possibly. > I particularly want the interface to require that you pass the > previously returned object to _continue. That makes it easy to see that > the object is still being used. If someone changes to code to delete > the object before the _continue, there should be a strong hint that it > won't work. > > Maybe it would be better to make it a WARN_ON() > > if (!obj || WARN_ON(iter->p != obj)) > iter->p = NULL; This doesn't really protect against the case where obj is removed. All it proves is that the user saved a copy of obj which we already did anyway. To detect an actual removal you'd need to traverse the list. I have another idea: we could save insert the walkers into the hash table chain at the end, essentially as a hidden list. We can mark it with a flag like rht_marker so that normal traversal doesn't see it. That way the removal code can simply traverse that list and inform them that the iterator is invalid. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt