Messages in this thread | | | Date | Thu, 14 May 2020 13:46:10 -0400 (EDT) | From | Mathieu Desnoyers <> | Subject | Re: [patch V4 part 4 15/24] x86/db: Split out dr6/7 handling |
| |
----- On May 14, 2020, at 1:28 PM, Thomas Gleixner tglx@linutronix.de wrote:
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> writes: >> ----- On May 5, 2020, at 9:49 AM, Thomas Gleixner tglx@linutronix.de wrote: >>> + >>> +static __always_inline void debug_exit(unsigned long dr7) >>> +{ >>> + set_debugreg(dr7, 7); >>> +} >>
* Question 1
>> Out of curiosity, what prevents the compiler from moving instructions >> outside of the code regions surrounded by entry/exit ? This is an always >> inline, which invokes set_debugreg which is inline for CONFIG_PARAVIRT_XXL=n, >> which in turn uses an asm() (not volatile), without any memory >> clobber. >>
?
* Question 2
>> Also, considering that "inline" is not sufficient to ensure the compiler >> does not emit a traceable function, I suspect you'll also want to mark >> "native_get_debugreg" and "native_set_debugreg" always inline as well. > > It can move it into a function and call that. Fine. If that function > stays in the noinstr section then it should not emit a trace stub and if > it moves it out of the section or reuses another instance in text then > objtool will complain. > > Checking for trace stubs and other instrumentation nonsense is on the > objtool wishlist anyway. > > But yes, marking these __always_inline prevents that. Those escaped my > chase. But I would have found them once I go and fix that paravirt muck.
This answers only my second question (see "Question 1" above).
Thanks,
Mathieu
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |