> On Nov 4, 2023, at 11:34 AM, Anton Ivanov <anton.iva...@kot-begemot.co.uk> > wrote: > > On 04/11/2023 09:25, Nadav Amit wrote: >> >> I was reading (again) the x86 C macro of “alternative()” and I was a bit >> surprised it does clobber the flags (“cc”) as a precaution. >> >> #define alternative(oldinstr, newinstr, ft_flags) \ >> asm_inline volatile (ALTERNATIVE(oldinstr, newinstr, ft_flags) : : : >> "memory") >> >> Actually there seems to be only one instance of problematic cases - in >> um/32-bit: >> >> #define mb() alternative("lock; addl $0,0(%%esp)", "mfence", >> X86_FEATURE_XMM2) >> #define rmb() alternative("lock; addl $0,0(%%esp)", "lfence", >> X86_FEATURE_XMM2) >> #define wmb() alternative("lock; addl $0,0(%%esp)", "sfence", >> X86_FEATURE_XMM) >> >> Presumably, if XMM or XMM2 are not supported, there would be instances where >> addl >> would be able to change eflags arithmetic flags without the compiler being >> aware >> of it. >> >> As it only affects 32-bit Linux UM - I don’t easily have an environment to >> test >> the fix. An alternative (word-pun unintended) is to add “cc” as a precaution >> to the alternative macro. >> > Application alternatives in um is presently a NOP. It always uses the "blunt > and heavy instrument" - the most conservative option. > > It is on the TODO list.
Thanks for the quick response. But I don’t see how it prevents the problem (it actually makes it worse - affecting XMM/XMM2 CPUs as well) since you keep the “lock; addl $0,0(%%esp)” in the running code, affecting eflags without telling the compiler that you do so through a “cc” clobber. _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um