![]() | |||||||||||||
Messages in this thread |
> > >[...] However, it might break slab. > > >If I am not mistaken, slab code initializes multiple objects in > > >CPU_UP_PREPARE and relies on the CPU_UP_CANCELLED to destroy the > > >objects which successfully got initialized before the some object's > > >initialization went bad. > > > > My testing machine is ordinary dual core non numa box. So it might not > > trigger the problem that you are warried about under heavy slab alloc > > failure injection. > > > > At first glance I couln't find the problem in cpu hottplug code in slab.c > > yet, > > but found some memory leak path. (it doesn't break slab though) > > That's what I meant. I shouldn't have used the word "break" :-) > In case of slab, freeing up of resources on an error during CPU_UP_PREPARE, > is currently handled in CPU_UP_CANCELLED. Now I perfectly understand your concern. The last memleak fix patch did not cover for each cachep->array[cpu] in cache_chain. So cpu hotplug error handling in slab becomes worse by this change. > But, like you reasoned out, it makes more sense for such a subsystem > to free up all the correctly allocated resources before sending a > NOTIFY_BAD, rather than handling it in CPU_UP_CANCELLED. And slab > needed that fix, which you've provided, before we send the notification > to (nr_calls - 1) callers. > > So could you add this patch to series? Sure, and I'll CC you on the slab change. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2007-07-18 18:31 [from the cache] ©2003-2008 | |||||||||||||