All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	x86@kernel.org, Lai Jiangshan <jiangshan.ljs@antgroup.com>,
	Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Thomas Tai <thomas.tai@oracle.com>,
	"Chang S. Bae" <chang.seok.bae@intel.com>,
	Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [PATCH V4 1/7] x86/traps: Move pt_regs only in fixup_bad_iret()
Date: Wed, 6 Apr 2022 21:00:38 +0200	[thread overview]
Message-ID: <Yk3jVrXoVpxuR0Mp@zn.tnic> (raw)
In-Reply-To: <20220318143016.124387-2-jiangshanlai@gmail.com>

On Fri, Mar 18, 2022 at 10:30:10PM +0800, Lai Jiangshan wrote:
> From: Lai Jiangshan <jiangshan.ljs@antgroup.com>
> 
> fixup_bad_iret() and sync_regs() have similar arguments and do similar
> work that copies full or partial pt_regs to a place and switches stack
> after return.  They are quite the same, but fixup_bad_iret() not only
> copies the pt_regs but also the return address of error_entry() while

What return address of error_entry()? You lost me here.

fixup_bad_iret() moves the stack frame while sync_regs() switches to the
thread stack. I have no clue what you mean.

> sync_regs() copies the pt_regs only and the return address of
> error_entry() was preserved and handled in ASM code.

Nope, no idea.
 
> This patch makes fixup_bad_iret() work like sync_regs() and the

Avoid having "This patch" or "This commit" in the commit message. It is
tautologically useless.

Also, do

$ git grep 'This patch' Documentation/process

for more details.

> handling of the return address of error_entry() is moved in ASM code.
> 
> It removes the need to use the struct bad_iret_stack, simplifies
> fixup_bad_iret() and makes the ASM error_entry() call fixup_bad_iret()
> as the same as calling sync_regs() which adds readability because
> the calling patterns are exactly the same.

So fixup_bad_iret() gets the stack ptr passed in by doing:

        mov     %rsp, %rdi
        call    fixup_bad_iret
        mov     %rax, %rsp


and error_regs()

        movq    %rsp, %rdi                      /* arg0 = pt_regs pointer */
        call    sync_regs
        movq    %rax, %rsp                      /* switch stack */

the same way.

Confused.

> It is prepared for later patch to do the stack switch after the
> error_entry() which simplifies the code further.

Looking at your next patch, is all this dance done just so that you can
do

	leaq    8(%rsp), %rdi

in order to pass in pt_regs to both functions?

And get rid of the saving/restoring %r12?

Is that what the whole noise is about?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  reply	other threads:[~2022-04-06 20:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-18 14:30 [PATCH V4 0/7] x86/entry: Clean up entry code Lai Jiangshan
2022-03-18 14:30 ` [PATCH V4 1/7] x86/traps: Move pt_regs only in fixup_bad_iret() Lai Jiangshan
2022-04-06 19:00   ` Borislav Petkov [this message]
2022-04-07  7:03     ` Lai Jiangshan
2022-04-07  8:22       ` Borislav Petkov
2022-04-07 13:18         ` Borislav Petkov
2022-04-08  1:56           ` Lai Jiangshan
2022-04-11  9:36   ` Borislav Petkov
2022-03-18 14:30 ` [PATCH V4 2/7] x86/entry: Switch the stack after error_entry() returns Lai Jiangshan
2022-04-11  9:35   ` Borislav Petkov
2022-04-11 11:48     ` Lai Jiangshan
2022-03-18 14:30 ` [PATCH V4 3/7] x86/entry: move PUSH_AND_CLEAR_REGS out of error_entry Lai Jiangshan
2022-03-18 14:30 ` [PATCH V4 4/7] x86/entry: Move cld to the start of idtentry Lai Jiangshan
2022-03-18 14:30 ` [PATCH V4 5/7] x86/entry: Don't call error_entry for XENPV Lai Jiangshan
2022-03-18 14:30 ` [PATCH V4 6/7] x86/entry: Convert SWAPGS to swapgs and remove the definition of SWAPGS Lai Jiangshan
2022-03-18 14:30 ` [PATCH V4 7/7] x86/entry: Use idtentry macro for entry_INT80_compat Lai Jiangshan
2022-04-06 15:57 ` [PATCH V4 0/7] x86/entry: Clean up entry code Lai Jiangshan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yk3jVrXoVpxuR0Mp@zn.tnic \
    --to=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=jiangshan.ljs@antgroup.com \
    --cc=jiangshanlai@gmail.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.tai@oracle.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.