hyperv/vmbus: Avoid unnecessary mb()

[kib]

How is this supposed to be reviewed ? Indeed, the patch changes compiler barrier + some fences into compiler barrier. Bit I have no idea why the change is safe, and what is the reason behind original code and this weaker variation.

Are you relying on the IA32 ordering guarantees ? If yes, then atomic_fence_acq() for read/any and atomic_fence_rel for any/write fencing is more clean.

[sepherosa_gmail.com]

In D7333#152520, @kib wrote:

How is this supposed to be reviewed ? Indeed, the patch changes compiler barrier + some fences into compiler barrier. Bit I have no idea why the change is safe, and what is the reason behind original code and this weaker variation.

Are you relying on the IA32 ordering guarantees ? If yes, then atomic_fence_acq() for read/any and atomic_fence_rel for any/write fencing is more clean.

Yeah, I am relying on IA32 ordering. Well, since the other side is in the hypervisor, I am not sure about whether fence_acq and fence_rel will be more readable or not (since acq and rel will not be paired).