Received: by 10.213.65.68 with SMTP id h4csp1481349imn; Thu, 29 Mar 2018 05:37:18 -0700 (PDT) X-Google-Smtp-Source: AIpwx49qem5BvPXsySfIsg4FHS0IWCrRU2ifd1tnopJ+3S8JOaj2jNJByeYj4t9RyVFGG9drGfBQ X-Received: by 2002:a17:902:720a:: with SMTP id ba10-v6mr8252134plb.294.1522327038189; Thu, 29 Mar 2018 05:37:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522327038; cv=none; d=google.com; s=arc-20160816; b=yb8eSzUCpNwzCznLYCKVZeQ3xyI1z6tm1zDm58onKM0YGjsfrH38dTSy7PWImaqAsE SNDh7UdLbJkLmbKOKKPFrHUiDvNf/AvXubHNRgPsOHjavy5EIHCBwqkaUckH/ssrhWP/ uthkg8/tYUzAaSNp58BLyXxp0PYeZpggrdjalmvKSEJ0nL1FwozliyJZJGpxXkaL9ILW mOCI/UztR3TJfsVITUJYcdiQ+dYWstCgMEEbTiu7JFTZlDr+lrFTIqMcXPHLFCnEN20V JHFIAeSW7FE7bLWhLM2Mqr6oUTy2Jv1ccr6sKa2JvLumJcng8gqCAn6N/wgMU5jZ8yob C+bA== 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=uv3orCNefjWbkYEdb8CzHPOF4y7H2fofPJrMBMF2rpg=; b=0GaByjpMp9Zd/Y1a1ErQVQijJR2bK/CSs/NpXQmSJBXkRxdEgsfNkRC7w+Ws2G58mF fJ10H2bxpGTECqLTqHilEghjrnND8qq1Z5PTpFKti0rZwUoa6Z4msnrIsX97yAEI/C5/ QzeIZ8C3q1aMcEJAnmOF3DKKqKIZisCV6Yf1mQEGn7+ZTxSYU5BIwoXYB67azA90Uo1I bUn8xuQlLMovkFt2/uhZ+LiferYNw0isDQKexgWPyLJ0VO4UGlkgX3LC0yaXxSGIzLMz O5zkSoRCK+lStSDUit8QKlPn/zszfHgY4/c0iFq1aq3GEKlYSy8OqH3ilZaIuJL06PQl C9+Q== 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 y3si3913724pgc.601.2018.03.29.05.37.02; Thu, 29 Mar 2018 05:37:18 -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 S1752495AbeC2Mfz (ORCPT + 99 others); Thu, 29 Mar 2018 08:35:55 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:49850 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751927AbeC2Mfy (ORCPT ); Thu, 29 Mar 2018 08:35:54 -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 1f1WmS-00053J-O2; Thu, 29 Mar 2018 20:35:48 +0800 Received: from herbert by gondobar with local (Exim 4.84_2) (envelope-from ) id 1f1WmO-0005vI-Du; Thu, 29 Mar 2018 20:35:44 +0800 Date: Thu, 29 Mar 2018 20:35:44 +0800 From: Herbert Xu To: Andreas Gruenbacher Cc: cluster-devel@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, NeilBrown , Thomas Graf , Tom Herbert Subject: Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek Message-ID: <20180329123544.GA22551@gondor.apana.org.au> References: <20180329120612.6104-1-agruenba@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180329120612.6104-1-agruenba@redhat.com> 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 Thu, Mar 29, 2018 at 02:06:10PM +0200, Andreas Gruenbacher wrote: > 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. In light of Neil's latest patch, do we still need this? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt