On 10/06/2009 09:40 PM, Gregory Haskins wrote:
Thinking about this some more over lunch, I think we (Avi and I) might
both be wrong (and David is right). Avi is right that we don't need
rmb() or barrier() for the reasons already stated, but I think David is
right that we need an smp_mb() to ensure the cpu doesn't do the
reordering. Otherwise a different cpu could invalidate the memory if it
reuses the freed memory in the meantime, iiuc. IOW: its not a compiler
issue but a cpu issue.
Or am I still confused?
The sequence of operations is:
v = p->v;
f();
// rmb() ?
g(v);
You are worried that the compiler or cpu will fetch p->v after f() has
executed? The compiler may not, since it can't tell whether f() might
change p->v. If f() can cause another agent to write to p (by freeing
it to a global list, for example), then it is its responsibility to
issue the smp_rmb(), otherwise no calculation that took place before f()
and accessed p is safe.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
