[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4E95BFAA-A115-4159-AA4F-6AAB548C6E6C@gmail.com>
Date: Sat, 25 Jan 2020 14:43:33 -0800
From: Mark D Rustad <mrustad@...il.com>
To: "Luck, Tony" <tony.luck@...el.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Arvind Sankar <nivedita@...m.mit.edu>,
"Christopherson, Sean J" <sean.j.christopherson@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
"Yu, Fenghua" <fenghua.yu@...el.com>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
H Peter Anvin <hpa@...or.com>,
"Raj, Ashok" <ashok.raj@...el.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH v16] x86/split_lock: Enable split lock detection by kernel
On Jan 25, 2020, at 2:07 PM, Luck, Tony <tony.luck@...el.com> wrote:
> - Transitioning between modes at runtime isn't supported and disabling
> is tracked per task, so hardware will always reach a steady state that
> matches the configured mode.
Maybe "isn't supported" is not really the right wording. I would think that
if it truly weren't supported that you really shouldn't be changing the
mode at all at runtime. Do you really just mean "isn't atomic"? Or is there
something deeper about it? If so, are there other possible risks associated
with changing the mode at runtime?
Sorry, the wording just happened to catch my eye and my mind immediately
went to "how can you be doing something that is not supported?"
--
Mark Rustad, MRustad@...il.com
Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)
Powered by blists - more mailing lists