From patchwork Thu May 26 18:43:43 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josh Poimboeuf X-Patchwork-Id: 9137823 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 280C66075C for ; Fri, 27 May 2016 07:52:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 19D0A27C23 for ; Fri, 27 May 2016 07:52:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0DC0727D10; Fri, 27 May 2016 07:52:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8E2D527C23 for ; Fri, 27 May 2016 07:52:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B7F436EBAE; Fri, 27 May 2016 07:52:36 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2CAC86E27E for ; Thu, 26 May 2016 18:43:45 +0000 (UTC) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B880271094; Thu, 26 May 2016 18:43:44 +0000 (UTC) Received: from treble (ovpn-116-74.phx2.redhat.com [10.3.116.74]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id u4QIhh4r016820; Thu, 26 May 2016 14:43:44 -0400 Date: Thu, 26 May 2016 13:43:43 -0500 From: Josh Poimboeuf To: Linus Torvalds Subject: [PATCH] drm/vmwgfx: fix "duplicate frame pointer save" warning Message-ID: <20160526184343.fdtjjjg67smmeekt@treble> References: <20160525175631.44xgcylo24ysftss@treble> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 26 May 2016 18:43:44 +0000 (UTC) X-Mailman-Approved-At: Fri, 27 May 2016 07:52:33 +0000 Cc: Ingo Molnar , DRI , Linux Kernel Mailing List X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP On Wed, May 25, 2016 at 04:51:21PM -0700, Linus Torvalds wrote: > On Wed, May 25, 2016 at 10:56 AM, Josh Poimboeuf 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 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 Signed-off-by: Josh Poimboeuf --- 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 #include #include +#include #include #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); /**