On Tue, Jun 30, 2009 at 12:09:29PM +0200, Heiko Carstens wrote: > On Tue, Jun 30, 2009 at 11:06:31AM +0200, Nick Piggin wrote: > > On Mon, Jun 29, 2009 at 04:12:34PM +0200, Heiko Carstens wrote: > > > slqb returns ZERO_SIZE_PTR instead of NULL for large size requests it cannot > > > handle. > > > The patch below would fix it. But I think its too ugly. So I leave it up to > > > Nick to come up with a real and nice patch ;) > > > > Could you try this patch and see if it helps? (it fixes a number > > of simple corner cases here, *blush*) > > Yes, it does work now. Thanks! Thanks. Pekka, can you please merge this with Signed-off-by: Nick Piggin <npiggin@xxxxxxx> > > > SLQB: fix allocation size checking > > > > SLQB would return ZERO_SIZE_PTR rather than NULL if the requested size is too > > large. Debugged by Heiko Carstens. Fix this by checking size edge cases up > > front rather than in the slab index calculation. > > > > Additionally, if the size parameter was non-constant and too large, then > > the checks may not have been performed at all which could cause corruption. > > > > Next, ARCH_KMALLOC_MINALIGN may not be obeyed if size is non-constant. So > > test for KMALLOC_MIN_SIZE in that case. > > > > Finally, if KMALLOC_SHIFT_SLQB_HIGH is larger than 2MB, then kmalloc_index > > could silently run off the end of its precomputed table and return a -1 > > index into the kmalloc slab array, which could result in corruption. Extend > > this to allow up to 32MB (to match SLAB), and add a compile-time error in > > the case that the table is exceeded (also like SLAB). -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
