On Mon, Aug 02, 2010 at 03:50:13PM +0200, Oleg Nesterov wrote:
>
> Also. Not sure this really makes sense, but if we ever need to expand the
> string, perhaps it makes sense to remeber this fact so that the next time
> we start with len > CORENAME_MAX_SIZE. In any case, I think this needs a
> separate patch.
>
> Oleg.
Yes, this is what I alluded to in my initial reply. We need to keep an atomic
value to track the maximum number of times we've called expand_corename to help
prevent us having to call it repeatedly on every crash. Something like this:
expand_corename(**corename, **out_end, **out_ptr)
{
...
*corename = krealloc(*corename,
CORENAME_MAX_SIZE*
atomic_inc_return(call_count),
GFP_KERNEL);
...
}
do_coredump(...)
{
...
corename = kmalloc(CORENAME_MAX_SIZE *
atomic_read(call_count),
GFP_KERNEL);
...
}
That will train the path to allocate a sensible size after the first crash, and
avoid lots of calls to krealloc in the pessimal case
Neil
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
