Re: [PATCH] f2fs: Cast expression type to unsigned long in __count_extent_cache()

[Jaegeuk Kim <jaegeuk@kernel.org>]

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 f2fs_sb_info *sbi,
> >  {
> >  	struct extent_tree_info *eti = &sbi->extent_tree[type];
> > 
> > -	return atomic_read(&eti->total_zombie_tree) +
> > +	return (unsigned long)atomic_read(&eti->total_zombie_tree) +
> >  				atomic_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.

I thought, since total_zombie_tree won't get overflowed theoritically, the first
cast to (unsigned long) could expand the space to cover the following
total_ext_node.

> 
> The best you can hope for is a 33bit result from wrapped 32bit
> signed counters.
> To get that you need to convert 'int' => 'unsigned int' => 'unsigned long'.
> One way would be:
> 	return (atomic_read(&eti->total_zombie_tree) + 0u + 0ul) +
> 		(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.
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)