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

From: David Rientjes
Date: Mon Aug 24 2009 - 16:42:03 EST

On Mon, 24 Aug 2009, Dave Hansen wrote:

> > diff --git a/include/linux/poison.h b/include/linux/poison.h
> > --- a/include/linux/poison.h
> > +++ b/include/linux/poison.h
> > @@ -65,6 +65,9 @@
> > #define MUTEX_DEBUG_INIT 0x11
> > #define MUTEX_DEBUG_FREE 0x22
> >
> > +/********** lib/flex_array.c **********/
> > +#define FLEX_ARRAY_FREE 0x6c /* for use-after-free poisoning */
> This seems like a good idea, but perhaps we should pick a non-ASCII
> character as the poison value. If someone ever tried to store strings
> as one-byte elements, they'd be in for a rude awakening the first time
> they store an 'l'.

I wasn't aware that storing an array of ASCII characters was a use case
for flex array, I'm having a hard type imagining such a user. We're
always going to have the possibility of conflict with the poison value
just from allowing eight byte element sizes, yet that possibility is still
going to exist if we disabled it on smaller elements and re-defined
FLEX_ARRAY_FREE as 0x6c6c, for example; the only thing that we've done is
eliminated the possibility of flex_array_shrink() for arrays consisting of
smaller elements. FLEX_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.

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. 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at