On Tue, Nov 29, 2011 at 10:08:00PM +0100, Thomas Meyer wrote:Fine by me. Thanks. As stated by others though you might want to change the descriptionThe advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107
Acked-by: Jonathan Cameron <jic23@xxxxxxxxxx>Signed-off-by: Thomas Meyer <thomas@xxxxxxxx>
-----
diff -u -p a/drivers/staging/iio/accel/lis3l02dq_ring.c b/drivers/staging/iio/accel/lis3l02dq_ring.c
--- a/drivers/staging/iio/accel/lis3l02dq_ring.c 2011-11-13 11:07:47.933826988 +0100
+++ b/drivers/staging/iio/accel/lis3l02dq_ring.c 2011-11-28 20:00:44.704446880 +0100
@@ -93,8 +93,7 @@ static int lis3l02dq_read_all(struct iio
struct spi_message msg;
int ret, i, j = 0;
- xfers = kzalloc((buffer->scan_count) * 2
- * sizeof(*xfers), GFP_KERNEL);
+ xfers = kcalloc((buffer->scan_count) * 2, sizeof(*xfers), GFP_KERNEL);
I've looked at these and none of them can actually overflow.
But if they could then there would still be the potential for
overflow here. If buffer->scan_count were a negative number then
the first for loop could cause memory corruption.
Still it's a cleanup and the patch is fine.