From: Arnd Bergmann <arnd@arndb.de>
The comparison against SIZE_MAX produces a harmless warning on 64-bit
architectures:
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:185:16: error: result of comparison of constant 419244183493398898 with expression of type 'unsigned int' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (num_pages > (SIZE_MAX - sizeof(struct pagelist) -
~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Shut up that warning by adding a cast to a longer type.
Fixes: ca641bae6da9 ("staging: vc04_services: prevent integer overflow in create_pagelist()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Dan Carpenter <hidden> Date: 2021-09-27 12:27:54
On Mon, Sep 27, 2021 at 01:36:56PM +0200, Arnd Bergmann wrote:
quoted hunk
From: Arnd Bergmann <arnd@arndb.de>
The comparison against SIZE_MAX produces a harmless warning on 64-bit
architectures:
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:185:16: error: result of comparison of constant 419244183493398898 with expression of type 'unsigned int' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (num_pages > (SIZE_MAX - sizeof(struct pagelist) -
~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Shut up that warning by adding a cast to a longer type.
Fixes: ca641bae6da9 ("staging: vc04_services: prevent integer overflow in create_pagelist()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The temptation would be to declare "num_pages" as size_t instead of
adding this cost. But then something will complain about the
"pagelistinfo->num_pages = num_pages;" assignment because
"pagelistinfo->num_pages" is a u32.
The next temptation is to change the SIZE_MAX to UINT_MAX. I didn't
do that originally because I can't test this and I was trying not to
break things... We probably still don't want to break things, but maybe
there is someone who is more familiar with this who knows if UINT_MAX is
okay?
regards,
dan carpenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Phil Elwell <hidden> Date: 2021-09-27 13:21:46
Hi Dan,
On 27/09/2021 13:26, Dan Carpenter wrote:
On Mon, Sep 27, 2021 at 01:36:56PM +0200, Arnd Bergmann wrote:
quoted
From: Arnd Bergmann <arnd@arndb.de>
The comparison against SIZE_MAX produces a harmless warning on 64-bit
architectures:
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:185:16: error: result of comparison of constant 419244183493398898 with expression of type 'unsigned int' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (num_pages > (SIZE_MAX - sizeof(struct pagelist) -
~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Shut up that warning by adding a cast to a longer type.
Fixes: ca641bae6da9 ("staging: vc04_services: prevent integer overflow in create_pagelist()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The temptation would be to declare "num_pages" as size_t instead of
adding this cost. But then something will complain about the
"pagelistinfo->num_pages = num_pages;" assignment because
"pagelistinfo->num_pages" is a u32.
The next temptation is to change the SIZE_MAX to UINT_MAX. I didn't
do that originally because I can't test this and I was trying not to
break things... We probably still don't want to break things, but maybe
there is someone who is more familiar with this who knows if UINT_MAX is
okay?
The VPU can't address more than 1GB directly, so UINT_MAX is more than sufficient.
Phil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
The temptation would be to declare "num_pages" as size_t instead of
adding this cost. But then something will complain about the
"pagelistinfo->num_pages = num_pages;" assignment because
"pagelistinfo->num_pages" is a u32.
The next temptation is to change the SIZE_MAX to UINT_MAX. I didn't
do that originally because I can't test this and I was trying not to
break things... We probably still don't want to break things, but maybe
there is someone who is more familiar with this who knows if UINT_MAX is
okay?
The VPU can't address more than 1GB directly, so UINT_MAX is more than sufficient.
Is there a macro that already defines that 1GB size, or maybe an even smaller
value that makes sense as an upper bound?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel