Re: [PATCH] fs/super: fix s_fs_info leak when setup_bdev_super() fails

[Shardul Bankar <shardul.b@mpiricsoftware.com>]

On Sun, 2026-02-01 at 08:27 +0000, Al Viro wrote:
> On Sun, Feb 01, 2026 at 01:02:26PM +0530, Shardul Bankar wrote:
> 
> 
> First of all, _what_ ->put_super()?  Forget ->s_root, ->s_op is
> not going to be set there, so there's nowhere to get ->put_super()
> from.  Relevant thing here is ->kill_sb().
> 
Right, good catch- at that point ->s_op isn’t set yet, so ->put_super()
isn’t even a thing to rely on. Thanks for pointing that out.

The leak here is actually originating from hfsplus
(hfsplus_init_fs_context()).

> Freeing ->s_fs_info is better done there anyway - makes for simpler
> handling of foo_fill_super() failure exits, exactly because you don't
> need to free the damn thing there - just let your ->kill_sb() deal
> with
> it.
> 
> The thing is, there are ->kill_sb() instances that do just that and
> I'm not at all sure they won't be broken by this patch.
> 
> Note that right now it's either "deactivate_locked_super() done, -
> >free()
> is told to bugger off" or "->free() is called,
> deactivate_locked_super()
> and ->kill_sb() isn't"; you are introducing a new situation here.

I see your concern about introducing a new ownership state for
s_fs_info (handing it back to fc while still going through
deactivate_locked_super() / ->kill_sb()), which could break filesystems
that already free s_fs_info from ->kill_sb().

I'll drop this patch and raise a new one by fixing the leak in the
filesystem side instead (HFS+), making sure its ->kill_sb() path
reliably frees s_fs_info even when we fail before fill_super() runs,
and I’ll add the HFS+ maintainer(s) on that patch.

Thanks,
Shardul