mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Breno Leitao <leitao@debian.org>
Cc: Ard Biesheuvel <ardb@kernel.org>, Jeremy Kerr <jk@ozlabs.org>,
	 linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@meta.com
Subject: Re: [PATCH] efivarfs: Suppress false-positive kmemleak warning for sfi
Date: Wed, 16 Jul 2025 09:26:03 -0400	[thread overview]
Message-ID: <ec0a66f40bc826bd016f338568e01908b86be35a.camel@HansenPartnership.com> (raw)
In-Reply-To: <qdw7skjlcw6dvnewpfrtxc27pm7sroan5eyn53exndehp3blav@z25oqkoo3ohw>

On Wed, 2025-07-16 at 06:16 -0700, Breno Leitao wrote:
> On Wed, Jul 16, 2025 at 09:09:00AM -0400, James Bottomley wrote:
> > On Wed, 2025-07-16 at 08:31 -0400, James Bottomley wrote:
> > [...]
> > > If the theory is correct, the leak is genuine and we need to
> > > implement .free in efivarfs_context_ops to fix it.
> > 
> > Rather than trying to trace this, which will be hard, it might be
> > easier just to try the fix below (not even compile tested) and see
> > if
> > it works.  Note there's no danger of a double free because when fc-
> > > s_fs_info is copied to sb->s_fs_info, the field is nulled in fc.
> > 
> > Regards,
> > 
> > James
> > 
> > ---
> > 
> > diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
> > index c900d98bf494..90a619d027fd 100644
> > --- a/fs/efivarfs/super.c
> > +++ b/fs/efivarfs/super.c
> > @@ -390,10 +390,16 @@ static int efivarfs_reconfigure(struct
> > fs_context *fc)
> >  	return 0;
> >  }
> >  
> > +static void efivarfs_fs_context_free(struct fs_context *fc)
> > +{
> > +	kfree(fc->s_fs_info);
> > +}
> > +
> >  static const struct fs_context_operations efivarfs_context_ops = {
> >  	.get_tree	= efivarfs_get_tree,
> >  	.parse_param	= efivarfs_parse_param,
> >  	.reconfigure	= efivarfs_reconfigure,
> > +	.free		= efivarfs_fs_context_free,
> >  };
> >  
> >  static int efivarfs_check_missing(efi_char16_t *name16, efi_guid_t
> > vendor,
> 
> Hello James,
> 
> I was testing something very similar based on your previous email. I
> can
> confirm that the following patch make kmemleak happy. 
> 
> Regarding the fixes, I think this was introduced in commit
> 5329aa5101f73c ("efivarfs: Add uid/gid mount options")
> 
> commit 035521e8a5029ea814337d680e0552ccab1f97e2
> Author: Breno Leitao <leitao@debian.org>
> Date:   Wed Jul 16 06:08:57 2025 -0700
> 
>     efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error
> paths
>     
>     When processing mount options, efivarfs allocates
> efivarfs_fs_info (sfi)
>     early in fs_context initialization. However, sfi is associated
> with the
>     superblock and typically freed when the superblock is destroyed.
> If the
>     fs_context is released (final put) before fill_super is
> called—such as
>     on error paths or during reconfiguration—the sfi structure would
> leak,
>     as ownership never transfers to the superblock.
>     
>     Implement the .free callback in efivarfs_context_ops to ensure
> any
>     allocated sfi is properly freed if the fs_context is torn down
> before
>     fill_super, preventing this memory leak.
>     
>     Suggested-by: James Bottomley
> <James.Bottomley@HansenPartnership.com>
>     Signed-off-by: Breno Leitao <leitao@debian.org>
> 
> diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
> index c900d98bf4945..07a3b9293396b 100644
> --- a/fs/efivarfs/super.c
> +++ b/fs/efivarfs/super.c
> @@ -390,10 +390,22 @@ static int efivarfs_reconfigure(struct
> fs_context *fc)
>  	return 0;
>  }
>  
> +static void efivarfs_free(struct fs_context *fc)
> +{
> +	struct efivarfs_fs_info *sfi;
> +
> +	sfi = fc->s_fs_info;
> +	if (!sfi)
> +		return;

Here, you'll excite the coccinelle checkers looking for if(x) free(x)
because free() already also has a test for NULL.

Other than that elision, it looks fine to me.

Regards,

James


  reply	other threads:[~2025-07-16 13:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-15  9:28 Breno Leitao
2025-07-16  0:41 ` Ard Biesheuvel
2025-07-16 11:45   ` Breno Leitao
2025-07-16 12:31     ` James Bottomley
2025-07-16 13:09       ` James Bottomley
2025-07-16 13:16         ` Breno Leitao
2025-07-16 13:26           ` James Bottomley [this message]
2025-07-16 14:30             ` Breno Leitao

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=ec0a66f40bc826bd016f338568e01908b86be35a.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=ardb@kernel.org \
    --cc=jk@ozlabs.org \
    --cc=kernel-team@meta.com \
    --cc=leitao@debian.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®