From: Frederic Weisbecker <fweisbec@gmail.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: "H. Peter Anvin" <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@elte.hu>,
Stephane Eranian <eranian@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Soeren Sandmann Pedersen <sandmann@redhat.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 1/2] x86: Fix rbp saving in pt_regs on irq entry
Date: Thu, 6 Jan 2011 16:45:39 +0100 [thread overview]
Message-ID: <20110106154536.GA2308@nowhere> (raw)
In-Reply-To: <4D25EB4B020000780002ABF7@vpn.id2.novell.com>
On Thu, Jan 06, 2011 at 03:18:19PM +0000, Jan Beulich wrote:
> >>> On 06.01.11 at 15:51, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > From the x86_64 low level interrupt handlers, the frame pointer is
> > saved in pt_regs in the wrong place, in the offset of rbx.
> >
> > rbx is not part of the irq partial saved registers, so it's not
> > critical, but later code that uses get_irq_regs() to get the
> > interrupted frame pointer instead get a stale rbx value, causing
> > unwinding code to fail miserably.
>
> Code using get_irq_regs() can't rely on the not explicitly
> saved registers' fields of pt_regs anyway; you now fix this
> for %rbp, but someone else might look at a different
> register and want that to be saved too. You just shouldn't,
> and the fact that %rbp happens to be saved at all shouldn't
> be taken to mean you can access it via the provided
> pt_regs pointer. This saving of %rbp could go away or be
> done in a different way at any point.
Right. That was something I was wondering about: is rbp saved here
as the beginning of the proc stack, or was is supposed to be
part of the pt_regs although mistakenly recorded in rbp?
So given what you are explaining me, it rather seem it wasn't supposed
to be of part pt_regs and it's there because it begins the frame of the irq
handler.
I agree that in the case of common irqs, rbp is not supposed to be part
of saved regs. I think may be we can change that semantic though as it
requires very few changes. In fact the only added overhead is that addq
below.
I'm waiting for opinions though.
> > @@ -808,6 +813,8 @@ ret_from_intr:
> > TRACE_IRQS_OFF
> > decl PER_CPU_VAR(irq_count)
> > leaveq
> > + /* we did not save rbx, restore only from ARGOFFSET */
> > + addq $8, %rsp
> > CFI_RESTORE rbp
> > CFI_DEF_CFA_REGISTER rsp
> > CFI_ADJUST_CFA_OFFSET -8
>
> *If* the patch was to be taken anyway, I would strongly suggest
> getting this mis-insertion fixed first: CFI annotations belong to the
> immediately preceding instruction, and hence you must not insert
> new instructions between an existing one and its annotation.
Good to know, will fix.
> Furthermore, an adjustment to %rsp (when it serves as the frame
> pointer as is the case here, though would be better visible if the
> added instruction was at the right place) needs to be annotated
> itself.
Hmm, I'm not familiar with those CFI adjustments.
Before we had:
leaveq
CFI_RESTORE rbp
CFI_DEF_CFA_REGISTER rsp
CFI_ADJUST_CFA_OFFSET -8
So CFI_RESTORE means rbp has now the value of the base frame of
the calling frame (the base frame pointer of the interrupted proc) ?
And what follows means that rsp-8 points to the return address?
But it doesn't seem to be the case, the return address here beeing
rip stored in pt_regs...
I'm confused.
next prev parent reply other threads:[~2011-01-06 15:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-06 14:51 [RFC GIT PULL] perf updates Frederic Weisbecker
2011-01-06 14:51 ` [PATCH 2/2] perf: Build tools with frame pointer Frederic Weisbecker
2011-01-07 15:31 ` [tip:perf/core] perf tools: Build " tip-bot for Frederic Weisbecker
[not found] ` <1294325513-14276-2-git-send-email-fweisbec@gmail.com>
2011-01-06 15:18 ` [RFC PATCH 1/2] x86: Fix rbp saving in pt_regs on irq entry Jan Beulich
2011-01-06 15:45 ` Frederic Weisbecker [this message]
2011-01-06 16:10 ` Jan Beulich
2011-01-06 16:22 ` Frederic Weisbecker
2011-01-06 16:39 ` Jan Beulich
2011-01-06 16:54 ` Frederic Weisbecker
2011-01-06 16:58 ` Jan Beulich
2011-01-06 17:12 ` Frederic Weisbecker
2011-01-06 17:24 ` Frederic Weisbecker
2011-01-07 7:45 ` Jan Beulich
2011-01-07 12:31 ` Ingo Molnar
2011-01-07 16:05 ` Frederic Weisbecker
2011-01-07 16:13 ` Jan Beulich
2011-01-07 16:27 ` Frederic Weisbecker
2011-01-07 16:58 ` Ingo Molnar
2011-01-07 17:17 ` Frederic Weisbecker
2011-01-07 16:33 ` Frederic Weisbecker
2011-01-07 14:26 ` Frederic Weisbecker
2011-01-07 12:23 ` [RFC GIT PULL] perf updates Ingo Molnar
2011-01-07 15:24 ` Frederic Weisbecker
2011-01-07 15:37 ` Ingo Molnar
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=20110106154536.GA2308@nowhere \
--to=fweisbec@gmail.com \
--cc=JBeulich@novell.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sandmann@redhat.com \
--cc=tglx@linutronix.de \
/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.