--- /dev/null
+From d62dbf77f7dfaa6fb455b4b9828069a11965929c Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 26 Sep 2014 22:19:12 +0200
+Subject: cpufreq: integrator: fix integrator_cpufreq_remove return type
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+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 <arnd@arndb.de>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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[] = {
--- /dev/null
+From 91e56499304f3d612053a9cf17f350868182c7d8 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Thu, 25 Sep 2014 10:13:12 +0100
+Subject: drm/i915: Flush the PTEs after updating them before suspend
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+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 <benjamin.widawsky@intel.com>
+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 <daniel.vetter@ffwll.ch>
+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 <chris@chris-wilson.co.uk>
+Cc: Takashi Iwai <tiwai@suse.de>
+Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
+Cc: Todd Previte <tprevite@gmail.com>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 19e81573fca7b87ced7701e01ba164b968d929bd Mon Sep 17 00:00:00 2001
+From: Steve French <smfrench@gmail.com>
+Date: Thu, 25 Sep 2014 01:26:55 -0500
+Subject: Fix problem recognizing symlinks
+
+From: Steve French <smfrench@gmail.com>
+
+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 <smfrench@gmail.com>
+Reviewed-by: Pavel Shilovsky <pshilovsky@samba.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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"},
--- /dev/null
+From 62b4d2041117f35ab2409c9f5c4b8d3dc8e59d0f Mon Sep 17 00:00:00 2001
+From: Josh Triplett <josh@joshtriplett.org>
+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 <josh@joshtriplett.org>
+
+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 <josh@joshtriplett.org>
+Acked-by: Randy Dunlap <rdunlap@infradead.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From 8e0e99ba64c7ba46133a7c8a3e3f7de01f23bd93 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Thu, 2 Oct 2014 13:45:00 +1000
+Subject: md/raid5: disable 'DISCARD' by default due to safety concerns.
+
+From: NeilBrown <neilb@suse.de>
+
+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 <shli@kernel.org>
+Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
+Cc: Mike Snitzer <snitzer@redhat.com>
+Cc: Heinz Mauelshagen <heinzm@redhat.com>
+Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
+Acked-by: Mike Snitzer <snitzer@redhat.com>
+Fixes: 620125f2bf8ff0c4969b79653b54d7bcc9d40637
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 &&
--- /dev/null
+From d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 Mon Sep 17 00:00:00 2001
+From: Mel Gorman <mgorman@suse.de>
+Date: Thu, 2 Oct 2014 19:47:41 +0100
+Subject: mm: migrate: Close race between migration completion and mprotect
+
+From: Mel Gorman <mgorman@suse.de>
+
+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 <mgorman@suse.de>
+Acked-by: Rik van Riel <riel@redhat.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 6c72e3501d0d62fc064d3680e5234f3463ec5a86 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Thu, 2 Oct 2014 16:17:02 -0700
+Subject: perf: fix perf bug in fork()
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+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 <oleg@redhat.com>
+Reported-by: Oleg Nesterov <oleg@redhat.com>
+Reported-by: Sylvain 'ythier' Hitier <sylvain.hitier@gmail.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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:
--- /dev/null
+From 24607f114fd14f2f37e3e0cb3d47bce96e81e848 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
+Date: Thu, 2 Oct 2014 16:51:18 -0400
+Subject: ring-buffer: Fix infinite spin in reading buffer
+
+From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
+
+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 <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
