Re: [PATCH] allocation: Track the size of allocated elements

Marion & Christophe JAILLET <[email protected]> Fri, 26 Aug 2022 12:05:55 +0200
Newsgroups org.kernel.vger.smatch
Message-ID <[email protected]>
Le 26/08/2022 à 11:31, Dan Carpenter a écrit :
> On Thu, Aug 25, 2022 at 07:54:20PM +0200, Christophe JAILLET wrote:
>> Add a new parameter, 'elem_size', which tells which argument holds the
>> size of an individual element.
>>
>> Many checks need this parameter, and up to now, we only have an expression
>> that shows how to compute the total amount of memory that is allocated.
>>
>> Signed-off-by: Christophe JAILLET <[email protected]>
>> ---
>> Not sure it is the best way to do it.
>>
>> In smatch.h, how are populated:
>>   	struct expression *total_size;
>>   	struct expression *nr_elems;
>>   	struct expression *elem_size;
>> ?
>>
>> With my first trials, these expr are always NULL.
> Yeah.  That code is not implemented yet.  Or more accurately, I
> implemented it last week but I haven't tested it yet or published it.
> I think once I publish that (later today probably) then it's a better
> option than passing the strings.
>
> I guess what I'm thinking there is that I quite like the size_str the
> way it is.  It's easier to fill in the alloc_fns[] table with just the
> size_str.  It's ultimate in flexibility.
>
> Then I think for kmalloc() I'll fill in the ->total_size expression.
> For kmalloc_array(), I'll leave total_size NULL and fill in the
> ->nr_elements and ->elem_size.  It feels like there should be another
> way set of expressions for struct_size().

Perfect for me :)

Thanks Dan.

> That's sort of roughly where I'd like to go.
>
> If you really want this then I can apply it but hopefully you won't
> want it if you have the expressions instead.  Expression pointers are
> better.

No need for my patch, I 200% agree with you.

CJ

>
> regards,
> dan carpenter
>