From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Subject: Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek Date: Wed, 4 Apr 2018 11:46:28 -0400 (EDT) Message-ID: <1366548861.16037365.1522856788263.JavaMail.zimbra@redhat.com> References: <20180329120612.6104-1-agruenba@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: cluster-devel@redhat.com, Herbert Xu , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, NeilBrown , Thomas Graf , Tom Herbert To: Andreas Gruenbacher Return-path: In-Reply-To: <20180329120612.6104-1-agruenba@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org ----- Original Message ----- > Here's a second version of the patch (now a patch set) to eliminate > rhashtable_walk_peek in gfs2. > > The first patch introduces lockref_put_not_zero, the inverse of > lockref_get_not_zero. > > The second patch eliminates rhashtable_walk_peek in gfs2. In > gfs2_glock_iter_next, the new lockref function from patch one is used to > drop a lockref count as long as the count doesn't drop to zero. This is > almost always the case; if there is a risk of dropping the last > reference, we must defer that to a work queue because dropping the last > reference may sleep. > > Thanks, > Andreas > > Andreas Gruenbacher (2): > lockref: Add lockref_put_not_zero > gfs2: Stop using rhashtable_walk_peek > > fs/gfs2/glock.c | 47 ++++++++++++++++++++++++++++------------------- > include/linux/lockref.h | 1 + > lib/lockref.c | 28 ++++++++++++++++++++++++++++ > 3 files changed, 57 insertions(+), 19 deletions(-) > > -- > 2.14.3 Hi, The patches look good. The big question is whether to add them to this merge window while it's still open. Opinions? Acked-by: Bob Peterson Regards, Bob Peterson