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.smir...@omp.ru>
> > Reviewed-by: Sergey Shtylyov <s.shtyl...@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)
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
