Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     trondmy@kernel.org
Cc:     linux-nfs@vger.kernel.org
Subject: Re: [PATCH v9 03/27] NFS: Trace lookup revalidation failure
Date:   Wed, 09 Mar 2022 08:42:47 -0500
Message-ID: <638A1DDB-5424-4FFA-A5A5-D212519D3A37@redhat.com>
In-Reply-To: <20220227231227.9038-4-trondmy@kernel.org>
References: <20220227231227.9038-1-trondmy@kernel.org>
 <20220227231227.9038-2-trondmy@kernel.org>
 <20220227231227.9038-3-trondmy@kernel.org>
 <20220227231227.9038-4-trondmy@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On 24 Feb 2022, at 21:09, Trond Myklebust wrote:
> On Thu, 2022-02-24 at 09:14 -0500, Benjamin Coddington wrote:
>> There's a path through nfs4_lookup_revalidate that will now only produce
>> this exit tracepoint.  Does it need the _enter tracepoint added?
>
> You're thinking about the nfs_lookup_revalidate_delegated() path? The
> _enter() tracepoint doesn't provide any useful information that isn't
> already provided by the _exit(), AFAICS.

No, the path through nfs4_do_lookup_revalidate(), reval_dentry: jump.  But I
agree there's not much value in the _enter() tracepoint.  Maybe we can
remove it, and _exit more like _done.

I am thinking about hearing back from folks about mis-matched _enter() and
_exit() results, but also realize this is nit-picking.

Ben