linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	DRI <dri-devel@lists.freedesktop.org>
Subject: [PATCH] drm/vmwgfx: fix "duplicate frame pointer save" warning
Date: Thu, 26 May 2016 13:43:43 -0500	[thread overview]
Message-ID: <20160526184343.fdtjjjg67smmeekt@treble> (raw)
In-Reply-To: <CA+55aFy2o8_M7XqZV__sTS0z+a_Wqr7tjHPm8tN0ZMdErFQXRQ@mail.gmail.com>

On Wed, May 25, 2016 at 04:51:21PM -0700, Linus Torvalds wrote:
> On Wed, May 25, 2016 at 10:56 AM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > I used to have a STACKTOOL_IGNORE_INSN macro that would tell the tool to
> > skip warnings for specific instructions in inline asm:
> >
> > Here's an example of it how it was used:
> 
> Ok, looking at that, I'm starting to suspect that it is simpler to
> just use STACK_FRAME_NON_STANDARD and mark the two functions that use
> this particular inline asm with the odd %rbp problem.
> 
> It's a rather special case, after all.

That's fine with me, it is indeed a rare case.  We can always add the
per-instruction macro later if needed.  Here's a patch.

---

From: Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH] drm/vmwgfx: fix "duplicate frame pointer save" warning

objtool reports the following warnings:

  drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: warning: objtool: vmw_send_msg()+0x107: duplicate frame pointer save
  drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: warning: objtool: vmw_host_get_guestinfo()+0x252: duplicate frame pointer save

To quote Linus:

 "The reason is that VMW_PORT_HB_OUT() uses a magic instruction sequence
  (a "rep outsb") to communicate with the hypervisor (it's a virtual GPU
  driver for vmware), and %rbp is part of the communication. So the
  inline asm does a save-and-restore of the frame pointer around the
  instruction sequence.

  I actually find the objtool warning to be quite reasonable, so it's
  not exactly a false positive, since in this case it actually does
  point out that the frame pointer won't be reliable over that
  instruction sequence.

  But in this particular case it just ends up being the wrong thing -
  the code is what it is, and %rbp just can't have the frame information
  due to annoying magic calling conventions."

Silence the warnings by telling objtool to ignore the two functions
which use the VMW_PORT_HB_{IN,OUT} macros.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index 6de283c..f0374f9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -28,6 +28,7 @@
 #include <linux/slab.h>
 #include <linux/module.h>
 #include <linux/kernel.h>
+#include <linux/frame.h>
 #include <asm/hypervisor.h>
 #include "drmP.h"
 #include "vmwgfx_msg.h"
@@ -194,7 +195,7 @@ static int vmw_send_msg(struct rpc_channel *channel, const char *msg)
 
 	return -EINVAL;
 }
-
+STACK_FRAME_NON_STANDARD(vmw_send_msg);
 
 
 /**
@@ -304,6 +305,7 @@ static int vmw_recv_msg(struct rpc_channel *channel, void **msg,
 
 	return 0;
 }
+STACK_FRAME_NON_STANDARD(vmw_recv_msg);
 
 
 /**
-- 
2.4.11

  reply	other threads:[~2016-05-26 18:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-25 17:14 objtool warning: "duplicate frame pointer save" Linus Torvalds
2016-05-25 17:56 ` Josh Poimboeuf
2016-05-25 23:51   ` Linus Torvalds
2016-05-26 18:43     ` Josh Poimboeuf [this message]
2016-05-26 18:58       ` [PATCH] drm/vmwgfx: fix "duplicate frame pointer save" warning Linus Torvalds
2016-06-08 14:27       ` [tip:core/urgent] objtool, drm/vmwgfx: Fix " tip-bot for Josh Poimboeuf

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=20160526184343.fdtjjjg67smmeekt@treble \
    --to=jpoimboe@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --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 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).