From: Andrea Arcangeli <aarcange@redhat.com>
To: "Van De Ven, Arjan" <arjan.van.de.ven@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
Hou Tao <houtao1@huawei.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
"ak@linux.intel.com" <ak@linux.intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"qiuxishi@huawei.com" <qiuxishi@huawei.com>,
"wangkefeng.wang@huawei.com" <wangkefeng.wang@huawei.com>
Subject: Re: [RH72 Spectre] ibpb_enabled = 1 leads to hard LOCKUP under x86_64 host machine
Date: Sat, 20 Jan 2018 16:22:29 +0100 [thread overview]
Message-ID: <20180120152229.GA2042@redhat.com> (raw)
In-Reply-To: <0575AF4FD06DD142AD198903C74E1CC87A5EC9AE@ORSMSX103.amr.corp.intel.com>
Hello everyone,
On Sat, Jan 20, 2018 at 01:56:08PM +0000, Van De Ven, Arjan wrote:
> well first of all don't use IBRS, use retpoline
This issue triggers in the IBPB code during user to user context
switch and IBPB is still needed there no matter if kernel is using
retpolines or if it uses kernel IBRS. In fact IBPB is still needed
there even if retpolines+user_ibrs is used or if
always_ibrs/ibrs_enabled=2 is used (IBRS doesn't protect from the
poison generated in the same predictor mode, "especially" in future
CPUs).
Only retpolining all userland would avoid IBPB here, but I doubt you
suggest that.
Kernel retpolines or kernel IBRS would make zero difference for
this specific issue.
> and if Andrea says this was a known issue in their code then I think that closes the issue.
>
It's an implementation bug we inherited from the merge of a CPU vendor
patch and I can confirm it's already closed. The fix has been already
shipped with the wave 2 update in fact and some other versions even
had the bug fixed since the very first wave on 0day.
That deadlock nuisance only ever triggered in artificial QA testcases
and even then it wasn't easily reproducible.
We already moved the follow ups in vendor BZ to avoid using bandwidth
here.
Thank you!
Andrea
prev parent reply other threads:[~2018-01-20 15:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-20 9:00 [RH72 Spectre] ibpb_enabled = 1 leads to hard LOCKUP under x86_64 host machine Hou Tao
2018-01-20 9:03 ` David Woodhouse
2018-01-20 13:56 ` Van De Ven, Arjan
2018-01-20 15:22 ` Andrea Arcangeli [this message]
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=20180120152229.GA2042@redhat.com \
--to=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=arjan.van.de.ven@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=houtao1@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qiuxishi@huawei.com \
--cc=tglx@linutronix.de \
--cc=wangkefeng.wang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).