From: Greg Kroah-Hartman Date: Fri, 1 Feb 2013 12:51:50 +0000 (+0100) Subject: 3.7-stable patches X-Git-Tag: v3.0.62~2 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=dead61ec5305d9c2aa485da37012aea4762d41d7;p=thirdparty%2Fkernel%2Fstable-queue.git 3.7-stable patches added patches: drm-i915-fix-forcewake-posting-reads.patch slub-assign-refcount-for-kmalloc_caches.patch --- diff --git a/queue-3.7/drm-i915-fix-forcewake-posting-reads.patch b/queue-3.7/drm-i915-fix-forcewake-posting-reads.patch new file mode 100644 index 00000000000..72ec3dc35e5 --- /dev/null +++ b/queue-3.7/drm-i915-fix-forcewake-posting-reads.patch @@ -0,0 +1,107 @@ +From b514407547890686572606c9dfa4b7f832db9958 Mon Sep 17 00:00:00 2001 +From: Jani Nikula +Date: Thu, 17 Jan 2013 10:24:09 +0200 +Subject: drm/i915: fix FORCEWAKE posting reads + +From: Jani Nikula + +commit b514407547890686572606c9dfa4b7f832db9958 upstream. + +We stopped reading FORCEWAKE for posting reads in + +commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd +Author: Ben Widawsky +Date: Sat Sep 1 22:59:50 2012 -0700 + + drm/i915: Never read FORCEWAKE + +and started using something from the same cacheline instead. On the +bug reporter's machine this broke entering rc6 states after a +suspend/resume cycle. It turns out reading ECOBUS as posting read +worked fine, while GTFIFODBG did not, preventing RC6 states after +suspend/resume per the bug report referenced below. It's not entirely +clear why, but clearly GTFIFODBG was nowhere near the same cacheline +or address range as FORCEWAKE. + +Trying out various registers for posting reads showed that all tested +registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true +work. Conversely, most (but not quite all) registers for which +NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced +bug. + +Based on the above, add posting reads on ECOBUS where GTFIFODBG was +previously relied on. + +In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as +well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same +address range as FORCEWAKE_VLV. + +v2: Add more details to the commit message. No functional changes. + +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411 +Reported-and-tested-by: Alexander Bersenev +CC: Ben Widawsky +Signed-off-by: Jani Nikula +Reviewed-by: Chris Wilson +Cc: stable@vger.kernel.org +[danvet: add cc: stable and make the commit message a bit clearer that +this is a regression fix and what exactly broke.] +Signed-off-by: Daniel Vetter +Signed-off-by: CAI Qian +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_pm.c | 15 ++++++++++----- + 1 file changed, 10 insertions(+), 5 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -4018,7 +4018,8 @@ static void __gen6_gt_force_wake_get(str + DRM_ERROR("Timed out waiting for forcewake old ack to clear.\n"); + + I915_WRITE_NOTRACE(FORCEWAKE, 1); +- POSTING_READ(ECOBUS); /* something from same cacheline, but !FORCEWAKE */ ++ /* something from same cacheline, but !FORCEWAKE */ ++ POSTING_READ(ECOBUS); + + if (wait_for_atomic((I915_READ_NOTRACE(forcewake_ack) & 1), + FORCEWAKE_ACK_TIMEOUT_MS)) +@@ -4041,7 +4042,8 @@ static void __gen6_gt_force_wake_mt_get( + DRM_ERROR("Timed out waiting for forcewake old ack to clear.\n"); + + I915_WRITE_NOTRACE(FORCEWAKE_MT, _MASKED_BIT_ENABLE(1)); +- POSTING_READ(ECOBUS); /* something from same cacheline, but !FORCEWAKE */ ++ /* something from same cacheline, but !FORCEWAKE */ ++ POSTING_READ(ECOBUS); + + if (wait_for_atomic((I915_READ_NOTRACE(forcewake_ack) & 1), + FORCEWAKE_ACK_TIMEOUT_MS)) +@@ -4078,14 +4080,16 @@ void gen6_gt_check_fifodbg(struct drm_i9 + static void __gen6_gt_force_wake_put(struct drm_i915_private *dev_priv) + { + I915_WRITE_NOTRACE(FORCEWAKE, 0); +- /* gen6_gt_check_fifodbg doubles as the POSTING_READ */ ++ /* something from same cacheline, but !FORCEWAKE */ ++ POSTING_READ(ECOBUS); + gen6_gt_check_fifodbg(dev_priv); + } + + static void __gen6_gt_force_wake_mt_put(struct drm_i915_private *dev_priv) + { + I915_WRITE_NOTRACE(FORCEWAKE_MT, _MASKED_BIT_DISABLE(1)); +- /* gen6_gt_check_fifodbg doubles as the POSTING_READ */ ++ /* something from same cacheline, but !FORCEWAKE_MT */ ++ POSTING_READ(ECOBUS); + gen6_gt_check_fifodbg(dev_priv); + } + +@@ -4140,7 +4144,8 @@ static void vlv_force_wake_get(struct dr + static void vlv_force_wake_put(struct drm_i915_private *dev_priv) + { + I915_WRITE_NOTRACE(FORCEWAKE_VLV, _MASKED_BIT_DISABLE(1)); +- /* The below doubles as a POSTING_READ */ ++ /* something from same cacheline, but !FORCEWAKE_VLV */ ++ POSTING_READ(FORCEWAKE_ACK_VLV); + gen6_gt_check_fifodbg(dev_priv); + } + diff --git a/queue-3.7/series b/queue-3.7/series index cf3f72edde9..2a737b3bcb7 100644 --- a/queue-3.7/series +++ b/queue-3.7/series @@ -85,3 +85,5 @@ netfilter-xt_recent-avoid-high-order-page-allocations.patch netfilter-nf_conntrack-fix-bug_on-while-removing-nf_conntrack-with-netns.patch netfilter-x_tables-print-correct-hook-names-for-arp.patch netfilter-ctnetlink-fix-leak-in-error-path-of-ctnetlink_create_expect.patch +drm-i915-fix-forcewake-posting-reads.patch +slub-assign-refcount-for-kmalloc_caches.patch diff --git a/queue-3.7/slub-assign-refcount-for-kmalloc_caches.patch b/queue-3.7/slub-assign-refcount-for-kmalloc_caches.patch new file mode 100644 index 00000000000..c7d4bcf8cc2 --- /dev/null +++ b/queue-3.7/slub-assign-refcount-for-kmalloc_caches.patch @@ -0,0 +1,52 @@ +From caiqian@redhat.com Fri Feb 1 13:47:04 2013 +From: CAI Qian +Date: Thu, 24 Jan 2013 22:50:09 -0500 (EST) +Subject: slub: assign refcount for kmalloc_caches +To: stable@vger.kernel.org +Cc: Christoph Lameter , Joonsoo Kim , Paul Hargrove +Message-ID: <2142250133.9176397.1359085809116.JavaMail.root@redhat.com> + +From: CAI Qian + +This is for stable-3.7.y only and this problem has already been solved +in mainline through some slab/slub re-work which isn't suitable to +backport here. See create_kmalloc_cache() in mm/slab_common.c there. + +commit cce89f4f6911286500cf7be0363f46c9b0a12ce0('Move kmem_cache +refcounting to common code') moves some refcount manipulation code to +common code. Unfortunately, it also removed refcount assignment for +kmalloc_caches. So, kmalloc_caches's refcount is initially 0. +This makes erroneous situation. + +Paul Hargrove report that when he create a 8-byte kmem_cache and +destory it, he encounter below message. +'Objects remaining in kmalloc-8 on kmem_cache_close()' + +8-byte kmem_cache merge with 8-byte kmalloc cache and refcount is +increased by one. So, resulting refcount is 1. When destroy it, it hit +refcount = 0, then kmem_cache_close() is executed and error message is +printed. + +This patch assign initial refcount 1 to kmalloc_caches, so fix this +erroneous situation. + +Reported-by: Paul Hargrove +Cc: Christoph Lameter +Signed-off-by: Joonsoo Kim +Signed-off-by: CAI Qian +Signed-off-by: Greg Kroah-Hartman + +--- + mm/slub.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/mm/slub.c ++++ b/mm/slub.c +@@ -3279,6 +3279,7 @@ static struct kmem_cache *__init create_ + if (kmem_cache_open(s, flags)) + goto panic; + ++ s->refcount = 1; + list_add(&s->list, &slab_caches); + return s; +