* Missing clobber on alternative use on Linux UM 32-bit
@ 2023-11-04 9:25 Nadav Amit
2023-11-04 9:34 ` Anton Ivanov
0 siblings, 1 reply; 5+ messages in thread
From: Nadav Amit @ 2023-11-04 9:25 UTC (permalink / raw)
To: Richard Weinberger, linux-um
Cc: Thomas Gleixner, Linux Kernel Mailing List, Peter Zijlstra
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.
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Missing clobber on alternative use on Linux UM 32-bit 2023-11-04 9:25 Missing clobber on alternative use on Linux UM 32-bit Nadav Amit @ 2023-11-04 9:34 ` Anton Ivanov 2023-11-04 9:40 ` Nadav Amit 0 siblings, 1 reply; 5+ messages in thread From: Anton Ivanov @ 2023-11-04 9:34 UTC (permalink / raw) To: Nadav Amit, Richard Weinberger, linux-um Cc: Thomas Gleixner, Linux Kernel Mailing List, Peter Zijlstra 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. > > > _______________________________________________ > linux-um mailing list > linux-um@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-um 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. -- Anton R. Ivanov https://www.kot-begemot.co.uk/ _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Missing clobber on alternative use on Linux UM 32-bit 2023-11-04 9:34 ` Anton Ivanov @ 2023-11-04 9:40 ` Nadav Amit 2023-11-05 15:47 ` David Laight 0 siblings, 1 reply; 5+ messages in thread From: Nadav Amit @ 2023-11-04 9:40 UTC (permalink / raw) To: Anton Ivanov Cc: Richard Weinberger, linux-um, Thomas Gleixner, Linux Kernel Mailing List, Peter Zijlstra > On Nov 4, 2023, at 11:34 AM, Anton Ivanov <anton.ivanov@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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Missing clobber on alternative use on Linux UM 32-bit 2023-11-04 9:40 ` Nadav Amit @ 2023-11-05 15:47 ` David Laight 2023-11-06 11:33 ` Nadav Amit 0 siblings, 1 reply; 5+ messages in thread From: David Laight @ 2023-11-05 15:47 UTC (permalink / raw) To: 'Nadav Amit', Anton Ivanov Cc: Richard Weinberger, linux-um@lists.infradead.org, Thomas Gleixner, Linux Kernel Mailing List, Peter Zijlstra From: Nadav Amit > Sent: 04 November 2023 09:41 > > > On Nov 4, 2023, at 11:34 AM, Anton Ivanov <anton.ivanov@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. gcc always assumes that inline asm changes "cc" - there is no need to add a 'clobber' for it. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Missing clobber on alternative use on Linux UM 32-bit 2023-11-05 15:47 ` David Laight @ 2023-11-06 11:33 ` Nadav Amit 0 siblings, 0 replies; 5+ messages in thread From: Nadav Amit @ 2023-11-06 11:33 UTC (permalink / raw) To: David Laight Cc: Anton Ivanov, Richard Weinberger, linux-um@lists.infradead.org, Thomas Gleixner, Linux Kernel Mailing List, Peter Zijlstra > On Nov 5, 2023, at 5:47 PM, David Laight <David.Laight@aculab.com> wrote: > > gcc always assumes that inline asm changes "cc" - there is no need > to add a 'clobber' for it. Thanks. I was unaware of this behavior. _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-11-06 11:33 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-11-04 9:25 Missing clobber on alternative use on Linux UM 32-bit Nadav Amit 2023-11-04 9:34 ` Anton Ivanov 2023-11-04 9:40 ` Nadav Amit 2023-11-05 15:47 ` David Laight 2023-11-06 11:33 ` Nadav Amit
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox