Re: [PATCH] efivarfs: Suppress false-positive kmemleak warning for sfi

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2025-07-16 at 04:45 -0700, Breno Leitao wrote:
> On Wed, Jul 16, 2025 at 10:41:24AM +1000, Ard Biesheuvel wrote:
> > On Tue, 15 Jul 2025 at 19:31, Breno Leitao <leitao@debian.org>
> > wrote:
> > > 
> > > When kmemleak is enabled, it incorrectly reports the sfi
> > > structure allocated during efivarfs_init_fs_context() as leaked:
> > > 
> > >     unreferenced object 0xffff888146250b80 (size 64):
> > >     __kmalloc_cache_noprof
> > >     efivarfs_init_fs_context
> > >     ...
> > > 
> > > On module unload, this object is freed in efivarfs_kill_sb(),
> > > confirming no actual leak. Also, kfree(sfi) is called at
> > > efivarfs_kill_sb(). I am not able to explain why kmemleak
> > > detected it as a leak. To silence this false-positive, mark the
> > > sfi allocation as ignored by kmemleak right after allocation.
> > > 
> > > This ensures clearer leak diagnostics for this allocation path.
> > > 
> > 
> > Can you provide a reproducer? x86 defconfig with kmemleak enabled
> > does not show this behavior.
> 
> I see this problem all the time when mounting efivars. This is the
> config I am using: https://pastebin.com/i21Yv0jt

Actually, there is a way this could be happening: to process the
options, we have to allocate sfi early when the fs_context is
initialized, but it is actually a property of the superblock and is
freed when the superblock is killed.  If we got a situation where
something did a final put of the fs context before we get to fill_super
(which is where the handover happens) we would leak sfi's.  This would
have to be on an error leg I presume (or possibly a reconfigure looking
at the code).

If the theory is correct, the leak is genuine and we need to implement
.free in efivarfs_context_ops to fix it.

Regards,

James