Page MenuHomeFreeBSD

hyperv/vmbus: Avoid unnecessary mb()
ClosedPublic

Authored by sepherosa_gmail.com on Jul 27 2016, 8:38 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 9, 2:03 PM
Unknown Object (File)
Sun, Nov 30, 9:43 PM
Unknown Object (File)
Thu, Nov 27, 9:25 AM
Unknown Object (File)
Oct 26 2025, 7:06 PM
Unknown Object (File)
Oct 26 2025, 6:46 AM
Unknown Object (File)
Oct 26 2025, 6:46 AM
Unknown Object (File)
Oct 26 2025, 6:46 AM
Unknown Object (File)
Oct 26 2025, 12:05 AM
Subscribers
None

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sepherosa_gmail.com retitled this revision from to hyperv/vmbus: Avoid unnecessary mb().
sepherosa_gmail.com updated this object.
sepherosa_gmail.com edited the test plan for this revision. (Show Details)

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.

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).

This revision was automatically updated to reflect the committed changes.