Re: [PATCH v2 2/4] KVM: introduce "xinterface" API for external interaction with guests

[Avi Kivity <avi@redhat.com>]

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.