Messages in this thread | | | From | Nick Piggin <> | Subject | Re: [rfc] SLOB memory ordering issue | Date | Thu, 16 Oct 2008 04:45:28 +1100 |
| |
On Thursday 16 October 2008 04:33, Linus Torvalds wrote: > On Thu, 16 Oct 2008, Nick Piggin wrote: > > Now they allocate these guys, take a lock, then insert them into the > > page tables. The lock is only an acquire barrier, so it can leak past > > stores. > > I think that Matt's point was that the code is buggy regardless of any > ctor or not. > > If you make an allocation visible to other CPU's, you would need to make > sure that allocation is stable with a smp_wmb() before you update the > pointer to that allocation.
What do you mean by the allocation is stable? Let's just talk in loads and stores and order. You need to make sure previous stores to initialise the object become visible before subsequent store to make the object visible. No questions about that (I think that's what you meant by make the alloc stable).
1. However, if the object is already fully initialised at the point the caller gets it out of the allocator, then the caller doesn't need to make any stores to initialise it obviously.
2. I think it could be easy to assume that the allocated object that was initialised with a ctor for us already will have its initializing stores ordered when we get it from slab.
So in my page table almost-example, by combining 1 and 2, one might think it is OK to leave out those smp_wmb()s. And it would be valid code if all those assumptions _were_ true.
| |