Re: [patch V4 part 3 01/29] x86/traps: Mark fixup_bad_iret() noinstr

Andy Lutomirski
2020-05-14T01:35:45Z

> On May 13, 2020, at 5:41 PM, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
>
> ﻿----- On May 12, 2020, at 9:51 PM, rostedt rostedt@goodmis.org wrote:
>
>>> On Fri, 8 May 2020 17:39:00 -0700
>>> Andy Lutomirski <luto@kernel.org> wrote:
>>>
>>> On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>>>>
>>>> This is called from deep entry ASM in a situation where instrumentation
>>>> will cause more harm than providing useful information.
>>>>
>>>
>>> Acked-by: Andy Lutomirski <luto@kernel.org>
>>>
>>> Maybe add to changelog:
>>>
>>> Switch from memmove() to memcpy() because memmove() can't be called
>>> from noinstr code.
>>
>> Yes please, because I was about to say that there was changes that
>> didn't seem to fit the change log.
>>
>> I would also add a comment in the code saying that we need the temp
>> variable to use memcpy as memmove can't be used in noinstr code.
>
> Looking at an updated version of the tree, I see the acked-by from Andy,
> but not comment about switching from memmove to memcpy.
>
> Also, I notice a significant undocumented change in this patch: it changes
> a this_cpu_read() (which presumes preemption is enabled) to a __this_cpu_read().
>
> So the 100$ question: is preemption enabled or not in fixup_bad_iret() ? And of
> course that change should be documented in the commit message.
>

IRQs are off, and, if they were on, the lack of a warning from the percpu access would be the least of our concerns here.

> Thanks,
>
> Mathieu
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com