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! > 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
