Re: 3.6rc6 slab corruption.

[Linus Torvalds]

On Tue, Sep 18, 2012 at 12:23 PM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
>>
>> It should be easyish to fix by just adding a lock around those things.
>
> Like this:

Not quite.

I suspect you need to protect the "read_from_buffer()" call too, since
otherwise the buffer can be free'd by another thread while being
copied to user space..

>>  - the whole format_array_alloc() code is one buggy piece of sh*t,
>> since afaik there is nothing that guarantees that the values cannot
>> change. So the notion of "let's format the output once to know how big
>> it is, and then a second time to actually print things into the array
>> we just allocated based on the first time" is pure and utter garbage,
>> afaik.
>
> Yikes. The fix could be to allocate a buffer large enough for the maximum
> that %u could take * array_size and not bother with the first pass.

That's the simple approach. An alternative approach would be to start
with a reasonable guess as to the size, and use krealloc() if needed
to expand.

What are the realistic array sizes? If we're talking about arrays of
just 16 words or something, just do the maximum (what, 12 bytes per
32-bit word? 11 bytes for the number, and then space/NUL after that).

If we're talking about potentially much bigger arrays, maybe we need
to use krealloc() to handle it without wasting tons of memory for the
common case..

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