Received: by 10.213.65.68 with SMTP id h4csp189163imn; Mon, 26 Mar 2018 18:52:59 -0700 (PDT) X-Google-Smtp-Source: AG47ELtnKBbU0ul7y89XlrAk02hmXP6ppu9CY4wQLRdUkTL1OjyuPVAXK0/zROqRiCfW1XhGUra9 X-Received: by 2002:a17:902:24c7:: with SMTP id l7-v6mr39798660plg.320.1522115579086; Mon, 26 Mar 2018 18:52:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522115579; cv=none; d=google.com; s=arc-20160816; b=ku5HZWThG7lVIoh9MlT4+xC7Q/yuwIrSmmiSNhEiUNYCniVv2ZTAmTGE1aXQTBOYIx wZ4DnxN4RMwpGUH9Fy9NYMvNUZjdp270r26VqIo6uh7czFLZz/gTL5AdEUeoISx35MmZ uX2nb17Y1w6qSFfchjjlLH5Q5ozmE33KzYnMvge+hzmELpbgthc42MBCAE93sgduGDNi 8QaVBEE3GzCJLdv1REJ+ulnnpPVFkcmBdfKhlXNquJQ/AXnvILmIUCdr3jckuR+LC1rH nJcrzoHhSzfh/+8XDtIG6B57hbzErirhdKgTXW/PDdXwTYWe9poRtzK8m/C2r6XO+DYI xgwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:cc:subject:date:to :from:arc-authentication-results; bh=6YJAaQY72xbimVgZRubd2X5MaVTcyjn6G3MmMPZJf98=; b=dAvx73ojtMWxzQ0EbHom6CcjpByztceaxJ/ttmqwEKkKvVrx4sCAY+SP7slI0qA6Kl o7QGLXqouDLiPdkhzOeAc+Df3/XGTIIXri6PX6j9GFffDjum0o1Ws+fiwP0gmB7EErCe 8fiJjKL3yXnhjNM3RRKMKrz/LozV6wf9+OnUXJvEkkSfn5LZj6drpgNTVkQfblFJ8Her ets47/rLLfuOPl6G+H5ZVfR6lYjgXNhOoC1bID5q/dLPP2H6eOBcFBq/d2rOIpqD9RMu c+9ZkQL+bygfsqoZB1ewhS/apJlBC1TLQ7blgoFq7qtLv2KutpHN020mSlbwXrgUNqPa 2TSg== 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 t16-v6si120218plo.358.2018.03.26.18.52.44; Mon, 26 Mar 2018 18:52:59 -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 S1752281AbeC0BvX (ORCPT + 99 others); Mon, 26 Mar 2018 21:51:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:38963 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752236AbeC0BvU (ORCPT ); Mon, 26 Mar 2018 21:51:20 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2AD43AE6C; Tue, 27 Mar 2018 01:51:19 +0000 (UTC) From: NeilBrown To: Thomas Graf , Herbert Xu Date: Tue, 27 Mar 2018 10:33:04 +1100 Subject: [PATCH 1/6] rhashtable: improve documentation for rhashtable_walk_peek() Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Message-ID: <152210718418.11435.11573013181393548255.stgit@noble> In-Reply-To: <152210688405.11435.13010923693146415942.stgit@noble> References: <152210688405.11435.13010923693146415942.stgit@noble> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The documentation for rhashtable_walk_peek() wrong. It claims to return the *next* entry, whereas it in fact returns the *previous* entry. However if no entries have yet been returned - or if the iterator was reset due to a resize event, then rhashtable_walk_peek() *does* return the next entry, but also advances the iterator. I suspect that this interface should be discarded and the one user should be changed to not require it. Possibly this patch should be seen as a first step in that conversation. This patch mostly corrects the documentation, but does make a small code change so that the documentation can be correct without listing too many special cases. I don't think the one user will be affected by the code change. Signed-off-by: NeilBrown --- lib/rhashtable.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/lib/rhashtable.c b/lib/rhashtable.c index 3825c30aaa36..24a57ca494cb 100644 --- a/lib/rhashtable.c +++ b/lib/rhashtable.c @@ -853,13 +853,17 @@ void *rhashtable_walk_next(struct rhashtable_iter *iter) EXPORT_SYMBOL_GPL(rhashtable_walk_next); /** - * rhashtable_walk_peek - Return the next object but don't advance the iterator + * rhashtable_walk_peek - Return the previously returned object without advancing the iterator * @iter: Hash table iterator * - * Returns the next object or NULL when the end of the table is reached. + * Returns the last object returned, or NULL if no object has yet been returned. + * If the previously returned object has since been removed, then some other arbitrary + * object maybe returned, or possibly NULL will be returned. In that case, the + * iterator might be advanced. * * Returns -EAGAIN if resize event occurred. Note that the iterator - * will rewind back to the beginning and you may continue to use it. + * will rewind back to the beginning and rhashtable_walk_next() should be + * used to get the next object. */ void *rhashtable_walk_peek(struct rhashtable_iter *iter) { @@ -880,7 +884,12 @@ void *rhashtable_walk_peek(struct rhashtable_iter *iter) * the table hasn't changed. */ iter->skip--; - } + } else + /* ->skip is only zero after rhashtable_walk_start() + * or when the iterator is reset. In this case there + * is no previous object to return. + */ + return NULL; return __rhashtable_walk_find_next(iter); }