All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com>
Cc: julia.lawall@inria.fr, Julian Braha <julianbraha@gmail.com>,
	outreachy@lists.linux.dev
Subject: Re: Clarification on NFS Tracepoint Build Warnings
Date: Sat, 24 Oct 2026 17:42:35 -0400	[thread overview]
Message-ID: <20261024174235.2d88f87f@fedora> (raw)
In-Reply-To: <atzinx9DDgmOwOEw@user>

On Sat, 24 Oct 2026 22:23:51 +0530
Yalagada Pavan Kumar <pavankumaryalagada@gmail.com> wrote:

> Hi Julia,
> 
> Using the attached configuration [1], i encountered few tracepoint warnings
> during the kernel build. I focused on these three NFS warnings:
> 
> warning: tracepoint 'nfs_local_open_fh' is unused in module fs/nfs/nfs.o
> warning: tracepoint 'nfs_atomic_open_exit' is unused in module fs/nfs/nfs.o
> warning: tracepoint 'nfs_atomic_open_enter' is unused in module fs/nfs/nfs.o
> 


> Could you please let me know whether my understanding is correct and whether
> guarding the tracepoint definition with CONFIG_NFS_LOCALIO is the apprpriate
> fix?

You are correct. Each warning may require a different fix. The
nfs_local_open_fh was not used because CONFIG_NFS_LOCALIO was not
enabled, and the TRACE_EVENT() macro should be guarded by that as your
patch does.

The nfs_atomic_open_exit/exit tracepoints are called in fs/nfs/dir.c
and if you see where they are used, there is:

#if IS_ENABLED(CONFIG_NFS_V4)

Around the use cases of the callers of the tracepoint. Your config
doesn't have that set, which is why they were not used. The solution
for those is to protect the TRACE_EVENT() definitions of those
tracepoints with the guard above.

-- Steve



      reply	other threads:[~2026-10-24 21:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-24 16:53 Clarification on NFS Tracepoint Build Warnings Yalagada Pavan Kumar
2026-10-24 21:42 ` Steven Rostedt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261024174235.2d88f87f@fedora \
    --to=rostedt@goodmis.org \
    --cc=julia.lawall@inria.fr \
    --cc=julianbraha@gmail.com \
    --cc=outreachy@lists.linux.dev \
    --cc=pavankumaryalagada@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.