All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Masami Hiramatsu <mhiramat@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	systemtap@sources.redhat.com,
	Harvey Harrison <harvey.harrison@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jan Blunck <jblunck@suse.de>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH -rc] [BUGFIX] x86: fix kernel_trap_sp()
Date: Tue, 12 May 2009 00:40:01 +0200	[thread overview]
Message-ID: <20090511224001.GA8198@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.01.0905111512240.3586@localhost.localdomain>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, 11 May 2009, Masami Hiramatsu wrote:
> >
> > Use &regs->sp instead of regs for getting the top of stack in kernel mode.
> > (on x86-64, regs->sp always points the top of stack)
> 
> Ack. 
> 
> That said, we have only _one_ use of this "kernel_trap_sp()" in 
> the whole kernel, and that use is actually fairly odd too, in that 
> it does it _before_ checking that it's in kernel mode.
> 
> Admittedly it will then only _use_ the value after it has checked 
> that things are in kernel mode, but it all boils down to "ok, 
> that's pretty odd".
> 
> So how about fixing that, and also fixing the naming of the 
> function. Call it "kernel_stack_pointer()" to match its more 
> widely used sibling function "user_stack_pointer()".
> 
> IOW, something like this?

yeah, this is cleaner and probably a tad faster. I've applied it to 
x86/urgent with your acked-by - or would you like to apply this 
straight away?

The use of the backtracing feature on the oprofile side is not very 
common (and the bug is ancient) so i wanted to wait a few days with 
this.

One small detail:

> +	return (unsigned long)(&regs->sp);

the original commit had:

> +	return (unsigned long)&regs->sp;

and this latter is correct as well due to operator priorities. No 
strong preference from my side so i took your version as-is. I kept 
Masami as the author and a comment for your changes.

( Not sure how to express this in a changelog properly - i didnt 
  want two commits but it was authored by two people in essence. So 
  i went for the version that will show up in the commit 
  notification email in a few minutes - also attached below. )

	Ingo

  reply	other threads:[~2009-05-11 22:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-11 21:03 [PATCH -rc] [BUGFIX] x86: fix kernel_trap_sp() Masami Hiramatsu
2009-05-11 21:51 ` [tip:x86/urgent] x86, 32-bit: " tip-bot for Masami Hiramatsu
2009-05-11 22:24 ` [PATCH -rc] [BUGFIX] x86: " Linus Torvalds
2009-05-11 22:40   ` Ingo Molnar [this message]
2009-05-11 22:52     ` Linus Torvalds
2009-05-12 11:23   ` Robin Holt
2009-05-12 14:20     ` Masami Hiramatsu
2009-05-12 14:36     ` Linus Torvalds
2009-05-11 22:39 ` [tip:x86/urgent] x86, 32-bit: " tip-bot for Masami Hiramatsu
2009-05-11 22:42 ` tip-bot for Masami Hiramatsu

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=20090511224001.GA8198@elte.hu \
    --to=mingo@elte.hu \
    --cc=harvey.harrison@gmail.com \
    --cc=hch@infradead.org \
    --cc=jblunck@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@redhat.com \
    --cc=systemtap@sources.redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.