Received: by 10.213.65.68 with SMTP id h4csp3062016imn; Mon, 2 Apr 2018 20:43:00 -0700 (PDT) X-Google-Smtp-Source: AIpwx49igPruDIPwhh8JgQMGZhlpvsC9sPFhybgmTj2udqfPw+20Y11FRkAEYXEKfTcOubm9B8Dt X-Received: by 2002:a17:902:8e83:: with SMTP id bg3-v6mr12648879plb.144.1522726980085; Mon, 02 Apr 2018 20:43:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522726980; cv=none; d=google.com; s=arc-20160816; b=XnqGagrhFTJrfOD7C6il8S6xhoQRc27IDAP4xAXKg+6q1B2Cu7Li4ZZi1omZyRicdf xh9FSoZg3c+OeI42QvJCO15afRp6NsydXeAqIjaF/gaDyaeiyC3wL03YGxkVqf1jAcky R1DlZMdtuaW1zKuEw6aF6jofUMYsB6bq333Uxc8cZkqnD1EMHtWMp3jOzgOy6qcqG3kW UnKos4rWkb3nXct7t3fl1tQqMS54s76RWJABqL/xR5+t0bfB6K+ILG8ka+biZa5y2Uui nYSC+IrUeb6yqTNlNSIWrFJ+uQSr8b2O7kX8g2TQr6iTHZKVywxTUACaqVWukKmFOKwq 76VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:references :in-reply-to:subject:cc:date:to:from:arc-authentication-results; bh=ddKLf9iXuSRfdCxamTuZzNI2FcRnhkWdPjWnIop9i90=; b=lOGDCBaHuTskWI7vClaoaTGxznW/2GewkeFnRqa2q0BFJ1C7QzZby0GfcW15TwufyD NF5fpSWmV/rNg4emBTxJVDh6oyBaFyYBqYotz1c5tWpbUC3MAfKojG2Hjz+NBLflcZzy U4QIoeDDAmLy+iuBc7FN2cN+0igGiFfERawawpVLYyXrZ53lTIV3HBJBM++a/Y4BZ1ag X8WQdkkTuioEYD2JYdTmp2WIofka5dmgBVMorAwODotS1tCP6YcIY/df0F8AUbekLppV UsdTzU/Xl1jhncAQ2sFg+1/sgQ43dBvNf7sqqyj+NnxU5AVpnQwDfQfyCnlxFSRhok49 8Eiw== 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 y4si1424368pfj.215.2018.04.02.20.42.45; Mon, 02 Apr 2018 20:43:00 -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 S1752973AbeDCDlj (ORCPT + 99 others); Mon, 2 Apr 2018 23:41:39 -0400 Received: from mx2.suse.de ([195.135.220.15]:58296 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751368AbeDCDli (ORCPT ); Mon, 2 Apr 2018 23:41:38 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AFAC5AF92; Tue, 3 Apr 2018 03:41:36 +0000 (UTC) From: NeilBrown To: Herbert Xu , Andreas Gruenbacher Date: Tue, 03 Apr 2018 13:41:26 +1000 Cc: cluster-devel , netdev@vger.kernel.org, LKML , Thomas Graf , Tom Herbert Subject: Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek In-Reply-To: <20180329170626.GA24218@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> Message-ID: <871sfx0xeh.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain On Fri, Mar 30 2018, Herbert Xu wrote: > On Thu, Mar 29, 2018 at 06:52:34PM +0200, Andreas Gruenbacher wrote: >> >> Should rhashtable_walk_peek be kept around even if there are no more >> users? I have my doubts. > > Absolutely. All netlink dumps using rhashtable_walk_next are buggy > and need to switch over to rhashtable_walk_peek. As otherwise > the object that triggers the out-of-space condition will be skipped > upon resumption. 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; return rhashtable_walk_next(&iter) and the ->next function just does last_pos = *ppos; *ppos += 1; do p = rhashtable_walk_next(&iter); while (IS_ERR(p)); return p; It might be OK to have a function call instead of expecting people to use iter.p directly. static inline void *rhashtable_walk_prev(struct rhashtable_iter *iter) { return iter->p; } Thoughts? Thanks, NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlrC9+cACgkQOeye3VZi gbm+Gg/9HrfwL/34+UdLALO+iHywnyIrA4C55+jnAWyMf93rosnaldFfPpWZmNgd 6DpWlPKSzDamziaxaaWOtDDIRy1ia4Ig1TgVWe0ZMrnIVqu75ffemzCVV3epHzfw 1ptFAIb0Vlgw1mLLMjcSRXgXO7NMFQV0laVFMnjeReeTBfMYoPhCx0xyTh9dISMl BLMJXpJ6ne84eXqFtMyWCvi1sBdLjK+Xw3Og4nk1spPwiFA7dhfH6VEzImlMyxrL WAD9vDiFFYjcB5wxH+gZ96wLEw2dTQmXEpcslYCQGsTaoTM1RNKfjXICetWiQO95 Jo/0rTozmtUxpcXhMfIyB9zMRpzNNLcKVgQom1tMEKhDiPAvRnfYxyfOkr9k8nd8 65sQqL6kphVRI1me+i3jgGgGdIGuobcM2AdsW2HRv79fr2JOtgkpT+8dTGTvkFHt g51fJjxKCRN3ye6XzJ5oLu32AxZOMblkoIIUK3djLJ9eeNP44DaY5t3qxBUnmxLT bat5oks/omLteabu/fj1PjWxftn2hNsEPwnPHMyylLUl7mqSH0iKdWhqxiZy49i/ ThzfzC9n8wRhBpbYd5+X7ZrJ2DWHh3TmMRiBWdpmqKn/MejLp9XMW2tRI4oI9fsA 97Vvsfi2m4kVvDPmtMmwuSuI5HDh7XMM3lrccLVaaj5cvJ4SG1I= =lo6j -----END PGP SIGNATURE----- --=-=-=--