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

[Dave Hansen]

On Mon, 2009-08-24 at 13:41 -0700, David Rientjes wrote:
> On the other hand, I'd have no problem trying to eliminate 
> fa->total_nr_elements (since we already have fa->element_size) since we 
> can calculate it in real-time; the only problem is being able to 
> distinguish when the elements are being stored in struct flex_array vs. 
> being stored in struct flex_array_part.

Yeah, that's the only reason it's there: to determine if we're using the
compact form or not.  We could probably find another place to store
that, or just store a flag telling whether we're using that form or not.
We couldn't do the bounds-checking, but I'm OK with that.

But, honestly, it doesn't *really* bother me if we just use two 32-bit
int slots in the 'struct flex_array'.  The 64-bit code has an extra 4
bytes now anyway.

> We could then use that
> unsigned int in struct flex_array to store the number of inuse elements 
> which is an alternative implementation to flex_array_shrink(), yet I'd 
> still propose to keep the poisoning to reveal use-uninitialized.

I kinda like the idea of truncating more, just because its simpler and
doesn't have any assumptions about the contents.  But, you are right
that poisoning has some distinct benefits, namely allowing sparsely used
arrays to shrink.

-- Dave

--
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/