All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: kernel test robot <ying.huang@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	lkp@01.org, LKML <linux-kernel@vger.kernel.org>,
	yu-cheng yu <yu-cheng.yu@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>,
	Rik van Riel <riel@redhat.com>,
	Quentin Casasnovas <quentin.casasnovas@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@amacapital.net>
Subject: Re: [lkp] [x86/fpu] 58122bf1d8: WARNING: CPU: 0 PID: 1 at arch/x86/include/asm/fpu/internal.h:529 fpu__restore+0x28f/0x9ab()
Date: Sat, 27 Feb 2016 14:13:37 +0100	[thread overview]
Message-ID: <20160227131337.GB5261@pd.tnic> (raw)
In-Reply-To: <20160227120211.GA25164@gmail.com>

On Sat, Feb 27, 2016 at 01:02:11PM +0100, Ingo Molnar wrote:
> So I'm wondering, why did this commit:
> 
>   58122bf1d856 x86/fpu: Default eagerfpu=on on all CPUs
> 

Hmm, so looking at switch_fpu_prepare():

        /*
         * If the task has used the math, pre-load the FPU on xsave processors
         * or if the past 5 consecutive context-switches used math.
         */
        fpu.preload = static_cpu_has(X86_FEATURE_FPU) &&
                      new_fpu->fpstate_active &&
                      (use_eager_fpu() || new_fpu->counter > 5);
		       ^^^^^^^^^^^^^^

and later:

        if (old_fpu->fpregs_active) {

		...

                /* Don't change CR0.TS if we just switch! */
                if (fpu.preload) {
			...
                        __fpregs_activate(new_fpu);


so I can see a possible link between 58122bf1d856 and what we're seeing.

But as I've told you offlist, I couldn't confirm that this commit was
the culprit due to my simulated reproducer. So I'm thinking the 0day
guys have a more reliable one.

> trigger the warning, while it never triggered on CPUs that were already 
> eagerfpu=on for years?

That I can't explain... yet.

FWIW, the one time splat I saw, happened on an IVB machine on 32-bit
which has always been eagerfpu=on.

> There must be something we are still missing I think.

Yeah.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: lkp@lists.01.org
Subject: Re: [x86/fpu] 58122bf1d8: WARNING: CPU: 0 PID: 1 at arch/x86/include/asm/fpu/internal.h:529 fpu__restore+0x28f/0x9ab()
Date: Sat, 27 Feb 2016 14:13:37 +0100	[thread overview]
Message-ID: <20160227131337.GB5261@pd.tnic> (raw)
In-Reply-To: <20160227120211.GA25164@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

On Sat, Feb 27, 2016 at 01:02:11PM +0100, Ingo Molnar wrote:
> So I'm wondering, why did this commit:
> 
>   58122bf1d856 x86/fpu: Default eagerfpu=on on all CPUs
> 

Hmm, so looking at switch_fpu_prepare():

        /*
         * If the task has used the math, pre-load the FPU on xsave processors
         * or if the past 5 consecutive context-switches used math.
         */
        fpu.preload = static_cpu_has(X86_FEATURE_FPU) &&
                      new_fpu->fpstate_active &&
                      (use_eager_fpu() || new_fpu->counter > 5);
		       ^^^^^^^^^^^^^^

and later:

        if (old_fpu->fpregs_active) {

		...

                /* Don't change CR0.TS if we just switch! */
                if (fpu.preload) {
			...
                        __fpregs_activate(new_fpu);


so I can see a possible link between 58122bf1d856 and what we're seeing.

But as I've told you offlist, I couldn't confirm that this commit was
the culprit due to my simulated reproducer. So I'm thinking the 0day
guys have a more reliable one.

> trigger the warning, while it never triggered on CPUs that were already 
> eagerfpu=on for years?

That I can't explain... yet.

FWIW, the one time splat I saw, happened on an IVB machine on 32-bit
which has always been eagerfpu=on.

> There must be something we are still missing I think.

Yeah.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

  reply	other threads:[~2016-02-27 13:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26  1:13 [x86/fpu] 58122bf1d8: WARNING: CPU: 0 PID: 1 at arch/x86/include/asm/fpu/internal.h:529 fpu__restore+0x28f/0x9ab() kernel test robot
2016-02-26  7:49 ` [lkp] " Borislav Petkov
2016-02-26  7:49   ` Borislav Petkov
2016-02-27 12:02   ` [lkp] " Ingo Molnar
2016-02-27 12:02     ` Ingo Molnar
2016-02-27 13:13     ` Borislav Petkov [this message]
2016-02-27 13:13       ` Borislav Petkov
2018-11-20 12:05   ` [tip:x86/urgent] x86/fpu: Disable bottom halves while loading FPU registers tip-bot for Sebastian Andrzej Siewior
2018-11-20 16:29   ` tip-bot for Sebastian Andrzej Siewior
2018-11-19 16:04 [PATCH v2] x86/fpu: Disable BH while while loading FPU registers in __fpu__restore_sig() Sebastian Andrzej Siewior
2018-11-19 17:02 ` Dave Hansen
2018-11-19 17:11   ` Sebastian Andrzej Siewior
2018-11-19 17:27     ` Borislav Petkov
2018-11-19 17:31       ` Sebastian Andrzej Siewior
2018-11-19 17:41         ` Borislav Petkov
2018-11-19 17:32       ` Dave Hansen
2018-11-19 18:10 ` Borislav Petkov
2018-11-20 10:26   ` [PATCH v3] " Sebastian Andrzej Siewior
     [not found] ` <20181120132531.6E80C206BB@mail.kernel.org>
2018-11-20 18:34   ` [PATCH v2] " Borislav Petkov
2018-11-21  6:11     ` Victoria Anosova
2018-11-21 10:56       ` Borislav Petkov
2018-11-21 12:41         ` Victoria Anosova
2018-11-21 12:54           ` Boris Petkov
2018-11-21 12:54             ` Boris Petkov

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=20160227131337.GB5261@pd.tnic \
    --to=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=quentin.casasnovas@oracle.com \
    --cc=riel@redhat.com \
    --cc=sai.praneeth.prakhya@intel.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=ying.huang@linux.intel.com \
    --cc=yu-cheng.yu@intel.com \
    /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.