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 >