Re: Undo aic7xxx changes (now rc7+aic20030603)

From: Stephan von Krawczynski (
Date: Sun Jun 08 2003 - 06:19:01 EST

Hello all,

looking at code around my problem I discovered this:

static inline void * __kmem_cache_alloc (kmem_cache_t *cachep, int flags)
        unsigned long save_flags;
        void* objp;

        kmem_cache_alloc_head(cachep, flags);
                cpucache_t *cc = cc_data(cachep);

                if (cc) {
                        if (cc->avail) {
                                objp = cc_entry(cc)[--cc->avail];
                        } else {
                                objp = kmem_cache_alloc_batch(cachep,cc,flags);
                                if (!objp)
                                        goto alloc_new_slab_nolock;
                } else {
                        objp = kmem_cache_alloc_one(cachep);
        objp = kmem_cache_alloc_one(cachep);
        return objp;
        if (kmem_cache_grow(cachep, flags))
                /* Someone may have stolen our objs. Doesn't matter, we'll
                 * just come back here again.
                goto try_again;
        return NULL;

I suggest it for most-absurd-goto-usage-award.

1) There seems to be no reference for symbol "alloc_new_slab"
2) "spin_unlock" (right below) is never reached
3) The not-ifdef'ed code below is only used if CONFIG_SMP
4) The code "alloc_new_slab_nolock" is referenced only once by a goto
   (why not simply pasted there?)

This does not look like a problem, it only is damn ugly. I have no idea
what this code actually does, but it looks patched-to-the-limit. Has
anybody reviewed slab regarding CONFIG_SMP?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:18 EST