On 12/13/2012 11:05 AM, Borislav Petkov wrote:
>
> Ok, I grok it now. So, in most cases, mce.ip comes from pt_regs.ip which
> is unsigned long so we're fine for both 32- and 64-bit. There's only the
> case with precise RIP reporting where we get the rip from an MSR but
> even then, it should be 4 b
On Thu, Dec 13, 2012 at 10:42:28AM -0800, H. Peter Anvin wrote:
> On 12/13/2012 10:37 AM, Borislav Petkov wrote:
> >>
> >> If appropriate, the code could be changed to
> >>
> >>(void *)(unsigned long)m->ip
> >
> > Can we explicitly cast it to what it is so that we can be explicit as to
> > wha
On Wed, 2012-12-12 at 23:45 +0100, Borislav Petkov wrote:
> On Wed, Dec 12, 2012 at 02:23:59PM -0800, Joe Perches wrote:
> > On Wed, 2012-12-12 at 21:49 +, Luck, Tony wrote:
> > > > I think I'd go ahead and ACK this unless Tony has some comments. I'm not
> > > > happy about the two pr_emerg cal
On Thu, 2012-12-13 at 19:37 +0100, Borislav Petkov wrote:
> On Thu, Dec 13, 2012 at 10:23:10AM -0800, Joe Perches wrote:
> > m->ip is a u64 so, when compiling x86-32, there's a new warning
> > "cast to pointer from integer of different size". This isn't new
> > different behavior, just a new warni
On Thu, Dec 13, 2012 at 10:23:10AM -0800, Joe Perches wrote:
> m->ip is a u64 so, when compiling x86-32, there's a new warning
> "cast to pointer from integer of different size". This isn't new
> different behavior, just a new warning. The previous print_symbol
> took a ulong and the u64 was sile
On 12/13/2012 10:37 AM, Borislav Petkov wrote:
>>
>> If appropriate, the code could be changed to
>>
>> (void *)(unsigned long)m->ip
>
> Can we explicitly cast it to what it is so that we can be explicit as to
> what we're casting it? IOW:
>
> (void *)(__u64)m->ip;
>
> Does that even
On Wed, 2012-12-12 at 22:09 +0100, Borislav Petkov wrote:
> On Wed, Dec 12, 2012 at 10:19:05AM -0800, Joe Perches wrote:
> > Use the new vsprintf extension to avoid any possible
> > message interleaving.
[]
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> > b/arch/x86/kernel/cpu/mcheck/mce.c
[]
On Wed, Dec 12, 2012 at 01:30:03PM -0800, Joe Perches wrote:
> > I think I'd go ahead and ACK this unless Tony has some comments. I'm
> > not happy about the two pr_emerg calls based on the conditional.
>
> It was done to avoid interleaving.
Right.
> > Or, Tony, what do you think, could we get aw
> I think I'd go ahead and ACK this unless Tony has some comments. I'm not
> happy about the two pr_emerg calls based on the conditional.
As written the patch has the nice property of not making any changes to the
console output (except to eliminate the possibility of interleaved output that
the o
On Wed, Dec 12, 2012 at 02:23:59PM -0800, Joe Perches wrote:
> On Wed, 2012-12-12 at 21:49 +, Luck, Tony wrote:
> > > I think I'd go ahead and ACK this unless Tony has some comments. I'm not
> > > happy about the two pr_emerg calls based on the conditional.
> >
> > As written the patch has the
On Wed, 2012-12-12 at 21:49 +, Luck, Tony wrote:
> > I think I'd go ahead and ACK this unless Tony has some comments. I'm not
> > happy about the two pr_emerg calls based on the conditional.
>
> As written the patch has the nice property of not making any changes to the
> console output (excep
On Wed, Dec 12, 2012 at 10:19:05AM -0800, Joe Perches wrote:
> Use the new vsprintf extension to avoid any possible
> message interleaving.
>
> Signed-off-by: Joe Perches
> ---
> arch/x86/kernel/cpu/mcheck/mce.c | 13 +++--
> arch/x86/kernel/dumpstack.c |5 ++---
> arch/x86/ke
Use the new vsprintf extension to avoid any possible
message interleaving.
Signed-off-by: Joe Perches
---
arch/x86/kernel/cpu/mcheck/mce.c | 13 +++--
arch/x86/kernel/dumpstack.c |5 ++---
arch/x86/kernel/process_32.c |2 +-
arch/x86/mm/mmio-mod.c |4 ++--
13 matches
Mail list logo
