* Ingo Molnar wrote:
> * Andy Lutomirski wrote:
>
> > On Mon, Mar 14, 2016 at 11:40 AM, Linus Torvalds
> > wrote:
> > > On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski
> > > wrote:
> > >>
> > >>
* Andy Lutomirski wrote:
> On Mon, Mar 14, 2016 at 11:40 AM, Linus Torvalds
> wrote:
> > On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski
> > wrote:
> >>
> >> The code in my queue is, literally:
> >>
> >> bool
* Linus Torvalds wrote:
> On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski wrote:
> >
> > So yes, let's please warn. I'm okay with removing the panic_on_oops
> > thing though. (But if anyone suggests that we should stop OOPSing on
> > bad
On Mon, Mar 14, 2016 at 11:10:16AM -0700, Andy Lutomirski wrote:
> A couple of the wrmsr users actually care about performance. These
> are the ones involved in context switching and, to a lesser extent, in
> switching in and out of guest mode.
Right, this very much includes a number of perf
On Mon, Mar 14, 2016 at 11:40 AM, Linus Torvalds
wrote:
> On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski wrote:
>>
>> The code in my queue is, literally:
>>
>> bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup,
>>
On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski wrote:
>
> The code in my queue is, literally:
>
> bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup,
> struct pt_regs *regs, int trapnr)
> {
> WARN_ONCE(1, "unchecked MSR access
On Mon, Mar 14, 2016 at 11:15 AM, Linus Torvalds
wrote:
> On Mon, Mar 14, 2016 at 11:10 AM, Andy Lutomirski wrote:
>>
>> A couple of the wrmsr users actually care about performance. These
>> are the ones involved in context switching and, to a
On Mon, Mar 14, 2016 at 11:04 AM, Linus Torvalds
wrote:
> On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski wrote:
>>
>> So yes, let's please warn. I'm okay with removing the panic_on_oops
>> thing though. (But if anyone suggests that we
On Mon, Mar 14, 2016 at 11:10 AM, Andy Lutomirski wrote:
>
> A couple of the wrmsr users actually care about performance. These
> are the ones involved in context switching and, to a lesser extent, in
> switching in and out of guest mode.
.. ok, see the crossed emails.
I'd
On Mon, Mar 14, 2016 at 11:04 AM, Linus Torvalds
wrote:
>
> None of this insane complicated crap that buys us exactly *nothing*,
> and depends on fancy new exception handling support etc etc.
Actually, the one _new_ thing we could do is to instead of removing
the
On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski wrote:
>
> So yes, let's please warn. I'm okay with removing the panic_on_oops
> thing though. (But if anyone suggests that we should stop OOPSing on
> bad kernel page faults, I *will* fight back.)
Bad kernel page faults
On Mon, Mar 14, 2016 at 10:11 AM, Linus Torvalds
wrote:
>
> On Mar 14, 2016 10:05 AM, "Andy Lutomirski" wrote:
>>
>> We could probably remove that check and let custom fixups run early.
>> I don't see any compelling reason to keep them
On Mar 14, 2016 10:05 AM, "Andy Lutomirski" wrote:
>
> We could probably remove that check and let custom fixups run early.
> I don't see any compelling reason to keep them disabled. That should
> probably be a separate change, though.
Or we could just use the existing
On Mon, Mar 14, 2016 at 5:02 AM, Borislav Petkov wrote:
> On Sat, Mar 12, 2016 at 10:08:49AM -0800, Andy Lutomirski wrote:
>> This demotes an OOPS and likely panic due to a failed non-"safe" MSR
>> access to a WARN_ONCE and, for RDMSR, a return value of zero. If
>> panic_on_oops
On Sat, Mar 12, 2016 at 10:08:49AM -0800, Andy Lutomirski wrote:
> This demotes an OOPS and likely panic due to a failed non-"safe" MSR
> access to a WARN_ONCE and, for RDMSR, a return value of zero. If
> panic_on_oops is set, then failed unsafe MSR accesses will still
> oops and panic.
>
> To
This demotes an OOPS and likely panic due to a failed non-"safe" MSR
access to a WARN_ONCE and, for RDMSR, a return value of zero. If
panic_on_oops is set, then failed unsafe MSR accesses will still
oops and panic.
To be clear, this type of failure should *not* happen. This patch
exists to
16 matches
Mail list logo