Messages in this thread | | | Date | Wed, 26 Jan 2011 14:04:07 +0100 | From | Steffen Klassert <> | Subject | Re: flex_array related problems on selinux policy loading |
| |
On Fri, Jan 21, 2011 at 07:57:35AM -0800, Dave Hansen wrote: > > My suggestion would be to simply make sure that the code handles 0-sized > objects and 0-length arrays OK, and do it in two separate patches. The > ZERO_SIZE_PTR can't be used for both because you need to know which > situation you were in and you need different behavior (like in > flex_array_put()). > > Frankly, I like the idea of just allocating a 'struct flex_array' in any > case, and just teaching the code to handle element_size=0 and > nr_elements=0. That way, if you have bugs in the code that does things > like flex_array_alloc(elem_size=0, len=5, ...) and then > flex_array_get(fa, index=99), you have the potential to detect and > report the bugs. The only way to do that is to remember what you set > the length as. >
Another thing came to my mind. An atempt to do a zero size allocation always succeed on kmalloc. If we want to allocate our metadata even in this case, we should be aware that this allocation _can_ fail. So flex_array_alloc would not show the same behaviour as kmalloc on zero size allocations. As most potential flex_array users convert their code from kmalloc, the behaviour of flex_array_alloc should be the same as of kmalloc. Showing a different behaviour here will produce pitfalls for potential new users. Also, to tell a user that we can not allocate memory for him, if the wants to allocate 0 byte (nothing) is quite odd. This user could easily continue processing, even if we can not allocate our metadata in this moment.
From this point of view, I'd tend to not allocating anything. Instead we could return two newly defined pointers, e.g. FLEX_ARRAY_ZERO_SIZE and FLEX_ARRAY_ZERO_ELEMENTS to catch if either element_size or total_nr_elements is zero.
The downside of this is of course, that we can't catch the bugs you mentioned above.
Steffen
| |