2.6.8 kmem_cache_alloc barfs

2.6.8 kmem_cache_alloc barfs

[jmerkey]

in 2.6.8 with all features and config options (at least those that will build) with 4GB memory option selected, kmem_cache_alloc crashes when called with requests for 64KB chunks of memory which exceed the kernel address space of 1GB in size rather than returning an out of memory error.  

It is crashing here:

     /* Get colour for the slab, and cal the next value. */

->>>>CRASH!!!        offset = cachep->colour_next;

        cachep->colour_next++;
        if (cachep->colour_next >= cachep->colour)
                cachep->colour_next = 0;
        offset *= cachep->colour_off;
                                                                                
        spin_unlock(&cachep->spinlock);
                                                                                
        if (local_flags & __GFP_WAIT)
                local_irq_enable();


Jeff

Re: 2.6.8 kmem_cache_alloc barfs

[Christoph Hellwig]

On Thu, Aug 19, 2004 at 06:18:20PM +0000, jmerkey@comcast.net wrote:
> 
> in 2.6.8 with all features and config options (at least those that will build) with 4GB memory option selected, kmem_cache_alloc crashes when called with requests for 64KB chunks of memory which exceed the kernel address space of 1GB in size rather than returning an out of memory error.  

testcase please.

Re: 2.6.8 kmem_cache_alloc barfs

[jmerkey]

regparm=3 in an external modules build creates this problem if you reference internal 
linux includes and makefile commands from an externally built module.  I notice stack 
passing is on where it needs to be in exported symbols **IF** they are defined properly.
There are some holes with this for folks creating external modules that call into a kernel
with objects that are mismatched from the compile.

This was the source of the bug.

Jeff


> On Thu, Aug 19, 2004 at 06:18:20PM +0000, jmerkey@comcast.net wrote:
> > 
> > in 2.6.8 with all features and config options (at least those that will build) 
> with 4GB memory option selected, kmem_cache_alloc crashes when called with 
> requests for 64KB chunks of memory which exceed the kernel address space of 1GB 
> in size rather than returning an out of memory error.  
> 
> testcase please.
> 

Re: 2.6.8 kmem_cache_alloc barfs

[jmerkey]

Richard,

Here you go....

#define MAX_BUFFER_SIZE 0x10000
                                                                                
                                                                                
NOTE:  This code barfs in kmalloc while allocating 64KB blocks.  I
allocate a large number of these blocks from this routine.  2.6.4,2.6.7,
and 2.6.8 all crash in kmem_cache_alloc when kmalloc gets called and
I have exceeded the 1GB memory space in the kernel.  I am using 2.4.20
kernels with the userspace/kernelspace patch that allows the
kernel page space to be increased from 1GB to 3GB to allow me
to allocate 2.5 GB of memory in the kernel.  I am not using
this patch at present, but was testing 2.6.8 to see if it returned
proper failure states when large amounts of memory were allocated
and kernel memory was exhausted.
                                                                                
Jeff

   for (i = 0; i < (32 * 2048); i++)
    {
       buffer = kmalloc(MAX_BUFFER_SIZE, GFP_KERNEL);
       if (!buffer)
       {
          P_Print("could not allocate data buffer (%d bytes)\n",
                  MAX_BUFFER_SIZE);
          break;
       }
       P_Set(buffer, 0, MAX_BUFFER_SIZE);
    }
                                                                                
Pretty easy to make it fail.

Jeff

                                                                                


> On Thu, Aug 19, 2004 at 06:18:20PM +0000, jmerkey@comcast.net wrote:
> > 
> > in 2.6.8 with all features and config options (at least those that will build) 
> with 4GB memory option selected, kmem_cache_alloc crashes when called with 
> requests for 64KB chunks of memory which exceed the kernel address space of 1GB 
> in size rather than returning an out of memory error.  
> 
> testcase please.
>