Unused event xfs_growfs_check_rtgeom

Unused event xfs_growfs_check_rtgeom

[Steven Rostedt]

I have code that will cause a warning if a trace event or tracepoint is
created but not used. Trace events can take up to 5K of memory in text
and meta data per event. There's a lot of events in the XFS file system
that are not used, but one in particular was added by commit
59a57acbce282 ("xfs: check that the rtrmapbt maxlevels doesn't increase
when growing fs"). That event is xfs_growfs_check_rtgeom, but it was
never called.

It looks like it was just an oversight. I'm holding off from deleting
it as it may still be valid but just never been added. It was added
relatively recently.

-- Steve

Re: Unused event xfs_growfs_check_rtgeom

[Steven Rostedt]

I also found events: xfs_metadir_link and xfs_metadir_start_link are
defined in fs/xfs/libxfs/xfs_metadir.c in a #ifndef __KERNEL__ section.

Are these events ever used? Why are they called in !__KERNEL__ code?

-- Steve

Re: Unused event xfs_growfs_check_rtgeom

[Darrick J. Wong]

On Thu, Jun 12, 2025 at 01:16:51PM -0400, Steven Rostedt wrote:
> I also found events: xfs_metadir_link and xfs_metadir_start_link are
> defined in fs/xfs/libxfs/xfs_metadir.c in a #ifndef __KERNEL__ section.
> 
> Are these events ever used? Why are they called in !__KERNEL__ code?

libxfs is shared with userspace, and xfs_repair uses them to relink old
quota files.

--D

> -- Steve

Re: Unused event xfs_growfs_check_rtgeom

[Darrick J. Wong]

On Thu, Jun 12, 2025 at 01:10:21PM -0400, Steven Rostedt wrote:
> I have code that will cause a warning if a trace event or tracepoint is
> created but not used. Trace events can take up to 5K of memory in text
> and meta data per event. There's a lot of events in the XFS file system
> that are not used, but one in particular was added by commit
> 59a57acbce282 ("xfs: check that the rtrmapbt maxlevels doesn't increase
> when growing fs"). That event is xfs_growfs_check_rtgeom, but it was
> never called.
> 
> It looks like it was just an oversight. I'm holding off from deleting
> it as it may still be valid but just never been added. It was added
> relatively recently.

Yes that's a bug.  Will send a fix shortly.

--D

> -- Steve

Re: Unused event xfs_growfs_check_rtgeom

[Steven Rostedt]

On Thu, 12 Jun 2025 10:47:37 -0700
"Darrick J. Wong" <djwong@kernel.org> wrote:

> On Thu, Jun 12, 2025 at 01:16:51PM -0400, Steven Rostedt wrote:
> > I also found events: xfs_metadir_link and xfs_metadir_start_link are
> > defined in fs/xfs/libxfs/xfs_metadir.c in a #ifndef __KERNEL__ section.
> > 
> > Are these events ever used? Why are they called in !__KERNEL__ code?  
> 
> libxfs is shared with userspace, and xfs_repair uses them to relink old
> quota files.
>

Does this userspace use these trace events? If so, I think the events
need to have an:

 #ifndef __KERENL__

around them too.

-- Steve

Re: Unused event xfs_growfs_check_rtgeom

[Steven Rostedt]

On Thu, 12 Jun 2025 10:47:58 -0700
"Darrick J. Wong" <djwong@kernel.org> wrote:

> On Thu, Jun 12, 2025 at 01:10:21PM -0400, Steven Rostedt wrote:
> > I have code that will cause a warning if a trace event or tracepoint is
> > created but not used. Trace events can take up to 5K of memory in text
> > and meta data per event. There's a lot of events in the XFS file system
> > that are not used, but one in particular was added by commit
> > 59a57acbce282 ("xfs: check that the rtrmapbt maxlevels doesn't increase
> > when growing fs"). That event is xfs_growfs_check_rtgeom, but it was
> > never called.
> > 
> > It looks like it was just an oversight. I'm holding off from deleting
> > it as it may still be valid but just never been added. It was added
> > relatively recently.  
> 
> Yes that's a bug.  Will send a fix shortly.
> 

Hmm, this looks like another event that may have been forgotten to be added:

  xfs_discard_rtrelax

It was added by 3ba3ab1f671 ("xfs: enable FITRIM on the realtime
device") but never called.

As well as event xfs_log_cil_return which was added by c1220522ef4
("xfs: grant heads track byte counts, not LSNs")

And in commit defee8dff2b2 ("xfs: online repair of realtime bitmaps for
a realtime group"), the following events were added but not used:

  xrep_rtbitmap_load
  xrep_rtbitmap_load_word
  xrep_rtbitmap_load_words

Commit e6c9e75fbe79 ("xfs: move files to orphanage instead of letting
nlinks drop to zero") Added:

  xrep_nlinks_set_record

Commit dbbdbd00863 ("xfs: repair problems in CoW forks") added:

  xrep_cow_free_staging

I'll be sending patches that removes or hides other events that are no
longer used.

-- Steve

  


-- Steve

Re: Unused event xfs_growfs_check_rtgeom

[Christoph Hellwig]

On Thu, Jun 12, 2025 at 02:46:08PM -0400, Steven Rostedt wrote:
> On Thu, 12 Jun 2025 10:47:37 -0700
> "Darrick J. Wong" <djwong@kernel.org> wrote:
> 
> > On Thu, Jun 12, 2025 at 01:16:51PM -0400, Steven Rostedt wrote:
> > > I also found events: xfs_metadir_link and xfs_metadir_start_link are
> > > defined in fs/xfs/libxfs/xfs_metadir.c in a #ifndef __KERNEL__ section.
> > > 
> > > Are these events ever used? Why are they called in !__KERNEL__ code?  
> > 
> > libxfs is shared with userspace, and xfs_repair uses them to relink old
> > quota files.
> >
> 
> Does this userspace use these trace events? If so, I think the events
> need to have an:

They have stubs for them.

Re: Unused event xfs_growfs_check_rtgeom

[Steven Rostedt]

On Thu, 12 Jun 2025 22:59:47 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> On Thu, Jun 12, 2025 at 02:46:08PM -0400, Steven Rostedt wrote:
> > On Thu, 12 Jun 2025 10:47:37 -0700
> > "Darrick J. Wong" <djwong@kernel.org> wrote:
> >   
> > > On Thu, Jun 12, 2025 at 01:16:51PM -0400, Steven Rostedt wrote:  
> > > > I also found events: xfs_metadir_link and xfs_metadir_start_link are
> > > > defined in fs/xfs/libxfs/xfs_metadir.c in a #ifndef __KERNEL__ section.
> > > > 
> > > > Are these events ever used? Why are they called in !__KERNEL__ code?    
> > > 
> > > libxfs is shared with userspace, and xfs_repair uses them to relink old
> > > quota files.
> > >  
> > 
> > Does this userspace use these trace events? If so, I think the events
> > need to have an:  
> 
> They have stubs for them.

If user space only has stubs for them, then why do they exist? The call
to this tracepoints are within #ifndef __KERNEL__ so the kernel will
never call them. Or can the user space stubs be replaced by actual content?

Either case, the events in the header file should be hidden from the kernel.

-- Steve