Re: [PATCH -next] kasan: fix -Wstringop-overflow warning

[Walter Wu <walter-zh.wu@mediatek.com>]

On Wed, 2020-03-11 at 16:38 -0700, Andrew Morton wrote:
> On Wed, 11 Mar 2020 21:42:44 +0800 Walter Wu <walter-zh.wu@mediatek.com> wrote:
> 
> > Compiling with gcc-9.2.1 points out below warnings.
> > 
> > In function 'memmove',
> >     inlined from 'kmalloc_memmove_invalid_size' at lib/test_kasan.c:301:2:
> > include/linux/string.h:441:9: warning: '__builtin_memmove' specified
> > bound 18446744073709551614 exceeds maximum object size
> > 9223372036854775807 [-Wstringop-overflow=]
> > 
> > Why generate this warnings?
> > Because our test function deliberately pass a negative number in memmove(),
> > so we need to make it "volatile" so that compiler doesn't see it.
> > 
> > ...
> >
> > --- a/lib/test_kasan.c
> > +++ b/lib/test_kasan.c
> > @@ -289,6 +289,7 @@ static noinline void __init kmalloc_memmove_invalid_size(void)
> >  {
> >  	char *ptr;
> >  	size_t size = 64;
> > +	volatile size_t invalid_size = -2;
> >  
> >  	pr_info("invalid size in memmove\n");
> >  	ptr = kmalloc(size, GFP_KERNEL);
> > @@ -298,7 +299,7 @@ static noinline void __init kmalloc_memmove_invalid_size(void)
> >  	}
> >  
> >  	memset((char *)ptr, 0, 64);
> > -	memmove((char *)ptr, (char *)ptr + 4, -2);
> > +	memmove((char *)ptr, (char *)ptr + 4, invalid_size);
> >  	kfree(ptr);
> >  }
> 
> Huh.  Why does this trick suppress the warning?
> 
We read below the document, so we try to verify whether it is work for
another checking. After we changed the code, It is ok.

https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html#Warning-Options
"They do not occur for variables or elements declared volatile. Because
these warnings depend on optimization, the exact variables or elements
for which there are warnings depends on the precise optimization options
and version of GCC used."

> Do we have any guarantee that this it will contiue to work in future
> gcc's?
> 
Sorry, I am not compiler expert, so I can't guarantee gcc will not
modify the rule, but at least it is work before gcc-9.
>