LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Harvey Harrison <harvey.harrison@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: Remove ifdef from step.c
Date: Thu, 10 Jan 2008 11:29:24 -0800	[thread overview]
Message-ID: <1199993365.19760.28.camel@brick> (raw)
In-Reply-To: <20080110124041.GA15156@elte.hu>

On Thu, 2008-01-10 at 13:40 +0100, Ingo Molnar wrote:
> * Harvey Harrison <harvey.harrison@gmail.com> wrote:
> 
> > @@ -148,11 +148,7 @@ static void write_debugctlmsr(struct task_struct *child, unsigned long val)
> >  	if (child != current)
> >  		return;
> >  
> > -#ifdef CONFIG_X86_64
> > -	wrmsrl(MSR_IA32_DEBUGCTLMSR, val);
> > -#else
> >  	wrmsr(MSR_IA32_DEBUGCTLMSR, val, 0);
> > -#endif
> 
> doesnt this break 64-bit? 'val' is 64-bit, but wrmsr truncates it to 
> 32-bit? [while wrmsrl() kept the full 64 bits]
> 

I wasn't totally sure about this, but believe in this case that it is
OK.  If not, we'll have to add this #ifdef back to restore_btf() in
kprobes.c which was lost Masami's unification.

But looking at how this is called, there shouldn't ever be anything in
the high 32 bits being written to (32 bit always wrote zero anyway).
In any event, it's going to be safer to use wrsmrl instead as you'll
get the zero extension on 32 bit and won't effect 64 bit.

Patch to follow.

Harvey


  reply	other threads:[~2008-01-10 19:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-10  7:18 Harvey Harrison
2008-01-10 12:40 ` Ingo Molnar
2008-01-10 19:29   ` Harvey Harrison [this message]
2008-01-10 19:40   ` [PATCH] x86: Use wrmsrl in kprobes.c, step.c Harvey Harrison
2008-01-10 19:49     ` H. Peter Anvin
2008-01-10 20:15       ` [PATCHv2] " Harvey Harrison

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1199993365.19760.28.camel@brick \
    --to=harvey.harrison@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH] x86: Remove ifdef from step.c' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).