Messages in this thread | | | Date | Tue, 8 Sep 2009 15:26:18 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [patch 3/4 -mm] flex_array: poison free elements |
| |
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?
| |