[lkml]   [2009]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 2/4] KVM: introduce "xinterface" API for external interaction with guests
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;
// rmb() ?

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.

 \ /
  Last update: 2009-10-07 10:45    [W:0.056 / U:0.020 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site