[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <C3302B2F-177F-4C39-910E-EADBA9285DD0@intel.com>
Date: Sat, 25 Jan 2020 23:10:00 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Mark D Rustad <mrustad@...il.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
>
> 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
The “modes” here means the three option selectable by command line option. Off/warn/fatal. Some earlier versions of this patch had a sysfs interface to switch things around.
Not whether we have the MSR enabled/disabled.
If Thomas or Boris finds more things to fix then I’ll take a look at clarifying this comment too.
-Tony
Powered by blists - more mailing lists