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

[David Rientjes]

On Mon, 24 Aug 2009, David Rientjes wrote:

> I'm starting to think that maybe an `unsigned int flags' is eventually 
> going to need to be added anyway: one reason is to serve this purpose of 
> identifying arrays that are stored in the base structure.  Another 
> possible reason is to identify flex arrays that want the poison behavior 
> to identify use-uninitialized and use-after-free and would be passed such 
> as flex_array_alloc(size, total, FLEX_ARRAY_POISON, gfp) to isolate arrays 
> that may, as you said, store elements of types other than void * or those 
> significantly small enough that they would collide with the poison values 
> at a higher probability.
> 

I was looking at converting a vmalloc'd array somewhere (anywhere, really) 
to use flex array instead.

The cgroup pidarray can't be converted because it sorts the array, for 
which flex array lacks support (and isn't really in its scope since the 
mapping from index to element is then pointless).  An alternative 
implementation like flex list, which I've already eluded to, seems more 
appropriate.

I also looked at oprofile's event_buffer, which vmalloc's elements of size 
unsigned long up to a certain threshold.  Flex array could accomodate 
261,632 such elements on x86_64 and the buffer threshold defaults to 
131,072, so it was looking like a good candidate.

The problem is that it copies the entire array to userspace up to a 
certain element when reading the oprofile `buffer' file.  That's not 
possible with flex array without vmalloc'ing memory of size buffer_pos * 
sizeof(unsigned long) and memcpy'ing the elements into it.  So using flex 
array in this case is pointless (and considerably slower on every read).

I'm struggling to find other examples.  Dave, do you know of any 
subsystems in the kernel that can readily be converted to using flex 
array?
--
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/