Received-SPF: pass (google.com: domain of linux-kernel+bounces-99558-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: David Laight <David.Laight@ACULAB.COM>
To: 'Jaegeuk Kim' <jaegeuk@kernel.org>
CC: 'Roman Smirnov' <r.smirnov@omp.ru>, Chao Yu <chao@kernel.org>, "Sergey
 Shtylyov" <s.shtylyov@omp.ru>, Karina Yankevich <k.yankevich@omp.ru>,
	"linux-f2fs-devel@lists.sourceforge.net"
	<linux-f2fs-devel@lists.sourceforge.net>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "lvc-project@linuxtesting.org"
	<lvc-project@linuxtesting.org>
Subject: RE: [PATCH] f2fs: Cast expression type to unsigned long in
 __count_extent_cache()
Thread-Topic: [PATCH] f2fs: Cast expression type to unsigned long in
 __count_extent_cache()
Thread-Index: AQHabtSs8qQLngIY8Ey8WBtnYc/JqbExQp7QgAHHeICAAAg9sA==
Date: Mon, 11 Mar 2024 21:19:48 +0000
Message-ID: <15882d97fc0c4742a119128ccc12b5dd@AcuMS.aculab.com>
References: <20240305080943.6922-1-r.smirnov@omp.ru>
 <b4f9780714e243a6af9f77ab00593ec1@AcuMS.aculab.com>
 <Ze9rb0dRKt98kK54@google.com>
In-Reply-To: <Ze9rb0dRKt98kK54@google.com>
Accept-Language: en-GB, en-US
Precedence: bulk
MIME-Version: 1.0
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

From: Jaegeuk Kim
> Sent: 11 March 2024 20:37
> On 03/10, David Laight wrote:
> > From: Roman Smirnov
> > > Sent: 05 March 2024 08:10
> > >
> > > Cast expression type to unsigned long in __count_extent_cache()
> > > to prevent integer overflow.
> > >
> > > Found by Linux Verification Center (linuxtesting.org) with Svace.
> >
> > Another broken analysis tool :-)
> >
> > > Signed-off-by: Roman Smirnov <r.smirnov@omp.ru>
> > > Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
> > > ---
> > >  fs/f2fs/shrinker.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/fs/f2fs/shrinker.c b/fs/f2fs/shrinker.c
> > > index 83d6fb97dcae..bb86a06c5d5e 100644
> > > --- a/fs/f2fs/shrinker.c
> > > +++ b/fs/f2fs/shrinker.c
> > > @@ -33,7 +33,7 @@ static unsigned long __count_extent_cache(struct f2=
fs_sb_info *sbi,
> > >  {
> > >  =09struct extent_tree_info *eti =3D &sbi->extent_tree[type];
> > >
> > > -=09return atomic_read(&eti->total_zombie_tree) +
> > > +=09return (unsigned long)atomic_read(&eti->total_zombie_tree) +
> > >  =09=09=09=09atomic_read(&eti->total_ext_node);
> >
> > Makes diddly-squit difference.
> >
> > Both total_zombie_tree and totat_ext_node are 'int'.
> > If they are large enough that their sum wraps then the values
> > can individually wrap (to negative values).
> >
> > You really don't want to cast 'int' to 'unsigned long' here
> > at all - implicitly or explicitly.
> > The cast will first promote 'int' to 'signed long'.
> > So a negative value will get sign extended to a very big value.
>=20
> I thought, since total_zombie_tree won't get overflowed theoritically, th=
e first
> cast to (unsigned long) could expand the space to cover the following
> total_ext_node.

If will force the arithmetic be done as 'unsigned long' so the
second value will go through the integer promotion rules to
get from 'int' to 'unsigned long', there is an intermediate
stage of 'signed long'.
So (on 64bit) the 32bit signed value is sign extended to a
64bit signed value and the converted to 64 bit unsigned (same
bit pattern on 2s compliment systems).
The cast itself will have done the same sign extension on the
first value.

If toal_ext_node can get anywhere near 31 bits it is also likely
to get negative as well.
At which point very silly things happen is pretty much all cases
unless you only zero-extend to 64 bits.

>=20
> >
> > The best you can hope for is a 33bit result from wrapped 32bit
> > signed counters.
> > To get that you need to convert 'int' =3D> 'unsigned int' =3D> 'unsigne=
d long'.
> > One way would be:
> > =09return (atomic_read(&eti->total_zombie_tree) + 0u + 0ul) +
> > =09=09(atomic_read(&eti->total_ext_node) + 0u);
> >
> > Although changing the return type to 'unsigned int' would probably
> > be better.
> > I don't know what the values are, but if they are stats counters
> > then that would give a value that nicely wraps at 2^32 rather
> > that the strange wrap that the sum of two wrapping 32bit counters
> > has.
> >
> > OTOH it may be that they are counts - and just can't get any where
> > near that big.
> >
> > =09David
> >
> > -
> > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, M=
K1 1PT, UK
> > Registration No: 1397386 (Wales)

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1=
PT, UK
Registration No: 1397386 (Wales)