svn commit: r339618 - head/sys/compat/linuxkpi/common/include/linux

Tijl Coosemans tijl at FreeBSD.org
Sun Nov 18 10:46:56 UTC 2018


On Sat, 17 Nov 2018 14:55:05 -0800 Matthew Macy <mat.macy at gmail.com> wrote:
> When looking at powerpc io.h raw and relaxed are not aliases, but it
> appears that on x86, they are:
> https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/io.h
> 
> Sorry for the noise. But let's starting moving the x86 specific
> atomic.h and io.h under asm/x86.

Yes, I agree that the file should be moved to an arch specific location.
And the functions should probably be implemented using inline asm like
they are on Linux in case there are differences in the way compilers treat
the C code versus the asm code.

> On Sat, Nov 17, 2018 at 2:01 PM Matthew Macy <mat.macy at gmail.com> wrote:
>> You should probably revert this. The implied understanding of the
>> _relaxed version is incorrect. compiler_membar is there to prevent
>> instruction reordering which is possible on FreeBSD because the accesses
>> are done in C. The relaxed variants still do not permit instruction
>> reordering. On Linux __compiler_member (referred to as barrier there)
>> isn’t necessary in the mmio accessors because they always use volatile
>> asm which can’t be reordered. The distinction between the relaxed and
>> non relaxed variants is that the relaxed variant lacks memory barriers
>> (sync / lwsync / eieio on ppc, membar on sparc, etc).

Quoting https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html:

"Note that the compiler can move even volatile asm instructions relative
to other code, including across jump instructions."

So I think the Linux implementation of the relaxed variant lacks both CPU
and compiler barriers.

>> Most of the time we don’t run in to problems on x86 because with TSO
>> the only reordering possible is writes that happen before reads can
>> become visible in memory after they occur in the instruction stream.

Note that these functions are normally used on uncacheable memory which
is strongly ordered on x86.  There should be no reordering at all.  On
PowerPC barrier instructions are needed to prevent reordering.


More information about the svn-src-all mailing list