[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55FADCBD.4070804@linux.intel.com>
Date: Thu, 17 Sep 2015 08:31:09 -0700
From: Arjan van de Ven <arjan@...ux.intel.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
Andy Lutomirski <luto@...capital.net>,
Ingo Molnar <mingo@...nel.org>
Cc: Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
KVM list <kvm@...r.kernel.org>,
xen-devel <Xen-devel@...ts.xen.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrew Morton <akpm@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops
On 9/17/2015 8:29 AM, Paolo Bonzini wrote:
>
>
> On 17/09/2015 17:27, Arjan van de Ven wrote:
>>>
>>>> ( We should double check that rdmsr()/wrmsr() results are never left
>>>> uninitialized, but are set to zero or so, for cases where the
>>>> return code is not
>>>> checked. )
>>>
>>> It sure looks like native_read_msr_safe doesn't clear the output if
>>> the rdmsr fails.
>>
>> I'd suggest to return some poison not just 0...
>
> What about 0 + WARN?
why 0?
0xdeadbeef or any other pattern (even 0x3636363636) makes more sense (of course also WARN... but most folks don't read dmesg for WARNs)
(it's the same thing we do for list or slab poison stuff)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists