Re: [patch 3/4 -mm] flex_array: poison free elements

[David Rientjes]

On Mon, 24 Aug 2009, Dave Hansen wrote:

> On Mon, 2009-08-24 at 13:41 -0700, David Rientjes wrote:
> > LEX_ARRAY_FREE (or an additional poison value to 
> > distinguish between use-uninitialized vs. use-after-free) must be used in 
> > flex_array_clear() otherwise the cgroup patchset, the only proposed user 
> > of this library code, could never shrink this array when pid's are free 
> > like the kmalloc vs. vmalloc patchset could do.
> 
> Are you saying that you expected it to never reallocate the array, but
> have a permanent flex_array and that it just calls flex_array_clear() on
> the elements that it doesn't want any more, and the array ends up
> sparsely populated?  I can see why we'd need a poison value in that
> case.
> 

Yeah, similar to using flex_array_free_parts() with a statically allocated 
struct flex_array storing the array's metadata (which is also broken, 
by the way, since it does no sanity check on either parameter in 
FLEX_ARRAY_INIT()).

> Or, are we just talking about a situation where we need to truncate the
> pidlist?
> 

The patchset Andrew referred to where he proposed using flex array instead 
would re-kmalloc (or re-vmalloc, I guess) a smaller amount of memory and 
then transfer elements into it to free the larger set of pages.  If they 
were to convert to using flex array, this would be achieved with 
flex_array_shrink() so they lose no functionality with the switch.

I don't think they can use flex array for another reason, however, because 
they want to sort the pidlist as its returned to userspace.  That would 
require dynamically allocating almost the same amount of memory as the 
flex array would, sorting it, and then storing it in the array.  This 
doesn't seem to be the best example use of flex array since the mapping of 
array indices to pid isn't really relevant and there's a longer iteration 
through the array if it is sparsely populated, which is why I suggested an 
alternative implementation of flex list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/