From: Greg Kroah-Hartman Date: Mon, 6 Oct 2014 00:04:53 +0000 (-0700) Subject: 3.14-stable patches X-Git-Tag: v3.10.57~28 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=986a257d7ddc4f61c12e99f835ef6a512b46614d;p=thirdparty%2Fkernel%2Fstable-queue.git 3.14-stable patches added patches: cpufreq-integrator-fix-integrator_cpufreq_remove-return-type.patch drm-i915-flush-the-ptes-after-updating-them-before-suspend.patch fix-problem-recognizing-symlinks.patch init-kconfig-fix-have_futex_cmpxchg-to-not-break-up-the-expert-menu.patch md-raid5-disable-discard-by-default-due-to-safety-concerns.patch mm-migrate-close-race-between-migration-completion-and-mprotect.patch perf-fix-perf-bug-in-fork.patch ring-buffer-fix-infinite-spin-in-reading-buffer.patch --- diff --git a/queue-3.14/cpufreq-integrator-fix-integrator_cpufreq_remove-return-type.patch b/queue-3.14/cpufreq-integrator-fix-integrator_cpufreq_remove-return-type.patch new file mode 100644 index 00000000000..dfef28e5c59 --- /dev/null +++ b/queue-3.14/cpufreq-integrator-fix-integrator_cpufreq_remove-return-type.patch @@ -0,0 +1,41 @@ +From d62dbf77f7dfaa6fb455b4b9828069a11965929c Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Fri, 26 Sep 2014 22:19:12 +0200 +Subject: cpufreq: integrator: fix integrator_cpufreq_remove return type + +From: Arnd Bergmann + +commit d62dbf77f7dfaa6fb455b4b9828069a11965929c upstream. + +When building this driver as a module, we get a helpful warning +about the return type: + +drivers/cpufreq/integrator-cpufreq.c:232:2: warning: initialization from incompatible pointer type + .remove = __exit_p(integrator_cpufreq_remove), + +If the remove callback returns void, the caller gets an undefined +value as it expects an integer to be returned. This fixes the +problem by passing down the value from cpufreq_unregister_driver. + +Signed-off-by: Arnd Bergmann +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/cpufreq/integrator-cpufreq.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/cpufreq/integrator-cpufreq.c ++++ b/drivers/cpufreq/integrator-cpufreq.c +@@ -213,9 +213,9 @@ static int __init integrator_cpufreq_pro + return cpufreq_register_driver(&integrator_driver); + } + +-static void __exit integrator_cpufreq_remove(struct platform_device *pdev) ++static int __exit integrator_cpufreq_remove(struct platform_device *pdev) + { +- cpufreq_unregister_driver(&integrator_driver); ++ return cpufreq_unregister_driver(&integrator_driver); + } + + static const struct of_device_id integrator_cpufreq_match[] = { diff --git a/queue-3.14/drm-i915-flush-the-ptes-after-updating-them-before-suspend.patch b/queue-3.14/drm-i915-flush-the-ptes-after-updating-them-before-suspend.patch new file mode 100644 index 00000000000..61c94a8df3c --- /dev/null +++ b/queue-3.14/drm-i915-flush-the-ptes-after-updating-them-before-suspend.patch @@ -0,0 +1,84 @@ +From 91e56499304f3d612053a9cf17f350868182c7d8 Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Thu, 25 Sep 2014 10:13:12 +0100 +Subject: drm/i915: Flush the PTEs after updating them before suspend + +From: Chris Wilson + +commit 91e56499304f3d612053a9cf17f350868182c7d8 upstream. + +As we use WC updates of the PTE, we are responsible for notifying the +hardware when to flush its TLBs. Do so after we zap all the PTEs before +suspend (and the BIOS tries to read our GTT). + +Fixes a regression from + +commit 828c79087cec61eaf4c76bb32c222fbe35ac3930 +Author: Ben Widawsky +Date: Wed Oct 16 09:21:30 2013 -0700 + + drm/i915: Disable GGTT PTEs on GEN6+ suspend + +that survived and continue to cause harm even after + +commit e568af1c626031925465a5caaab7cca1303d55c7 +Author: Daniel Vetter +Date: Wed Mar 26 20:08:20 2014 +0100 + + drm/i915: Undo gtt scratch pte unmapping again + +v2: Trivial rebase. +v3: Fixes requires pointer dances. + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340 +Tested-by: ming.yao@intel.com +Signed-off-by: Chris Wilson +Cc: Takashi Iwai +Cc: Paulo Zanoni +Cc: Todd Previte +Cc: Daniel Vetter +Reviewed-by: Daniel Vetter +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++++++++++++- + 1 file changed, 13 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/i915_gem_gtt.c ++++ b/drivers/gpu/drm/i915/i915_gem_gtt.c +@@ -827,6 +827,16 @@ void i915_check_and_clear_faults(struct + POSTING_READ(RING_FAULT_REG(&dev_priv->ring[RCS])); + } + ++static void i915_ggtt_flush(struct drm_i915_private *dev_priv) ++{ ++ if (INTEL_INFO(dev_priv->dev)->gen < 6) { ++ intel_gtt_chipset_flush(); ++ } else { ++ I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN); ++ POSTING_READ(GFX_FLSH_CNTL_GEN6); ++ } ++} ++ + void i915_gem_suspend_gtt_mappings(struct drm_device *dev) + { + struct drm_i915_private *dev_priv = dev->dev_private; +@@ -843,6 +853,8 @@ void i915_gem_suspend_gtt_mappings(struc + dev_priv->gtt.base.start / PAGE_SIZE, + dev_priv->gtt.base.total / PAGE_SIZE, + true); ++ ++ i915_ggtt_flush(dev_priv); + } + + void i915_gem_restore_gtt_mappings(struct drm_device *dev) +@@ -863,7 +875,7 @@ void i915_gem_restore_gtt_mappings(struc + i915_gem_gtt_bind_object(obj, obj->cache_level); + } + +- i915_gem_chipset_flush(dev); ++ i915_ggtt_flush(dev_priv); + } + + int i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj) diff --git a/queue-3.14/fix-problem-recognizing-symlinks.patch b/queue-3.14/fix-problem-recognizing-symlinks.patch new file mode 100644 index 00000000000..b9dbe92a5d8 --- /dev/null +++ b/queue-3.14/fix-problem-recognizing-symlinks.patch @@ -0,0 +1,49 @@ +From 19e81573fca7b87ced7701e01ba164b968d929bd Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Thu, 25 Sep 2014 01:26:55 -0500 +Subject: Fix problem recognizing symlinks + +From: Steve French + +commit 19e81573fca7b87ced7701e01ba164b968d929bd upstream. + +Changeset eb85d94bd introduced a problem where if a cifs open +fails during query info of a file we +will still try to close the file (happens with certain types +of reparse points) even though the file handle is not valid. + +In addition for SMB2/SMB3 we were not mapping the return code returned +by Windows when trying to open a file (like a Windows NFS symlink) +which is a reparse point. + +Signed-off-by: Steve French +Reviewed-by: Pavel Shilovsky +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/smb1ops.c | 2 +- + fs/cifs/smb2maperror.c | 2 ++ + 2 files changed, 3 insertions(+), 1 deletion(-) + +--- a/fs/cifs/smb1ops.c ++++ b/fs/cifs/smb1ops.c +@@ -586,7 +586,7 @@ cifs_query_path_info(const unsigned int + tmprc = CIFS_open(xid, &oparms, &oplock, NULL); + if (tmprc == -EOPNOTSUPP) + *symlink = true; +- else ++ else if (tmprc == 0) + CIFSSMBClose(xid, tcon, fid.netfid); + } + +--- a/fs/cifs/smb2maperror.c ++++ b/fs/cifs/smb2maperror.c +@@ -256,6 +256,8 @@ static const struct status_to_posix_erro + {STATUS_DLL_MIGHT_BE_INCOMPATIBLE, -EIO, + "STATUS_DLL_MIGHT_BE_INCOMPATIBLE"}, + {STATUS_STOPPED_ON_SYMLINK, -EOPNOTSUPP, "STATUS_STOPPED_ON_SYMLINK"}, ++ {STATUS_IO_REPARSE_TAG_NOT_HANDLED, -EOPNOTSUPP, ++ "STATUS_REPARSE_NOT_HANDLED"}, + {STATUS_DEVICE_REQUIRES_CLEANING, -EIO, + "STATUS_DEVICE_REQUIRES_CLEANING"}, + {STATUS_DEVICE_DOOR_OPEN, -EIO, "STATUS_DEVICE_DOOR_OPEN"}, diff --git a/queue-3.14/init-kconfig-fix-have_futex_cmpxchg-to-not-break-up-the-expert-menu.patch b/queue-3.14/init-kconfig-fix-have_futex_cmpxchg-to-not-break-up-the-expert-menu.patch new file mode 100644 index 00000000000..fa456ab5100 --- /dev/null +++ b/queue-3.14/init-kconfig-fix-have_futex_cmpxchg-to-not-break-up-the-expert-menu.patch @@ -0,0 +1,41 @@ +From 62b4d2041117f35ab2409c9f5c4b8d3dc8e59d0f Mon Sep 17 00:00:00 2001 +From: Josh Triplett +Date: Fri, 3 Oct 2014 16:19:24 -0700 +Subject: init/Kconfig: Fix HAVE_FUTEX_CMPXCHG to not break up the EXPERT menu + +From: Josh Triplett + +commit 62b4d2041117f35ab2409c9f5c4b8d3dc8e59d0f upstream. + +commit 03b8c7b623c80af264c4c8d6111e5c6289933666 ("futex: Allow +architectures to skip futex_atomic_cmpxchg_inatomic() test") added the +HAVE_FUTEX_CMPXCHG symbol right below FUTEX. This placed it right in +the middle of the options for the EXPERT menu. However, +HAVE_FUTEX_CMPXCHG does not depend on EXPERT or FUTEX, so Kconfig stops +placing items in the EXPERT menu, and displays the remaining several +EXPERT items (starting with EPOLL) directly in the General Setup menu. + +Since both users of HAVE_FUTEX_CMPXCHG only select it "if FUTEX", make +HAVE_FUTEX_CMPXCHG itself depend on FUTEX. With this change, the +subsequent items display as part of the EXPERT menu again; the EMBEDDED +menu now appears as the next top-level item in the General Setup menu, +which makes General Setup much shorter and more usable. + +Signed-off-by: Josh Triplett +Acked-by: Randy Dunlap +Signed-off-by: Greg Kroah-Hartman + +--- + init/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +--- a/init/Kconfig ++++ b/init/Kconfig +@@ -1389,6 +1389,7 @@ config FUTEX + + config HAVE_FUTEX_CMPXCHG + bool ++ depends on FUTEX + help + Architectures should select this if futex_atomic_cmpxchg_inatomic() + is implemented and always working. This removes a couple of runtime diff --git a/queue-3.14/md-raid5-disable-discard-by-default-due-to-safety-concerns.patch b/queue-3.14/md-raid5-disable-discard-by-default-due-to-safety-concerns.patch new file mode 100644 index 00000000000..992e4f02b97 --- /dev/null +++ b/queue-3.14/md-raid5-disable-discard-by-default-due-to-safety-concerns.patch @@ -0,0 +1,92 @@ +From 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Thu, 2 Oct 2014 13:45:00 +1000 +Subject: md/raid5: disable 'DISCARD' by default due to safety concerns. + +From: NeilBrown + +commit 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93 upstream. + +It has come to my attention (thanks Martin) that 'discard_zeroes_data' +is only a hint. Some devices in some cases don't do what it +says on the label. + +The use of DISCARD in RAID5 depends on reads from discarded regions +being predictably zero. If a write to a previously discarded region +performs a read-modify-write cycle it assumes that the parity block +was consistent with the data blocks. If all were zero, this would +be the case. If some are and some aren't this would not be the case. +This could lead to data corruption after a device failure when +data needs to be reconstructed from the parity. + +As we cannot trust 'discard_zeroes_data', ignore it by default +and so disallow DISCARD on all raid4/5/6 arrays. + +As many devices are trustworthy, and as there are benefits to using +DISCARD, add a module parameter to over-ride this caution and cause +DISCARD to work if discard_zeroes_data is set. + +If a site want to enable DISCARD on some arrays but not on others they +should select DISCARD support at the filesystem level, and set the +raid456 module parameter. + raid456.devices_handle_discard_safely=Y + +As this is a data-safety issue, I believe this patch is suitable for +-stable. +DISCARD support for RAID456 was added in 3.7 + +Cc: Shaohua Li +Cc: "Martin K. Petersen" +Cc: Mike Snitzer +Cc: Heinz Mauelshagen +Acked-by: Martin K. Petersen +Acked-by: Mike Snitzer +Fixes: 620125f2bf8ff0c4969b79653b54d7bcc9d40637 +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid5.c | 18 +++++++++++++++++- + 1 file changed, 17 insertions(+), 1 deletion(-) + +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -64,6 +64,10 @@ + #define cpu_to_group(cpu) cpu_to_node(cpu) + #define ANY_GROUP NUMA_NO_NODE + ++static bool devices_handle_discard_safely = false; ++module_param(devices_handle_discard_safely, bool, 0644); ++MODULE_PARM_DESC(devices_handle_discard_safely, ++ "Set to Y if all devices in each array reliably return zeroes on reads from discarded regions"); + static struct workqueue_struct *raid5_wq; + /* + * Stripe cache +@@ -6117,7 +6121,7 @@ static int run(struct mddev *mddev) + mddev->queue->limits.discard_granularity = stripe; + /* + * unaligned part of discard request will be ignored, so can't +- * guarantee discard_zerors_data ++ * guarantee discard_zeroes_data + */ + mddev->queue->limits.discard_zeroes_data = 0; + +@@ -6142,6 +6146,18 @@ static int run(struct mddev *mddev) + !bdev_get_queue(rdev->bdev)-> + limits.discard_zeroes_data) + discard_supported = false; ++ /* Unfortunately, discard_zeroes_data is not currently ++ * a guarantee - just a hint. So we only allow DISCARD ++ * if the sysadmin has confirmed that only safe devices ++ * are in use by setting a module parameter. ++ */ ++ if (!devices_handle_discard_safely) { ++ if (discard_supported) { ++ pr_info("md/raid456: discard support disabled due to uncertainty.\n"); ++ pr_info("Set raid456.devices_handle_discard_safely=Y to override.\n"); ++ } ++ discard_supported = false; ++ } + } + + if (discard_supported && diff --git a/queue-3.14/mm-migrate-close-race-between-migration-completion-and-mprotect.patch b/queue-3.14/mm-migrate-close-race-between-migration-completion-and-mprotect.patch new file mode 100644 index 00000000000..edb246a6889 --- /dev/null +++ b/queue-3.14/mm-migrate-close-race-between-migration-completion-and-mprotect.patch @@ -0,0 +1,44 @@ +From d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 Mon Sep 17 00:00:00 2001 +From: Mel Gorman +Date: Thu, 2 Oct 2014 19:47:41 +0100 +Subject: mm: migrate: Close race between migration completion and mprotect + +From: Mel Gorman + +commit d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 upstream. + +A migration entry is marked as write if pte_write was true at the time the +entry was created. The VMA protections are not double checked when migration +entries are being removed as mprotect marks write-migration-entries as +read. It means that potentially we take a spurious fault to mark PTEs write +again but it's straight-forward. However, there is a race between write +migrations being marked read and migrations finishing. This potentially +allows a PTE to be write that should have been read. Close this race by +double checking the VMA permissions using maybe_mkwrite when migration +completes. + +[torvalds@linux-foundation.org: use maybe_mkwrite] +Signed-off-by: Mel Gorman +Acked-by: Rik van Riel +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/migrate.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/mm/migrate.c ++++ b/mm/migrate.c +@@ -148,8 +148,11 @@ static int remove_migration_pte(struct p + pte = pte_mkold(mk_pte(new, vma->vm_page_prot)); + if (pte_swp_soft_dirty(*ptep)) + pte = pte_mksoft_dirty(pte); ++ ++ /* Recheck VMA as permissions can change since migration started */ + if (is_write_migration_entry(entry)) +- pte = pte_mkwrite(pte); ++ pte = maybe_mkwrite(pte, vma); ++ + #ifdef CONFIG_HUGETLB_PAGE + if (PageHuge(new)) { + pte = pte_mkhuge(pte); diff --git a/queue-3.14/perf-fix-perf-bug-in-fork.patch b/queue-3.14/perf-fix-perf-bug-in-fork.patch new file mode 100644 index 00000000000..f18a3ee80bc --- /dev/null +++ b/queue-3.14/perf-fix-perf-bug-in-fork.patch @@ -0,0 +1,65 @@ +From 6c72e3501d0d62fc064d3680e5234f3463ec5a86 Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Thu, 2 Oct 2014 16:17:02 -0700 +Subject: perf: fix perf bug in fork() + +From: Peter Zijlstra + +commit 6c72e3501d0d62fc064d3680e5234f3463ec5a86 upstream. + +Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by +calling perf_event_free_task() when failing sched_fork() we will not yet +have done the memset() on ->perf_event_ctxp[] and will therefore try and +'free' the inherited contexts, which are still in use by the parent +process. This is bad.. + +Suggested-by: Oleg Nesterov +Reported-by: Oleg Nesterov +Reported-by: Sylvain 'ythier' Hitier +Signed-off-by: Peter Zijlstra (Intel) +Cc: Ingo Molnar +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/events/core.c | 4 +++- + kernel/fork.c | 5 +++-- + 2 files changed, 6 insertions(+), 3 deletions(-) + +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -7836,8 +7836,10 @@ int perf_event_init_task(struct task_str + + for_each_task_context_nr(ctxn) { + ret = perf_event_init_context(child, ctxn); +- if (ret) ++ if (ret) { ++ perf_event_free_task(child); + return ret; ++ } + } + + return 0; +--- a/kernel/fork.c ++++ b/kernel/fork.c +@@ -1323,7 +1323,7 @@ static struct task_struct *copy_process( + goto bad_fork_cleanup_policy; + retval = audit_alloc(p); + if (retval) +- goto bad_fork_cleanup_policy; ++ goto bad_fork_cleanup_perf; + /* copy all the process information */ + retval = copy_semundo(clone_flags, p); + if (retval) +@@ -1522,8 +1522,9 @@ bad_fork_cleanup_semundo: + exit_sem(p); + bad_fork_cleanup_audit: + audit_free(p); +-bad_fork_cleanup_policy: ++bad_fork_cleanup_perf: + perf_event_free_task(p); ++bad_fork_cleanup_policy: + #ifdef CONFIG_NUMA + mpol_put(p->mempolicy); + bad_fork_cleanup_cgroup: diff --git a/queue-3.14/ring-buffer-fix-infinite-spin-in-reading-buffer.patch b/queue-3.14/ring-buffer-fix-infinite-spin-in-reading-buffer.patch new file mode 100644 index 00000000000..af449cdfd9d --- /dev/null +++ b/queue-3.14/ring-buffer-fix-infinite-spin-in-reading-buffer.patch @@ -0,0 +1,55 @@ +From 24607f114fd14f2f37e3e0cb3d47bce96e81e848 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Red Hat)" +Date: Thu, 2 Oct 2014 16:51:18 -0400 +Subject: ring-buffer: Fix infinite spin in reading buffer + +From: "Steven Rostedt (Red Hat)" + +commit 24607f114fd14f2f37e3e0cb3d47bce96e81e848 upstream. + +Commit 651e22f2701b "ring-buffer: Always reset iterator to reader page" +fixed one bug but in the process caused another one. The reset is to +update the header page, but that fix also changed the way the cached +reads were updated. The cache reads are used to test if an iterator +needs to be updated or not. + +A ring buffer iterator, when created, disables writes to the ring buffer +but does not stop other readers or consuming reads from happening. +Although all readers are synchronized via a lock, they are only +synchronized when in the ring buffer functions. Those functions may +be called by any number of readers. The iterator continues down when +its not interrupted by a consuming reader. If a consuming read +occurs, the iterator starts from the beginning of the buffer. + +The way the iterator sees that a consuming read has happened since +its last read is by checking the reader "cache". The cache holds the +last counts of the read and the reader page itself. + +Commit 651e22f2701b changed what was saved by the cache_read when +the rb_iter_reset() occurred, making the iterator never match the cache. +Then if the iterator calls rb_iter_reset(), it will go into an +infinite loop by checking if the cache doesn't match, doing the reset +and retrying, just to see that the cache still doesn't match! Which +should never happen as the reset is suppose to set the cache to the +current value and there's locks that keep a consuming reader from +having access to the data. + +Fixes: 651e22f2701b "ring-buffer: Always reset iterator to reader page" +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/ring_buffer.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/trace/ring_buffer.c ++++ b/kernel/trace/ring_buffer.c +@@ -3372,7 +3372,7 @@ static void rb_iter_reset(struct ring_bu + iter->head = cpu_buffer->reader_page->read; + + iter->cache_reader_page = iter->head_page; +- iter->cache_read = iter->head; ++ iter->cache_read = cpu_buffer->read; + + if (iter->head) + iter->read_stamp = cpu_buffer->read_stamp; diff --git a/queue-3.14/series b/queue-3.14/series index 88b44efd92d..6eeaaf503d7 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -1 +1,9 @@ udf-avoid-infinite-loop-when-processing-indirect-icbs.patch +perf-fix-perf-bug-in-fork.patch +mm-migrate-close-race-between-migration-completion-and-mprotect.patch +cpufreq-integrator-fix-integrator_cpufreq_remove-return-type.patch +md-raid5-disable-discard-by-default-due-to-safety-concerns.patch +drm-i915-flush-the-ptes-after-updating-them-before-suspend.patch +fix-problem-recognizing-symlinks.patch +init-kconfig-fix-have_futex_cmpxchg-to-not-break-up-the-expert-menu.patch +ring-buffer-fix-infinite-spin-in-reading-buffer.patch