Page MenuHomeFreeBSD

Use atomic_interrupt_fence() instead of bare __compiler_membar()
ClosedPublic

Authored by kib on Feb 27 2021, 12:05 AM.

Details

Summary

for the which which definitely use membar to sync with interrupt handlers.

libc and rtld uses of __compiler_membar() seems to want compiler barriers proper.

There are two special cases:

  1. kpilite sched_unpin_lite() fence after td_pinned decrement. I am not sure if we need it at all
  2. x86/include/bus.h (not handled in the patch) where I am not sure why do we need seq_cst fence at all for bus_space_barrier()

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

kib requested review of this revision.Feb 27 2021, 12:05 AM
kib created this revision.

I'm not very familiar with bus_space_barrier(). I'm wondering if it's trying to handle the case where the resource is mapped WC?

sys/sys/kpilite.h
51–52

I suspect it is duplicated from critical_exit(). The same commit that added kpilite.h also added an inline critical_exit() to systm.h, and there the second fence is indeed required. I think you can just drop it here.

This revision is now accepted and ready to land.Feb 27 2021, 4:39 PM
kib marked an inline comment as done.Feb 27 2021, 11:05 PM

I'm not very familiar with bus_space_barrier(). I'm wondering if it's trying to handle the case where the resource is mapped WC?

For WC fencing, locked op might be not enough. For instance, for fencing CLFLUSHOPT, SDM requires SFENCE. I think it is right to not touch bus.h in this commit.