[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150614084059.GA24562@gmail.com>
Date: Sun, 14 Jun 2015 10:40:59 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Denys Vlasenko <dvlasenk@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Steven Rostedt <rostedt@...dmis.org>,
Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andy Lutomirski <luto@...capital.net>,
Oleg Nesterov <oleg@...hat.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Alexei Starovoitov <ast@...mgrid.com>,
Will Drewry <wad@...omium.org>,
Kees Cook <keescook@...omium.org>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] x86/asm/entry/32: Replace RESTORE_RSI_RDI[_RDX] with
open-coded 32-bit reads
* Denys Vlasenko <dvlasenk@...hat.com> wrote:
> +8b 74 24 68 mov 0x68(%rsp),%esi
> +8b 7c 24 70 mov 0x70(%rsp),%edi
> +8b 54 24 60 mov 0x60(%rsp),%edx
Btw., could you (in another patch) order the restoration properly, by pt_regs
memory order, where possible?
So this:
> + movl RSI(%rsp), %esi
> + movl RDI(%rsp), %edi
> + movl RDX(%rsp), %edx
> movl RIP(%rsp), %ecx
> movl EFLAGS(%rsp), %r11d
would become:
movl RDX(%rsp), %edx
movl RSI(%rsp), %esi
movl RDI(%rsp), %edi
movl RIP(%rsp), %ecx
movl EFLAGS(%rsp), %r11d
... or so.
In fact I'd suggest we structure movl based restoration precisely after the field
order in the structure, and comment on cases where we depart from what's in
pt_regs - to make it all easier to verify.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists