Messages in this thread | | | From | Nick Piggin <> | Subject | Re: [rfc] SLOB memory ordering issue | Date | Thu, 16 Oct 2008 03:46:58 +1100 |
| |
On Thursday 16 October 2008 03:34, Nick Piggin wrote: > I think I see a possible memory ordering problem with SLOB: > In slab caches with constructors, the constructor is run > before returning the object to caller, with no memory barrier > afterwards. > > Now there is nothing that indicates the _exact_ behaviour > required here. Is it at all reasonable to expect ->ctor() to > be visible to all CPUs and not just the allocating CPU? > > SLAB and SLUB don't appear to have this problem. Of course, > they have per-CPU fastpath queues, so _can_ have effectively > exactly the same ordering issue if the object was brought > back into the "initialized" state before being freed, rather > than by ->ctor(). However in that case, it is at least > kind of visible to the caller.
Although I guess it's just as much of a SLAB implementation detail as the lack of ->ctor() barrier... And I really doubt _any_ of the callers would have ever thought about either possible problem.
I'd really hate to add a branch to the slab fastpath for this though. Maybe we just have to document it, assume there are no problems, and maybe take a look at some of the core users of this.
| |