rpms
/
kernel
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Linux v3.10.5

This commit is contained in:
Justin M. Forbes 2013-08-05 09:30:05 -05:00
parent 1ff229fcea
commit 9a45702091
4 changed files with 5 additions and 180 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

113
drm-i915-correctly-restore-fences-with-objects-attac.patch
View File

@ -1,113 +0,0 @@
From 94a335dba34ff47cad3d6d0c29b452d43a1be3c8 Mon Sep 17 00:00:00 2001
From: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed, 17 Jul 2013 14:51:28 +0200
Subject: [PATCH] drm/i915: correctly restore fences with objects attached
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
To avoid stalls we delay tiling changes and especially hold of
committing the new fence state for as long as possible.
Synchronization points are in the execbuf code and in our gtt fault
handler.
Unfortunately we've missed that tricky detail when adding proper fence
restore code in
commit 19b2dbde5732170a03bd82cc8bd442cf88d856f7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jun 12 10:15:12 2013 +0100
drm/i915: Restore fences after resume and GPU resets
The result was that we've restored fences for objects with no tiling,
since the object<->fence link still existed after resume. Now that
wouldn't have been too bad since any subsequent access would have
fixed things up, but if we've changed from tiled to untiled real havoc
happened:
The tiling stride is stored -1 in the fence register, so a stride of 0
resulted in all 1s in the top 32bits, and so a completely bogus fence
spanning everything from the start of the object to the top of the
GTT. The tell-tale in the register dumps looks like:
FENCE START 2: 0x0214d001
FENCE END 2: 0xfffff3ff
Bit 11 isn't set since the hw doesn't store it, even when writing all
1s (at least on my snb here).
To prevent such a gaffle in the future add a sanity check for fences
with an untiled object attached in i915_gem_write_fence.
v2: Fix the WARN, spotted by Chris.
v3: Trying to reuse get_fences looked ugly and obfuscated the code.
Instead reuse update_fence and to make it really dtrt also move the
fence dirty state clearing into update_fence.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60530
Cc: stable@vger.kernel.org (for 3.10 only)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Matthew Garrett <matthew.garrett@nebula.com>
Tested-by: Björn Bidar <theodorstormgrade@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/i915/i915_gem.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 97afd26..d9e2208 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2258,7 +2258,17 @@ void i915_gem_restore_fences(struct drm_device *dev)
for (i = 0; i < dev_priv->num_fence_regs; i++) {
struct drm_i915_fence_reg *reg = &dev_priv->fence_regs[i];
- i915_gem_write_fence(dev, i, reg->obj);
+
+ /*
+ * Commit delayed tiling changes if we have an object still
+ * attached to the fence, otherwise just clear the fence.
+ */
+ if (reg->obj) {
+ i915_gem_object_update_fence(reg->obj, reg,
+ reg->obj->tiling_mode);
+ } else {
+ i915_gem_write_fence(dev, i, NULL);
+ }
}
}
@@ -2795,6 +2805,10 @@ static void i915_gem_write_fence(struct drm_device *dev, int reg,
if (i915_gem_object_needs_mb(dev_priv->fence_regs[reg].obj))
mb();
+ WARN(obj && (!obj->stride || !obj->tiling_mode),
+ "bogus fence setup with stride: 0x%x, tiling mode: %i\n",
+ obj->stride, obj->tiling_mode);
+
switch (INTEL_INFO(dev)->gen) {
case 7:
case 6:
@@ -2836,6 +2850,7 @@ static void i915_gem_object_update_fence(struct drm_i915_gem_object *obj,
fence->obj = NULL;
list_del_init(&fence->lru_list);
}
+ obj->fence_dirty = false;
}
static int
@@ -2965,7 +2980,6 @@ i915_gem_object_get_fence(struct drm_i915_gem_object *obj)
return 0;
i915_gem_object_update_fence(obj, reg, enable);
- obj->fence_dirty = false;
return 0;
}
--
1.8.3.1

17
kernel.spec
View File

@ -74,7 +74,7 @@ Summary: The Linux kernel
%if 0%{?released_kernel}
# Do we have a -stable update to apply?
%define stable_update 4
%define stable_update 5
# Is it a -stable RC?
%define stable_rc 0
# Set rpm version accordingly
@ -737,9 +737,6 @@ Patch25007: fix-child-thread-introspection.patch
#rhbz 948262
Patch25024: intel_iommu-Downgrade-the-warning-if-enabling-irq-remapping-fails.patch
#CVE-2013-2140 rhbz 971146 971148
Patch25031: xen-blkback-Check-device-permissions-before-allowing.patch
#CVE-2013-2147 rhbz 971242 971249
Patch25032: cve-2013-2147-ciss-info-leak.patch
@ -778,9 +775,6 @@ Patch25069: iwlwifi-dvm-fix-calling-ieee80211_chswitch_done-with-NULL.patch
#rhbz 969473
Patch25070: Input-elantech-fix-for-newer-hardware-versions-v7.patch
#rhbz 989093
Patch25071: drm-i915-correctly-restore-fences-with-objects-attac.patch
#rhbz 977053
Patch25073: iwl4965-reset-firmware-after-rfkill-off.patch
@ -1461,9 +1455,6 @@ ApplyPatch fix-child-thread-introspection.patch
#rhbz 948262
ApplyPatch intel_iommu-Downgrade-the-warning-if-enabling-irq-remapping-fails.patch
#CVE-2013-2140 rhbz 971146 971148
ApplyPatch xen-blkback-Check-device-permissions-before-allowing.patch
#CVE-2013-2147 rhbz 971242 971249
ApplyPatch cve-2013-2147-ciss-info-leak.patch
@ -1502,9 +1493,6 @@ ApplyPatch iwlwifi-dvm-fix-calling-ieee80211_chswitch_done-with-NULL.patch
#rhbz 969473
ApplyPatch Input-elantech-fix-for-newer-hardware-versions-v7.patch
#rhbz 989093
ApplyPatch drm-i915-correctly-restore-fences-with-objects-attac.patch
#rhbz 977053
ApplyPatch iwl4965-reset-firmware-after-rfkill-off.patch
@ -2350,6 +2338,9 @@ fi
# ||----w |
# || ||
%changelog
* Mon Aug 04 2013 Justin M. Forbes <jforbes@redhat.com>
- Linux v3.10.5
* Thu Aug 1 2013 Peter Robinson <pbrobinson@fedoraproject.org> - 3.10.4-100
- Rebase ARM config

1
sources
View File

@ -1,2 +1,3 @@
4f25cd5bec5f8d5a7d935b3f2ccb8481 linux-3.10.tar.xz
2e46ab138670b3171b52b849568cb42f patch-3.10.4.xz
6366a8d4b0429ab6836c296ba298fb0e patch-3.10.5.xz

54
xen-blkback-Check-device-permissions-before-allowing.patch
View File

@ -1,54 +0,0 @@
From e029d62efa5eb46831a9e1414468e582379b743f Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk () oracle com>
Date: Wed, 16 Jan 2013 11:33:52 -0500
Subject: [PATCH] xen/blkback: Check device permissions before allowing
OP_DISCARD
We need to make sure that the device is not RO or that
the request is not past the number of sectors we want to
issue the DISCARD operation for.
Cc: stable () vger kernel org
Acked-by: Jan Beulich <JBeulich () suse com>
Acked-by: Ian Campbell <Ian.Campbell () citrix com>
[v1: Made it pr_warn instead of pr_debug]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk () oracle com>
---
drivers/block/xen-blkback/blkback.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index e79ab45..4119bcd 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -876,7 +876,18 @@ static int dispatch_discard_io(struct xen_blkif *blkif,
int status = BLKIF_RSP_OKAY;
struct block_device *bdev = blkif->vbd.bdev;
unsigned long secure;
+ struct phys_req preq;
+
+ preq.sector_number = req->u.discard.sector_number;
+ preq.nr_sects = req->u.discard.nr_sectors;
+ err = xen_vbd_translate(&preq, blkif, WRITE);
+ if (err) {
+ pr_warn(DRV_PFX "access denied: DISCARD [%llu->%llu] on dev=%04x\n",
+ preq.sector_number,
+ preq.sector_number + preq.nr_sects, blkif->vbd.pdevice);
+ goto fail_response;
+ }
blkif->st_ds_req++;
xen_blkif_get(blkif);
@@ -887,7 +898,7 @@ static int dispatch_discard_io(struct xen_blkif *blkif,
err = blkdev_issue_discard(bdev, req->u.discard.sector_number,
req->u.discard.nr_sectors,
GFP_KERNEL, secure);
-
+fail_response:
if (err == -EOPNOTSUPP) {
pr_debug(DRV_PFX "discard op failed, not supported\n");
status = BLKIF_RSP_EOPNOTSUPP;
--
1.8.1.4