From: <gregkh@linuxfoundation.org>
To: thellstrom@vmware.com, brianp@vmware.com,
gregkh@linuxfoundation.org, syeh@vmware.com
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "drm/vmwgfx: Avoid validating views on view destruction" has been added to the 4.8-stable tree
Date: Sat, 29 Oct 2016 09:20:06 -0400 [thread overview]
Message-ID: <14777472068160@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Avoid validating views on view destruction
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-vmwgfx-avoid-validating-views-on-view-destruction.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From a19440304db2d97aed5cee9bfa5017c98d2348bf Mon Sep 17 00:00:00 2001
From: Thomas Hellstrom <thellstrom@vmware.com>
Date: Mon, 10 Oct 2016 11:06:45 -0700
Subject: drm/vmwgfx: Avoid validating views on view destruction
From: Thomas Hellstrom <thellstrom@vmware.com>
commit a19440304db2d97aed5cee9bfa5017c98d2348bf upstream.
When a view destruction command was present in the command stream, the
view was validated to avoid a device error. That caused excessive and
unnecessary validations of views, surfaces and mobs on view destruction.
Replace this with a new relocation type that patches the view
destruction command to a NOP if the view is not present in the device
after the execbuf validation sequence.
Also add checks for the member size of the vmw_res_relocation struct.
Fixes sporadic command submission errors on google-earth exit.
Reported-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 70 ++++++++++++++++++++++++++------
1 file changed, 57 insertions(+), 13 deletions(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -34,6 +34,24 @@
#define VMW_RES_HT_ORDER 12
+ /**
+ * enum vmw_resource_relocation_type - Relocation type for resources
+ *
+ * @vmw_res_rel_normal: Traditional relocation. The resource id in the
+ * command stream is replaced with the actual id after validation.
+ * @vmw_res_rel_nop: NOP relocation. The command is unconditionally replaced
+ * with a NOP.
+ * @vmw_res_rel_cond_nop: Conditional NOP relocation. If the resource id
+ * after validation is -1, the command is replaced with a NOP. Otherwise no
+ * action.
+ */
+enum vmw_resource_relocation_type {
+ vmw_res_rel_normal,
+ vmw_res_rel_nop,
+ vmw_res_rel_cond_nop,
+ vmw_res_rel_max
+};
+
/**
* struct vmw_resource_relocation - Relocation info for resources
*
@@ -41,11 +59,13 @@
* @res: Non-ref-counted pointer to the resource.
* @offset: Offset of 4 byte entries into the command buffer where the
* id that needs fixup is located.
+ * @rel_type: Type of relocation.
*/
struct vmw_resource_relocation {
struct list_head head;
const struct vmw_resource *res;
- unsigned long offset;
+ u32 offset:29;
+ enum vmw_resource_relocation_type rel_type:3;
};
/**
@@ -410,10 +430,13 @@ static int vmw_resource_context_res_add(
* @res: The resource.
* @offset: Offset into the command buffer currently being parsed where the
* id that needs fixup is located. Granularity is 4 bytes.
+ * @rel_type: Relocation type.
*/
static int vmw_resource_relocation_add(struct list_head *list,
const struct vmw_resource *res,
- unsigned long offset)
+ unsigned long offset,
+ enum vmw_resource_relocation_type
+ rel_type)
{
struct vmw_resource_relocation *rel;
@@ -425,6 +448,7 @@ static int vmw_resource_relocation_add(s
rel->res = res;
rel->offset = offset;
+ rel->rel_type = rel_type;
list_add_tail(&rel->head, list);
return 0;
@@ -459,11 +483,23 @@ static void vmw_resource_relocations_app
{
struct vmw_resource_relocation *rel;
+ /* Validate the struct vmw_resource_relocation member size */
+ BUILD_BUG_ON(SVGA_CB_MAX_SIZE >= (1 << 29));
+ BUILD_BUG_ON(vmw_res_rel_max >= (1 << 3));
+
list_for_each_entry(rel, list, head) {
- if (likely(rel->res != NULL))
+ switch (rel->rel_type) {
+ case vmw_res_rel_normal:
cb[rel->offset] = rel->res->id;
- else
+ break;
+ case vmw_res_rel_nop:
cb[rel->offset] = SVGA_3D_CMD_NOP;
+ break;
+ default:
+ if (rel->res->id == -1)
+ cb[rel->offset] = SVGA_3D_CMD_NOP;
+ break;
+ }
}
}
@@ -655,7 +691,8 @@ static int vmw_cmd_res_reloc_add(struct
*p_val = NULL;
ret = vmw_resource_relocation_add(&sw_context->res_relocations,
res,
- id_loc - sw_context->buf_start);
+ id_loc - sw_context->buf_start,
+ vmw_res_rel_normal);
if (unlikely(ret != 0))
return ret;
@@ -721,7 +758,8 @@ vmw_cmd_res_check(struct vmw_private *de
return vmw_resource_relocation_add
(&sw_context->res_relocations, res,
- id_loc - sw_context->buf_start);
+ id_loc - sw_context->buf_start,
+ vmw_res_rel_normal);
}
ret = vmw_user_resource_lookup_handle(dev_priv,
@@ -2144,7 +2182,8 @@ static int vmw_cmd_shader_define(struct
return vmw_resource_relocation_add(&sw_context->res_relocations,
NULL, &cmd->header.id -
- sw_context->buf_start);
+ sw_context->buf_start,
+ vmw_res_rel_nop);
return 0;
}
@@ -2189,7 +2228,8 @@ static int vmw_cmd_shader_destroy(struct
return vmw_resource_relocation_add(&sw_context->res_relocations,
NULL, &cmd->header.id -
- sw_context->buf_start);
+ sw_context->buf_start,
+ vmw_res_rel_nop);
return 0;
}
@@ -2848,8 +2888,7 @@ static int vmw_cmd_dx_cid_check(struct v
* @header: Pointer to the command header in the command stream.
*
* Check that the view exists, and if it was not created using this
- * command batch, make sure it's validated (present in the device) so that
- * the remove command will not confuse the device.
+ * command batch, conditionally make this command a NOP.
*/
static int vmw_cmd_dx_view_remove(struct vmw_private *dev_priv,
struct vmw_sw_context *sw_context,
@@ -2877,10 +2916,15 @@ static int vmw_cmd_dx_view_remove(struct
return ret;
/*
- * Add view to the validate list iff it was not created using this
- * command batch.
+ * If the view wasn't created during this command batch, it might
+ * have been removed due to a context swapout, so add a
+ * relocation to conditionally make this command a NOP to avoid
+ * device errors.
*/
- return vmw_view_res_val_add(sw_context, view);
+ return vmw_resource_relocation_add(&sw_context->res_relocations,
+ view,
+ &cmd->header.id - sw_context->buf_start,
+ vmw_res_rel_cond_nop);
}
/**
Patches currently in stable-queue which might be from thellstrom@vmware.com are
queue-4.8/drm-vmwgfx-limit-the-user-space-command-buffer-size.patch
queue-4.8/drm-vmwgfx-avoid-validating-views-on-view-destruction.patch
reply other threads:[~2016-10-29 13:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=14777472068160@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=brianp@vmware.com \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=syeh@vmware.com \
--cc=thellstrom@vmware.com \
/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).