On Mon, Jan 26, 2026 at 06:34:49PM +0200, Konstantin Belousov wrote:
> On Mon, Jan 26, 2026 at 03:57:45PM +0000, Marius Strobl wrote:
> > The branch main has been updated by marius:
> >
> > URL:
> > https://cgit.FreeBSD.org/src/commit/?id=e769bc77184312b6137a9b180c97b87c0760b849
> >
> > commit e769bc77184312b6137a9b180c97b87c0760b849
> > Author: Marius Strobl <[email protected]>
> > AuthorDate: 2026-01-26 13:58:57 +0000
> > Commit: Marius Strobl <[email protected]>
> > CommitDate: 2026-01-26 15:54:48 +0000
> >
> > sym(4): Employ memory barriers also on x86
> >
> > In an MP world, it doesn't hold that x86 requires no memory barriers.
> It does hold. x86 is much more strongly ordered than all other arches
> we currently support.
If it does hold, then why is atomic_thread_fence_seq_cst() employing
a StoreLoad barrier even on amd64?
I agree that x86 is more strongly ordered than the other supported
architectures, though.
The panic seen matches the typical scenario of even x86 requiring a
StoreLoad barrier. For the actual usage of these macros, the use of
bus_{space,9}_barrier(9) would be more appropriate, however. On x86,
this translates to a "lock addl $0,mem" for BUS_SPACE_BARRIER_READ,
which probably would also achieve the intended order. I'd much
prefer to just do what Linux still does up until today and be done
with it, though.
Marius
