Re: Next June 29: Boot failure with SLQB on s390

[Heiko Carstens <heiko.carstens@de.ibm.com>]

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).