All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	"Andy Lutomirski" <luto@kernel.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	kvm@vger.kernel.org, "Jason A. Donenfeld" <Jason@zx2c4.com>,
	"Rik van Riel" <riel@surriel.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>
Subject: Re: [PATCH 07/22] x86/fpu: Remove fpu->initialized
Date: Thu, 24 Jan 2019 14:34:49 +0100	[thread overview]
Message-ID: <20190124133449.GC11554@zn.tnic> (raw)
In-Reply-To: <20190109114744.10936-8-bigeasy@linutronix.de>

On Wed, Jan 09, 2019 at 12:47:29PM +0100, Sebastian Andrzej Siewior wrote:
> The `initialized' member of the fpu struct is always set to one user
								 ^
								 for

> tasks and zero for kernel tasks. This avoids saving/restoring the FPU
> registers for kernel threads.
> 
> I expect that fpu->initialized is always 1 and the 0 case has been

"I expect" reads funny. Make that impartial and passive and "expecting"
is the wrong formulation. It needs to be a clear statement talking about
the FPU context's state and why that state is always initialized.

> removed or is not important. For instance fpu__drop() sets the value to
> zero and its caller call either fpu__initialize() (which would

"its callers invoke" or so

> set it back to one) or don't return to userland.
> 
> The context switch code (switch_fpu_prepare() + switch_fpu_finish())
> can't unconditionally save/restore registers for kernel threads. I have
> no idea what will happen if we restore a zero FPU context for the kernel
> thread (since it never was initialized).

Yeah, avoid those "author is wondering" statements.

> Also it has been agreed that
> for PKRU we don't want a random state (inherited from the previous task)
> but a deterministic one.

Rewrite that to state what the PKRU state is going to be.

> For kernel_fpu_begin() (+end) the situation is similar: The kernel test
> bot told me, that EFI with runtime services uses this before
> alternatives_patched is true. Which means that this function is used too
> early and it wasn't the case before.
> 
> For those two cases current->mm is used to determine between user &
> kernel thread.

Now that we start looking at ->mm, I think we should document this
somewhere prominently, maybe

  arch/x86/include/asm/fpu/internal.h

or so along with all the logic this patchset changes wrt FPU handling.
Then we wouldn't have to wonder in the future why stuff is being done
the way it is done.

Like the FPU saving on the user stack frame or why this was needed:

-	/* Update the thread's fxstate to save the fsave header. */
-	if (ia32_fxstate)
-		copy_fxregs_to_kernel(fpu);

Some sort of a high-level invariants written down would save us a lot of
head scratching in the future.

> For kernel_fpu_begin() we skip save/restore of the FPU
> registers.
> During the context switch into a kernel thread we don't do anything.
> There is no reason to save the FPU state of a kernel thread.
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  arch/x86/ia32/ia32_signal.c         | 17 +++-----
>  arch/x86/include/asm/fpu/internal.h | 15 +++----
>  arch/x86/include/asm/fpu/types.h    |  9 ----
>  arch/x86/include/asm/trace/fpu.h    |  5 +--
>  arch/x86/kernel/fpu/core.c          | 68 ++++++++---------------------
>  arch/x86/kernel/fpu/init.c          |  2 -
>  arch/x86/kernel/fpu/regset.c        | 19 ++------
>  arch/x86/kernel/fpu/xstate.c        |  2 -
>  arch/x86/kernel/process_32.c        |  4 +-
>  arch/x86/kernel/process_64.c        |  4 +-
>  arch/x86/kernel/signal.c            | 17 +++-----
>  arch/x86/mm/pkeys.c                 |  7 +--
>  12 files changed, 49 insertions(+), 120 deletions(-)

...

> diff --git a/arch/x86/include/asm/trace/fpu.h b/arch/x86/include/asm/trace/fpu.h
> index 069c04be15076..bd65f6ba950f8 100644
> --- a/arch/x86/include/asm/trace/fpu.h
> +++ b/arch/x86/include/asm/trace/fpu.h
> @@ -13,22 +13,19 @@ DECLARE_EVENT_CLASS(x86_fpu,
>  
>  	TP_STRUCT__entry(
>  		__field(struct fpu *, fpu)
> -		__field(bool, initialized)
>  		__field(u64, xfeatures)
>  		__field(u64, xcomp_bv)
>  		),

Yikes, can you do that?

rostedt has been preaching that adding members at the end of tracepoints
is ok but not changing them in the middle as that breaks ABI.

Might wanna ping him about it first.

>  
>  	TP_fast_assign(
>  		__entry->fpu		= fpu;
> -		__entry->initialized	= fpu->initialized;
>  		if (boot_cpu_has(X86_FEATURE_OSXSAVE)) {
>  			__entry->xfeatures = fpu->state.xsave.header.xfeatures;
>  			__entry->xcomp_bv  = fpu->state.xsave.header.xcomp_bv;
>  		}
>  	),
> -	TP_printk("x86/fpu: %p initialized: %d xfeatures: %llx xcomp_bv: %llx",
> +	TP_printk("x86/fpu: %p xfeatures: %llx xcomp_bv: %llx",
>  			__entry->fpu,
> -			__entry->initialized,
>  			__entry->xfeatures,
>  			__entry->xcomp_bv
>  	)
> diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
> index e43296854e379..3a4668c9d24f1 100644
> --- a/arch/x86/kernel/fpu/core.c
> +++ b/arch/x86/kernel/fpu/core.c
> @@ -101,7 +101,7 @@ static void __kernel_fpu_begin(void)
>  
>  	kernel_fpu_disable();
>  
> -	if (fpu->initialized) {
> +	if (current->mm) {
>  		/*
>  		 * Ignore return value -- we don't care if reg state
>  		 * is clobbered.
> @@ -116,7 +116,7 @@ static void __kernel_fpu_end(void)
>  {
>  	struct fpu *fpu = &current->thread.fpu;
>  
> -	if (fpu->initialized)
> +	if (current->mm)
>  		copy_kernel_to_fpregs(&fpu->state);
>  
>  	kernel_fpu_enable();
> @@ -147,10 +147,9 @@ void fpu__save(struct fpu *fpu)
>  
>  	preempt_disable();
>  	trace_x86_fpu_before_save(fpu);
> -	if (fpu->initialized) {
> -		if (!copy_fpregs_to_fpstate(fpu)) {
> -			copy_kernel_to_fpregs(&fpu->state);
> -		}
> +
> +	if (!copy_fpregs_to_fpstate(fpu)) {
> +		copy_kernel_to_fpregs(&fpu->state);
>  	}

WARNING: braces {} are not necessary for single statement blocks
#217: FILE: arch/x86/kernel/fpu/core.c:151:
+       if (!copy_fpregs_to_fpstate(fpu)) {
+               copy_kernel_to_fpregs(&fpu->state);
        }


...

> diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
> index 7888a41a03cdb..77d9eb43ccac8 100644
> --- a/arch/x86/kernel/process_32.c
> +++ b/arch/x86/kernel/process_32.c
> @@ -288,10 +288,10 @@ __switch_to(struct task_struct *prev_p, struct task_struct *next_p)
>  	if (prev->gs | next->gs)
>  		lazy_load_gs(next->gs);
>  
> -	switch_fpu_finish(next_fpu, cpu);
> -
>  	this_cpu_write(current_task, next_p);
>  
> +	switch_fpu_finish(next_fpu, cpu);
> +
>  	/* Load the Intel cache allocation PQR MSR. */
>  	resctrl_sched_in();
>  
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index e1983b3a16c43..ffea7c557963a 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -566,14 +566,14 @@ __switch_to(struct task_struct *prev_p, struct task_struct *next_p)
>  
>  	x86_fsgsbase_load(prev, next);
>  
> -	switch_fpu_finish(next_fpu, cpu);
> -
>  	/*
>  	 * Switch the PDA and FPU contexts.
>  	 */
>  	this_cpu_write(current_task, next_p);
>  	this_cpu_write(cpu_current_top_of_stack, task_top_of_stack(next_p));
>  
> +	switch_fpu_finish(next_fpu, cpu);
> +
>  	/* Reload sp0. */
>  	update_task_stack(next_p);
>  

Those moves need at least a comment in the commit message or a separate
patch.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

  reply	other threads:[~2019-01-24 13:35 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09 11:47 [PATCH v6] x86: load FPU registers on return to userland Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 01/22] x86/fpu: Remove fpu->initialized usage in __fpu__restore_sig() Sebastian Andrzej Siewior
2019-01-14 16:24   ` Borislav Petkov
2019-02-05 10:08     ` Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 02/22] x86/fpu: Remove fpu__restore() Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 03/22] x86/fpu: Remove preempt_disable() in fpu__clear() Sebastian Andrzej Siewior
2019-01-14 18:55   ` Borislav Petkov
2019-01-09 11:47 ` [PATCH 04/22] x86/fpu: Always init the `state' " Sebastian Andrzej Siewior
2019-01-14 19:32   ` Borislav Petkov
2019-01-09 11:47 ` [PATCH 05/22] x86/fpu: Remove fpu->initialized usage in copy_fpstate_to_sigframe() Sebastian Andrzej Siewior
2019-01-16 19:36   ` Borislav Petkov
2019-01-16 22:40     ` Sebastian Andrzej Siewior
2019-01-17 12:22       ` Borislav Petkov
2019-01-18 21:14         ` Sebastian Andrzej Siewior
2019-01-18 21:17           ` Dave Hansen
2019-01-18 21:37             ` Sebastian Andrzej Siewior
2019-01-18 21:43               ` Dave Hansen
2019-01-21 11:21             ` Oleg Nesterov
2019-01-22 13:40               ` Borislav Petkov
2019-01-22 16:15                 ` Oleg Nesterov
2019-01-22 17:00                   ` Borislav Petkov
2019-02-05 11:34                     ` Sebastian Andrzej Siewior
2019-02-05 11:17               ` Sebastian Andrzej Siewior
2019-02-26 16:38                 ` Oleg Nesterov
2019-03-08 18:12                   ` Sebastian Andrzej Siewior
2019-02-05 14:37         ` [PATCH 05/22 v2] " Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 06/22] x86/fpu: Don't save fxregs for ia32 frames " Sebastian Andrzej Siewior
2019-01-24 11:17   ` Borislav Petkov
2019-02-05 16:43     ` [PATCH 06/22 v2] x86/fpu: Don't save fxregs for ia32 frames in Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 07/22] x86/fpu: Remove fpu->initialized Sebastian Andrzej Siewior
2019-01-24 13:34   ` Borislav Petkov [this message]
2019-02-05 18:03     ` Sebastian Andrzej Siewior
2019-02-06 14:01       ` Borislav Petkov
2019-02-07 10:13         ` Sebastian Andrzej Siewior
2019-02-07 10:37           ` Borislav Petkov
2019-02-05 18:06     ` [PATCH 07/22 v2] " Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 08/22] x86/fpu: Remove user_fpu_begin() Sebastian Andrzej Siewior
2019-01-25 15:18   ` Borislav Petkov
2019-02-05 18:16     ` Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 09/22] x86/fpu: Add (__)make_fpregs_active helpers Sebastian Andrzej Siewior
2019-01-28 18:23   ` Borislav Petkov
2019-02-07 10:43     ` Sebastian Andrzej Siewior
2019-02-13  9:30       ` Borislav Petkov
2019-02-14 14:51         ` Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 10/22] x86/fpu: Make __raw_xsave_addr() use feature number instead of mask Sebastian Andrzej Siewior
2019-01-28 18:30   ` Borislav Petkov
2019-01-09 11:47 ` [PATCH 11/22] x86/fpu: Make get_xsave_field_ptr() and get_xsave_addr() " Sebastian Andrzej Siewior
2019-01-28 18:49   ` Borislav Petkov
2019-02-07 11:13     ` Sebastian Andrzej Siewior
2019-02-13  9:31       ` Borislav Petkov
2019-01-09 11:47 ` [PATCH 12/22] x86/fpu: Only write PKRU if it is different from current Sebastian Andrzej Siewior
2019-01-23 18:09   ` Dave Hansen
2019-02-07 11:27     ` Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 13/22] x86/pkeys: Don't check if PKRU is zero before writting it Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 14/22] x86/fpu: Eager switch PKRU state Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 15/22] x86/entry: Add TIF_NEED_FPU_LOAD Sebastian Andrzej Siewior
2019-01-30 11:55   ` Borislav Petkov
2019-02-07 11:49     ` Sebastian Andrzej Siewior
2019-02-13  9:35       ` Borislav Petkov
2019-02-14 15:28         ` Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 16/22] x86/fpu: Always store the registers in copy_fpstate_to_sigframe() Sebastian Andrzej Siewior
2019-01-30 11:43   ` Borislav Petkov
2019-02-07 13:28     ` Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 17/22] x86/fpu: Prepare copy_fpstate_to_sigframe() for TIF_NEED_FPU_LOAD Sebastian Andrzej Siewior
2019-01-30 11:56   ` Borislav Petkov
2019-01-30 12:28     ` Sebastian Andrzej Siewior
2019-01-30 12:53       ` Borislav Petkov
2019-02-07 14:10         ` Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 18/22] x86/fpu: Update xstate's PKRU value on write_pkru() Sebastian Andrzej Siewior
2019-01-23 17:28   ` Dave Hansen
2019-01-09 11:47 ` [PATCH 19/22] x86/fpu: Inline copy_user_to_fpregs_zeroing() Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 20/22] x86/fpu: Let __fpu__restore_sig() restore the !32bit+fxsr frame from kernel memory Sebastian Andrzej Siewior
2019-01-30 21:29   ` Borislav Petkov
2019-01-09 11:47 ` [PATCH 21/22] x86/fpu: Merge the two code paths in __fpu__restore_sig() Sebastian Andrzej Siewior
2019-01-09 11:47 ` [PATCH 22/22] x86/fpu: Defer FPU state load until return to userspace Sebastian Andrzej Siewior
2019-01-31  9:16   ` Borislav Petkov
2019-01-15 12:44 ` [PATCH v6] x86: load FPU registers on return to userland David Laight
2019-01-15 13:15   ` 'Sebastian Andrzej Siewior'
2019-01-15 14:33     ` David Laight
2019-01-15 19:46   ` Dave Hansen
2019-01-15 20:26     ` Andy Lutomirski
2019-01-15 20:54       ` Dave Hansen
2019-01-15 21:11         ` Andy Lutomirski
2019-01-16 10:31           ` David Laight
2019-01-16 10:18       ` David Laight
2019-01-30 11:35 ` Borislav Petkov
2019-01-30 12:06   ` Sebastian Andrzej Siewior
2019-01-30 12:27     ` Borislav Petkov
2019-02-08 13:12       ` Sebastian Andrzej Siewior
2019-02-13 15:54         ` Sebastian Andrzej Siewior
2019-02-21 11:49 [PATCH v7] " Sebastian Andrzej Siewior
2019-02-21 11:50 ` [PATCH 07/22] x86/fpu: Remove fpu->initialized Sebastian Andrzej Siewior

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=20190124133449.GC11554@zn.tnic \
    --to=bp@alien8.de \
    --cc=Jason@zx2c4.com \
    --cc=bigeasy@linutronix.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=riel@surriel.com \
    --cc=rkrcmar@redhat.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.