Re: git: e769bc771843 - main - sym(4): Employ memory barriers also on x86
Date: Mon, 26 Jan 2026 18:11:51 UTC
On 26/01/2026 18:34, 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 <marius@FreeBSD.org> >> AuthorDate: 2026-01-26 13:58:57 +0000 >> Commit: Marius Strobl <marius@FreeBSD.org> >> 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. > > That said, the use of the barriers in drivers is usually not justified > (I did not looked at this specific case). > > Even if needed, please stop using rmb/wmb etc. Use atomic_thread_fence() > of appropriate kind, see atomic(9). Then on x86 it does the right thing. I understand that this advice is for the "normal" memory access model. But does it apply to "special" memory? E.g., to memory-based communication with devices? -- Andriy Gapon