kmem_cache_destroy issue with RT12 patch on v3.0.3 (perhaps related to thread 3.0.4 + rt12: deadlock?)

[PRINGLE Chris <chris.pringle@xxxxxxxxxxx>]

Dear All,

I've just upgraded to v3.0.3 of the kernel and the latest set of corresponding RT patches (rt12) and have run into a kernel OOPS/hang. This didn't happen on earlier kernels (2.6.33.7 was the last I tried), and doesn't happen without the RT patch.

The following code causes the a kernel OOPS at the point where I call kmem_cache_destroy:

struct test_struct
{
    unsigned int test[4096];
};

#define NUM_TESTS 1000

bool test_func(void)
{
    struct kmem_cache* testcache;
    struct test_struct* structs[NUM_TESTS];
    int i;

    printk(KERN_ERR "Creating\n");
    testcache= KMEM_CACHE(test_struct, 0);
    if (testcache == NULL)
    {
        printk(KERN_ERR "ERROR: %s: Failed to allocate lookaside cache \n", __func__);
        return false;
    }

    printk(KERN_ERR "Allocating\n");
    for (i= 0; i < NUM_TESTS; i++)
    {
        structs[i]= kmem_cache_alloc(testcache, GFP_KERNEL);
        if (structs[i] == NULL)
        {
            printk(KERN_ERR "ERROR: Failed to allocate\n");
        }
    }

    printk(KERN_ERR "Freeing\n");
    for (i= 0; i < NUM_TESTS; i++)
    {
        if (structs[i])
            kmem_cache_free(testcache, structs[i]);
    }

    printk(KERN_ERR "Destroying\n");
    kmem_cache_destroy(testcache);
}

Stack trace (from gdb) is as follows:
#23 0xc137ee53 in rt_spin_lock_slowlock (lock=0xcf802be0) at kernel/rtmutex.c:781
#24 0xc137f120 in rt_spin_lock_fastlock (lock=0xcedf00f1) at kernel/rtmutex.c:650
#25 rt_spin_lock (lock=0xcedf00f1) at kernel/rtmutex.c:815
#26 0xc1099818 in __local_lock_irq (cachep=0xcf400200, objp=<value optimised out>) at include/linux/locallock.h:89
#27 __local_lock_irqsave (cachep=0xcf400200, objp=<value optimised out>) at include/linux/locallock.h:117
#28 kmem_cache_free (cachep=0xcf400200, objp=<value optimised out>) at mm/slab.c:3940
#29 0xc10999b7 in slab_destroy (cachep=0xcec0bf00, slabp=<value optimised out>, delayed=<value optimised out>) at mm/slab.c:2100
#30 0xc1099b34 in free_block (cachep=0xcec0bf00, objpp=<value optimised out>, nr_objects=<value optimised out>, node=0) at mm/slab.c:3674
#31 0xc1099f6e in __do_drain (arg=0xcec0bf00, cpu=<value optimised out>) at mm/slab.c:2606
#32 do_drain (arg=0xcec0bf00, cpu=<value optimised out>) at mm/slab.c:2622
#33 0xc1098bde in slab_on_each_cpu (func=0xc1099f10 <do_drain>, arg=0xcec0bf00) at mm/slab.c:737
#34 0xc109a296 in drain_cpu_caches (cachep=0xcec0bf00) at mm/slab.c:2634
#35 __cache_shrink (cachep=0xcec0bf00) at mm/slab.c:2696
#36 0xc109a46c in kmem_cache_destroy (cachep=0xcec0bf00) at mm/slab.c:2760

The code is running on an SMP i686 kernel with full pre-emption enabled. The kernel is running on an i686 VMWare virtual machine.

If I add SLAB_RED_ZONE | SLAB_DEBUG_OBJECTS to KMEM_CACHE flags the problem doesn't appear to show itself.

Any ideas?
Cheers,
Chris

____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html