Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 17 Mar 2022 13:13:53 -0700 | Subject | Re: [PATCH v5] x86: use builtins to read eflags |
| |
On Thu, Mar 17, 2022 at 12:45 PM Bill Wendling <morbo@google.com> wrote: > > On Thu, Mar 17, 2022 at 11:52 AM Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > But the whole "you can't move _other_ things that you don't even > > understand around this either" is equally important. A "disable > > interrupts" could easily be protecting a "read and modify a CPU MSR > > value" too - no real "memory" access necessarily involved, but > > "memory" is the only way we can tell you "don't move this". > > > And yet that's not guaranteed. From > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html:
That's my point exactly.
The 'volatile' part of 'asm volatile' is almost meaningless.
As a result, we mark pretty much all system instructions as being memory clobbers, because that actually works.
Whether they actually clobber memory or not is immaterial, and is not why we do it.
> Note that the solution _isn't_ to add a "memory" clobber, because it's > not guaranteed to work, as it's explicitly defined to be a read/write > _memory_ barrier, despite what kernel writers wish it would do.
The solution you quote *ALSO* doesn't work, because they used a pointless example that was made-up in order to get to that solution.
Nobody cares about an operation being ordered wrt an addition.
Mostly kernel people care about an operation being ordered wrt something that the compiler DOES NOT KNOW ABOUT, and there is no way to actually tell the compiler, exactly because the compiler has no effin idea about it.
But the other thing kernel people care about is ordering those operations wrt externally visible things - like modifying memory. So an MSR write (or a write to a register like %CR0) may not itself directly read or modify memory at all, but there are other reasons why it might need to be ordered with any memory operations around it anyway, because some of those memory operations may be indirectly relevant (ie maybe they are page table writes and you just changed the page table pointer in %CR0, and now - even if you don't access the particular memory location, speculation may cause TLB fills to happen at any time).
You can't tell the compiler "this eflags operation must be ordered wrt this MSR write" - because even if the compiler knows about eflags, it doesn't know about things like page table contents or specific MSR bits, or whatever.
In a perfect world, we could actually enumerate resources we cared about somehow. But that world is not the world we live in.
So we end up basically having exactly *ONE* resource we can use as a "the compiler knows about this, and lets us use it as a synchronization point".
That one resource is "memory". You may not like it, but you have absolutely zero realistic alternatives, do you?
> Your assertion that compilers don't know about control registers isn't > exactly true. In the case of "pushf/popf", those instructions know > about the eflags registers. All subsequent instructions that read or > modify eflags also know about it. In essence, the compiler can > determine its own clobber list, which include MSRs.
Nope.
I think you are thinking of the arm64 MSR's. As far as I know, no compiler out there - and certainly not the complete set of compilers we support - know a thing about x86 msr registers. It's all inline asm.
And honestly, no sane person would _want_ a compiler worrying about x86 MSR's.
A compiler should do a good job at the basic instruction set, adn then give us the escapes for the unusual cases.
Stop believing that a compiler can deal with every part of system programming and that everything should be intrinsics. Because you don't have all the intrinsics we need anyway.
Linus
| |