[PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super

[PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super

[Sasha Levin]

From: Andreas Gruenbacher <agruenba@redhat.com>

[ Upstream commit 4e58543e7da4859c4ba61d15493e3522b6ad71fd ]

It turns out that the .freeze_super and .thaw_super operations require
the filesystem to manage the superblock refcount itself.  We are using
the freeze_super() and thaw_super() helpers to mostly take care of that
for us, but this means that the superblock may no longer be around by
when thaw_super() returns, and gfs2_thaw_super() will then access freed
memory.  Take an extra superblock reference in gfs2_thaw_super() to fix
that.

Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/gfs2/super.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
index 29157f7d9663..2993598d18a4 100644
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -1013,6 +1013,7 @@ static int gfs2_freeze(struct super_block *sb)
 		goto out;
 	}
 
+	atomic_inc(&sb->s_active);
 	for (;;) {
 		error = gfs2_lock_fs_check_clean(sdp, &sdp->sd_freeze_gh);
 		if (!error)
@@ -1034,6 +1035,7 @@ static int gfs2_freeze(struct super_block *sb)
 	error = 0;
 out:
 	mutex_unlock(&sdp->sd_freeze_mutex);
+	deactivate_super(sb);
 	return error;
 }
 
-- 
2.43.0

Re: [PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

Hi!

> From: Andreas Gruenbacher <agruenba@redhat.com>
> 
> [ Upstream commit 4e58543e7da4859c4ba61d15493e3522b6ad71fd ]
> 
> It turns out that the .freeze_super and .thaw_super operations require
> the filesystem to manage the superblock refcount itself.  We are using
> the freeze_super() and thaw_super() helpers to mostly take care of that
> for us, but this means that the superblock may no longer be around by
> when thaw_super() returns, and gfs2_thaw_super() will then access freed
> memory.  Take an extra superblock reference in gfs2_thaw_super() to fix
> that.

Patch was broken during backport.

> +++ b/fs/gfs2/super.c
> @@ -1013,6 +1013,7 @@ static int gfs2_freeze(struct super_block *sb)
>  		goto out;
>  	}
>  
> +	atomic_inc(&sb->s_active);
>  	for (;;) {
>  		error = gfs2_lock_fs_check_clean(sdp, &sdp->sd_freeze_gh);
>  		if (!error)
> @@ -1034,6 +1035,7 @@ static int gfs2_freeze(struct super_block *sb)
>  	error = 0;
>  out:
>  	mutex_unlock(&sdp->sd_freeze_mutex);
> +	deactivate_super(sb);
>  	return error;
>  }

Notice the goto out? That now jumps around the atomic_inc, but we
still do decrease. This will break 4.19, please fix or drop.

BR,
								Pavel
-- 
DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super

[Andreas Gruenbacher]

On Tue, Jan 16, 2024 at 9:53 PM Pavel Machek <pavel@denx.de> wrote:
> Hi!
>
> > From: Andreas Gruenbacher <agruenba@redhat.com>
> >
> > [ Upstream commit 4e58543e7da4859c4ba61d15493e3522b6ad71fd ]
> >
> > It turns out that the .freeze_super and .thaw_super operations require
> > the filesystem to manage the superblock refcount itself.  We are using
> > the freeze_super() and thaw_super() helpers to mostly take care of that
> > for us, but this means that the superblock may no longer be around by
> > when thaw_super() returns, and gfs2_thaw_super() will then access freed
> > memory.  Take an extra superblock reference in gfs2_thaw_super() to fix
> > that.
>
> Patch was broken during backport.
>
> > +++ b/fs/gfs2/super.c
> > @@ -1013,6 +1013,7 @@ static int gfs2_freeze(struct super_block *sb)
> >               goto out;
> >       }
> >
> > +     atomic_inc(&sb->s_active);
> >       for (;;) {
> >               error = gfs2_lock_fs_check_clean(sdp, &sdp->sd_freeze_gh);
> >               if (!error)
> > @@ -1034,6 +1035,7 @@ static int gfs2_freeze(struct super_block *sb)
> >       error = 0;
> >  out:
> >       mutex_unlock(&sdp->sd_freeze_mutex);
> > +     deactivate_super(sb);
> >       return error;
> >  }
>
> Notice the goto out? That now jumps around the atomic_inc, but we
> still do decrease. This will break 4.19, please fix or drop.

Thanks, Pavel.

Sasha, you don't want that fix without "gfs2: Rework freeze / thaw
logic" and the follow-up fixes, and backporting that probably isn't
going to be worth it.

Thanks,
Andreas

Re: [PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super

[Sasha Levin]

On Thu, Jan 18, 2024 at 12:50:37PM +0100, Andreas Gruenbacher wrote:
>On Tue, Jan 16, 2024 at 9:53 PM Pavel Machek <pavel@denx.de> wrote:
>> Hi!
>>
>> > From: Andreas Gruenbacher <agruenba@redhat.com>
>> >
>> > [ Upstream commit 4e58543e7da4859c4ba61d15493e3522b6ad71fd ]
>> >
>> > It turns out that the .freeze_super and .thaw_super operations require
>> > the filesystem to manage the superblock refcount itself.  We are using
>> > the freeze_super() and thaw_super() helpers to mostly take care of that
>> > for us, but this means that the superblock may no longer be around by
>> > when thaw_super() returns, and gfs2_thaw_super() will then access freed
>> > memory.  Take an extra superblock reference in gfs2_thaw_super() to fix
>> > that.
>>
>> Patch was broken during backport.
>>
>> > +++ b/fs/gfs2/super.c
>> > @@ -1013,6 +1013,7 @@ static int gfs2_freeze(struct super_block *sb)
>> >               goto out;
>> >       }
>> >
>> > +     atomic_inc(&sb->s_active);
>> >       for (;;) {
>> >               error = gfs2_lock_fs_check_clean(sdp, &sdp->sd_freeze_gh);
>> >               if (!error)
>> > @@ -1034,6 +1035,7 @@ static int gfs2_freeze(struct super_block *sb)
>> >       error = 0;
>> >  out:
>> >       mutex_unlock(&sdp->sd_freeze_mutex);
>> > +     deactivate_super(sb);
>> >       return error;
>> >  }
>>
>> Notice the goto out? That now jumps around the atomic_inc, but we
>> still do decrease. This will break 4.19, please fix or drop.
>
>Thanks, Pavel.
>
>Sasha, you don't want that fix without "gfs2: Rework freeze / thaw
>logic" and the follow-up fixes, and backporting that probably isn't
>going to be worth it.

I'll drop it, thanks!

-- 
Thanks,
Sasha