[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <807929267.20601.1589416908153.JavaMail.zimbra@efficios.com>
Date: Wed, 13 May 2020 20:41:48 -0400 (EDT)
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Andy Lutomirski <luto@...nel.org>
Cc: linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>,
paulmck <paulmck@...nel.org>,
Alexandre Chartre <alexandre.chartre@...cle.com>,
Frederic Weisbecker <frederic@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Petr Mladek <pmladek@...e.com>,
"Joel Fernandes, Google" <joel@...lfernandes.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
Brian Gerst <brgerst@...il.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Will Deacon <will@...nel.org>
Subject: Re: [patch V4 part 3 01/29] x86/traps: Mark fixup_bad_iret()
noinstr
----- On May 12, 2020, at 9:51 PM, rostedt rostedt@...dmis.org wrote:
> On Fri, 8 May 2020 17:39:00 -0700
> Andy Lutomirski <luto@...nel.org> wrote:
>
>> On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner <tglx@...utronix.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@...nel.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.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Powered by blists - more mailing lists