Currently failslab injects failures into ____cache_alloc().
But with enabling CONFIG_NUMA it's not enough to let actual
slab allocator functions (kmalloc, kmem_cache_alloc, ...) return NULL.

This patch moves fault injection hook inside of __cache_alloc() and
__cache_alloc_node(). These are lower call path than ____cache_alloc()
and enable to inject faulures to slab allocators with CONFIG_NUMA.

Cc: Pekka Enberg <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>

---
 mm/slab.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

Index: 2.6-git/mm/slab.c
===================================================================
--- 2.6-git.orig/mm/slab.c
+++ 2.6-git/mm/slab.c
@@ -3142,7 +3142,7 @@ static int __init failslab_debugfs(void)
        struct dentry *dir;
        int err;
 
-               err = init_fault_attr_dentries(&failslab.attr, "failslab");
+       err = init_fault_attr_dentries(&failslab.attr, "failslab");
        if (err)
                return err;
        dir = failslab.attr.dentries.dir;
@@ -3180,9 +3180,6 @@ static inline void *____cache_alloc(stru
 
        check_irq_off();
 
-       if (should_failslab(cachep, flags))
-               return NULL;
-
        ac = cpu_cache_get(cachep);
        if (likely(ac->avail)) {
                STATS_INC_ALLOCHIT(cachep);
@@ -3374,6 +3371,9 @@ __cache_alloc_node(struct kmem_cache *ca
        unsigned long save_flags;
        void *ptr;
 
+       if (should_failslab(cachep, flags))
+               return NULL;
+
        cache_alloc_debugcheck_before(cachep, flags);
        local_irq_save(save_flags);
 
@@ -3444,6 +3444,9 @@ __cache_alloc(struct kmem_cache *cachep,
        unsigned long save_flags;
        void *objp;
 
+       if (should_failslab(cachep, flags))
+               return NULL;
+
        cache_alloc_debugcheck_before(cachep, flags);
        local_irq_save(save_flags);
        objp = __do_cache_alloc(cachep, flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to