Received: by 10.213.65.68 with SMTP id h4csp3078492imn; Mon, 2 Apr 2018 21:07:30 -0700 (PDT) X-Google-Smtp-Source: AIpwx499Lmup0mL5cOlZxDhFTz6ZQgwrV/F8MvOu97zcuWYEbR4EdQN+QvFWGeRLcdh7t/Y5qeVj X-Received: by 10.99.152.68 with SMTP id l4mr7827418pgo.75.1522728450583; Mon, 02 Apr 2018 21:07:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522728450; cv=none; d=google.com; s=arc-20160816; b=JXKCbxYfc6kQsKmXL66fIwBCW//4+crmIUXFTBZ9eWd2BQ3pZgbupHiH5HjbbvVkBQ T/xpd78TmJVkbTWbdxCJlZXuXOJxnFFLKsJ99mo/bM3SFqNzZ5eV3pssH0Wi9Cf6WePd a/arH6B4yy4GhOsam5d6BCaKzsrm03K+aKANFT0jxOaZ4nfVYZL8IowkHael0X6Nk3jW Fz6f4XHGyOTqKngrcUESjBUnG3LrKIyZmrSY9rczuW2F4O4+wFkUOYfUZndIqK5YzG0V gmKybcvhqrwIgoinkocQqkC6gszlZoOhqB5v0RfFywxgOS6HVYAyW9F7o2Zi6NLJNjhG Wu/A== 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=q0FellXx1CDx7iZf5n5t9RqsGROfFbgmFtl09PyMlNM=; b=EZvx/WWKOIVOF+9XYrVEbkzzK3Xmn2mLHd/wkGqGawKsMvcstIGRMzfMlGFzC4wgnt WYB1QV9bwOXw8P3tintxn+ncwhxdNoL26RL1Txl4j5QqRhsqaIuE1gLHnFbRWYNVrWyW tP0hgEErbuXacfnLcCBmucIF60t5s2LMBm3JOZ2n6VYNrA5vhAmerLXKwaPoKIkVVuQ1 GWE2v8Z9FpcK5NWomnDBA9wP3kdwMe3OemI2w94t9HEc8imHZjARIiBU9qdmWjArR2p3 EJ1i9ALuWYBswQWvPE6YEzZl8e2DgzUYLuNjYyCWENTHNFbOpi2EnkMPJ+GbUcbjyRgO 0Xng== 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 u22-v6si1985067plk.608.2018.04.02.21.06.43; Mon, 02 Apr 2018 21:07:30 -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 S1751414AbeDCEDj (ORCPT + 99 others); Tue, 3 Apr 2018 00:03:39 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:57408 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750711AbeDCEDh (ORCPT ); Tue, 3 Apr 2018 00:03:37 -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 1f3DAO-0005jc-0d; Tue, 03 Apr 2018 12:03:28 +0800 Received: from herbert by gondobar with local (Exim 4.84_2) (envelope-from ) id 1f3DAJ-0000wR-0e; Tue, 03 Apr 2018 12:03:23 +0800 Date: Tue, 3 Apr 2018 12:03:23 +0800 From: Herbert Xu To: NeilBrown Cc: Andreas Gruenbacher , cluster-devel , netdev@vger.kernel.org, LKML , Thomas Graf , Tom Herbert Subject: Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek Message-ID: <20180403040322.GB3515@gondor.apana.org.au> References: <20180329120612.6104-1-agruenba@redhat.com> <20180329123544.GA22551@gondor.apana.org.au> <20180329154153.GA23562@gondor.apana.org.au> <20180329170626.GA24218@gondor.apana.org.au> <871sfx0xeh.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871sfx0xeh.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 Tue, Apr 03, 2018 at 01:41:26PM +1000, NeilBrown wrote: > > Do we really need a rhashtable_walk_peek() interface? > I imagine that a seqfile ->start function can do: > > if (*ppos == 0 && last_pos != 0) { > rhashtable_walk_exit(&iter); > rhashtable_walk_enter(&table, &iter); > last_pos = 0; > } > rhashtable_walk_start(&iter); > if (*ppos == last_pos && iter.p) > return iter.p; > last_pos = *ppos; We don't want users poking into the internals of iter. If you're suggesting we could simplify rhashtable_walk_peek to just this after your patch then yes possibly. You also need to ensure that not only seqfs users continue to work but also netlink dump users which are slightly different. > It might be OK to have a function call instead of expecting people to > use iter.p directly. Yes that would definitely be the preferred option. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt