[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120918203713.GB19300@phenom.dumpdata.com>
Date: Tue, 18 Sep 2012 16:37:13 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Dave Jones <davej@...hat.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
Suzuki Poulose <suzuki@...ibm.com>,
Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
Subject: Re: 3.6rc6 slab corruption.
> >> It should be easyish to fix by just adding a lock around those things.
> >
> > Like this:
>
> Not quite.
.. new patch in another email...
.. snip..
> > 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).
30 words. ~360 + 29 spaces + NULL = 390?
>
> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists