--- /dev/null
+From a2c12493ed7e63a18cef33a71686d12ffcd6600e Mon Sep 17 00:00:00 2001
+From: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
+Date: Thu, 6 Nov 2014 12:11:00 +0000
+Subject: iio: of_iio_channel_get_by_name() returns non-null pointers for error legs
+
+From: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
+
+commit a2c12493ed7e63a18cef33a71686d12ffcd6600e upstream.
+
+Currently in the inkern.c code for IIO framework, the function
+of_iio_channel_get_by_name() will return a non-NULL pointer when
+it cannot find a channel using of_iio_channel_get() and when it
+tries to search for 'io-channel-ranges' property and fails. This
+is incorrect behaviour as the function which calls this expects
+a NULL pointer for failure. This patch rectifies the issue.
+
+Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
+Signed-off-by: Jonathan Cameron <jic23@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/inkern.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/inkern.c
++++ b/drivers/iio/inkern.c
+@@ -183,7 +183,7 @@ static struct iio_channel *of_iio_channe
+ else if (name && index >= 0) {
+ pr_err("ERROR: could not get IIO channel %s:%s(%i)\n",
+ np->full_name, name ? name : "", index);
+- return chan;
++ return NULL;
+ }
+
+ /*
+@@ -193,8 +193,9 @@ static struct iio_channel *of_iio_channe
+ */
+ np = np->parent;
+ if (np && !of_get_property(np, "io-channel-ranges", NULL))
+- break;
++ return NULL;
+ }
++
+ return chan;
+ }
+
+@@ -317,6 +318,7 @@ struct iio_channel *iio_channel_get(stru
+ if (channel != NULL)
+ return channel;
+ }
++
+ return iio_channel_get_sys(name, channel_name);
+ }
+ EXPORT_SYMBOL_GPL(iio_channel_get);
--- /dev/null
+From 4f4366033945419b0c52118c29d3057d7c558765 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Thu, 19 Jun 2014 21:34:37 +0000
+Subject: irqchip: spear_shirq: Fix interrupt offset
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 4f4366033945419b0c52118c29d3057d7c558765 upstream.
+
+The ras3 block on spear320 claims to have 3 interrupts. In fact it has
+one and 6 reserved interrupts. Account the 6 reserved to this block so
+it has 7 interrupts total. That matches the datasheet and the device
+tree entries.
+
+Broken since commit 80515a5a(ARM: SPEAr3xx: shirq: simplify and move
+the shared irq multiplexor to DT). Testing is overrated....
+
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lkml.kernel.org/r/20140619212712.872379208@linutronix.de
+Fixes: 80515a5a2e3c ('ARM: SPEAr3xx: shirq: simplify and move the shared irq multiplexor to DT')
+Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/irqchip/spear-shirq.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/irqchip/spear-shirq.c
++++ b/drivers/irqchip/spear-shirq.c
+@@ -125,7 +125,7 @@ static struct spear_shirq spear320_shirq
+ };
+
+ static struct spear_shirq spear320_shirq_ras3 = {
+- .irq_nr = 3,
++ .irq_nr = 7,
+ .irq_bit_off = 0,
+ .invalid_irq = 1,
+ .regs = {
--- /dev/null
+From 682367c494869008eb89ef733f196e99415ae862 Mon Sep 17 00:00:00 2001
+From: Nadav Amit <namit@cs.technion.ac.il>
+Date: Wed, 18 Jun 2014 17:21:19 +0300
+Subject: KVM: x86: Increase the number of fixed MTRR regs to 10
+
+From: Nadav Amit <namit@cs.technion.ac.il>
+
+commit 682367c494869008eb89ef733f196e99415ae862 upstream.
+
+Recent Intel CPUs have 10 variable range MTRRs. Since operating systems
+sometime make assumptions on CPUs while they ignore capability MSRs, it is
+better for KVM to be consistent with recent CPUs. Reporting more MTRRs than
+actually supported has no functional implications.
+
+Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/kvm_host.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/include/asm/kvm_host.h
++++ b/arch/x86/include/asm/kvm_host.h
+@@ -92,7 +92,7 @@
+ #define KVM_REFILL_PAGES 25
+ #define KVM_MAX_CPUID_ENTRIES 80
+ #define KVM_NR_FIXED_MTRR_REGION 88
+-#define KVM_NR_VAR_MTRR 8
++#define KVM_NR_VAR_MTRR 10
+
+ #define ASYNC_PF_PER_VCPU 64
+
--- /dev/null
+From 7cb060a91c0efc5ff94f83c6df3ed705e143cdb9 Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Thu, 19 Jun 2014 11:40:18 +0200
+Subject: KVM: x86: preserve the high 32-bits of the PAT register
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+commit 7cb060a91c0efc5ff94f83c6df3ed705e143cdb9 upstream.
+
+KVM does not really do much with the PAT, so this went unnoticed for a
+long time. It is exposed however if you try to do rdmsr on the PAT
+register.
+
+Reported-by: Valentine Sinitsyn <valentine.sinitsyn@gmail.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/kvm_host.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/include/asm/kvm_host.h
++++ b/arch/x86/include/asm/kvm_host.h
+@@ -445,7 +445,7 @@ struct kvm_vcpu_arch {
+ bool nmi_injected; /* Trying to inject an NMI this entry */
+
+ struct mtrr_state_type mtrr_state;
+- u32 pat;
++ u64 pat;
+
+ int switch_db_regs;
+ unsigned long db[KVM_NR_DB_REGS];
--- /dev/null
+From 133d4527eab8d199a62eee6bd433f0776842df2e Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Wed, 2 Jul 2014 12:04:14 +1000
+Subject: md: flush writes before starting a recovery.
+
+From: NeilBrown <neilb@suse.de>
+
+commit 133d4527eab8d199a62eee6bd433f0776842df2e upstream.
+
+When we write to a degraded array which has a bitmap, we
+make sure the relevant bit in the bitmap remains set when
+the write completes (so a 're-add' can quickly rebuilt a
+temporarily-missing device).
+
+If, immediately after such a write starts, we incorporate a spare,
+commence recovery, and skip over the region where the write is
+happening (because the 'needs recovery' flag isn't set yet),
+then that write will not get to the new device.
+
+Once the recovery finishes the new device will be trusted, but will
+have incorrect data, leading to possible corruption.
+
+We cannot set the 'needs recovery' flag when we start the write as we
+do not know easily if the write will be "degraded" or not. That
+depends on details of the particular raid level and particular write
+request.
+
+This patch fixes a corruption issue of long standing and so it
+suitable for any -stable kernel. It applied correctly to 3.0 at
+least and will minor editing to earlier kernels.
+
+Reported-by: Bill <billstuff2001@sbcglobal.net>
+Tested-by: Bill <billstuff2001@sbcglobal.net>
+Link: http://lkml.kernel.org/r/53A518BB.60709@sbcglobal.net
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/md.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -7447,6 +7447,19 @@ void md_do_sync(struct md_thread *thread
+ rdev->recovery_offset < j)
+ j = rdev->recovery_offset;
+ rcu_read_unlock();
++
++ /* If there is a bitmap, we need to make sure all
++ * writes that started before we added a spare
++ * complete before we start doing a recovery.
++ * Otherwise the write might complete and (via
++ * bitmap_endwrite) set a bit in the bitmap after the
++ * recovery has checked that bit and skipped that
++ * region.
++ */
++ if (mddev->bitmap) {
++ mddev->pers->quiesce(mddev, 1);
++ mddev->pers->quiesce(mddev, 0);
++ }
+ }
+
+ printk(KERN_INFO "md: %s of RAID array %s\n", desc, mdname(mddev));
--- /dev/null
+From 9bd359203210efeb5d8f0d81c155079f34b47449 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Wed, 2 Jul 2014 11:35:06 +1000
+Subject: md: make sure GET_ARRAY_INFO ioctl reports correct "clean" status
+
+From: NeilBrown <neilb@suse.de>
+
+commit 9bd359203210efeb5d8f0d81c155079f34b47449 upstream.
+
+If an array has a bitmap, the when we set the "has bitmap" flag we
+incorrectly clear the "is clean" flag.
+
+"is clean" isn't really important when a bitmap is present, but it is
+best to get it right anyway.
+
+Reported-by: George Duffield <forumscollective@gmail.com>
+Link: http://lkml.kernel.org/CAG__1a4MRV6gJL38XLAurtoSiD3rLBTmWpcS5HYvPpSfPR88UQ@mail.gmail.com
+Fixes: 36fa30636fb84b209210299684e1be66d9e58217 (v2.6.14)
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/md.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -5606,7 +5606,7 @@ static int get_array_info(struct mddev *
+ if (mddev->in_sync)
+ info.state = (1<<MD_SB_CLEAN);
+ if (mddev->bitmap && mddev->bitmap_info.offset)
+- info.state = (1<<MD_SB_BITMAP_PRESENT);
++ info.state |= (1<<MD_SB_BITMAP_PRESENT);
+ info.active_disks = insync;
+ info.working_disks = working;
+ info.failed_disks = failed;
--- /dev/null
+From 76f47128f9b33af1e96819746550d789054c9664 Mon Sep 17 00:00:00 2001
+From: "J. Bruce Fields" <bfields@redhat.com>
+Date: Thu, 19 Jun 2014 16:44:48 -0400
+Subject: nfsd: fix rare symlink decoding bug
+
+From: "J. Bruce Fields" <bfields@redhat.com>
+
+commit 76f47128f9b33af1e96819746550d789054c9664 upstream.
+
+An NFS operation that creates a new symlink includes the symlink data,
+which is xdr-encoded as a length followed by the data plus 0 to 3 bytes
+of zero-padding as required to reach a 4-byte boundary.
+
+The vfs, on the other hand, wants null-terminated data.
+
+The simple way to handle this would be by copying the data into a newly
+allocated buffer with space for the final null.
+
+The current nfsd_symlink code tries to be more clever by skipping that
+step in the (likely) case where the byte following the string is already
+0.
+
+But that assumes that the byte following the string is ours to look at.
+In fact, it might be the first byte of a page that we can't read, or of
+some object that another task might modify.
+
+Worse, the NFSv4 code tries to fix the problem by actually writing to
+that byte.
+
+In the NFSv2/v3 cases this actually appears to be safe:
+
+ - nfs3svc_decode_symlinkargs explicitly null-terminates the data
+ (after first checking its length and copying it to a new
+ page).
+ - NFSv2 limits symlinks to 1k. The buffer holding the rpc
+ request is always at least a page, and the link data (and
+ previous fields) have maximum lengths that prevent the request
+ from reaching the end of a page.
+
+In the NFSv4 case the CREATE op is potentially just one part of a long
+compound so can end up on the end of a page if you're unlucky.
+
+The minimal fix here is to copy and null-terminate in the NFSv4 case.
+The nfsd_symlink() interface here seems too fragile, though. It should
+really either do the copy itself every time or just require a
+null-terminated string.
+
+Reported-by: Jeff Layton <jlayton@primarydata.com>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfsd/nfs4proc.c | 9 ---------
+ fs/nfsd/nfs4xdr.c | 13 ++++++++++++-
+ 2 files changed, 12 insertions(+), 10 deletions(-)
+
+--- a/fs/nfsd/nfs4proc.c
++++ b/fs/nfsd/nfs4proc.c
+@@ -576,15 +576,6 @@ nfsd4_create(struct svc_rqst *rqstp, str
+
+ switch (create->cr_type) {
+ case NF4LNK:
+- /* ugh! we have to null-terminate the linktext, or
+- * vfs_symlink() will choke. it is always safe to
+- * null-terminate by brute force, since at worst we
+- * will overwrite the first byte of the create namelen
+- * in the XDR buffer, which has already been extracted
+- * during XDR decode.
+- */
+- create->cr_linkname[create->cr_linklen] = 0;
+-
+ status = nfsd_symlink(rqstp, &cstate->current_fh,
+ create->cr_name, create->cr_namelen,
+ create->cr_linkname, create->cr_linklen,
+--- a/fs/nfsd/nfs4xdr.c
++++ b/fs/nfsd/nfs4xdr.c
+@@ -553,7 +553,18 @@ nfsd4_decode_create(struct nfsd4_compoun
+ READ_BUF(4);
+ READ32(create->cr_linklen);
+ READ_BUF(create->cr_linklen);
+- SAVEMEM(create->cr_linkname, create->cr_linklen);
++ /*
++ * The VFS will want a null-terminated string, and
++ * null-terminating in place isn't safe since this might
++ * end on a page boundary:
++ */
++ create->cr_linkname =
++ kmalloc(create->cr_linklen + 1, GFP_KERNEL);
++ if (!create->cr_linkname)
++ return nfserr_jukebox;
++ memcpy(create->cr_linkname, p, create->cr_linklen);
++ create->cr_linkname[create->cr_linklen] = '\0';
++ defer_free(argp, kfree, create->cr_linkname);
+ break;
+ case NF4BLK:
+ case NF4CHR:
cifs-fix-mount-failure-with-broken-pathnames-when-smb3-mount-with-mapchars-option.patch
ext4-fix-buffer-double-free-in-ext4_alloc_branch.patch
ext4-fix-hole-punching-for-files-with-indirect-blocks.patch
+kvm-x86-increase-the-number-of-fixed-mtrr-regs-to-10.patch
+kvm-x86-preserve-the-high-32-bits-of-the-pat-register.patch
+iio-of_iio_channel_get_by_name-returns-non-null-pointers-for-error-legs.patch
+nfsd-fix-rare-symlink-decoding-bug.patch
+tools-ffs-test-fix-header-values-endianess.patch
+tracing-remove-ftrace_stop-start-from-reading-the-trace-file.patch
+md-flush-writes-before-starting-a-recovery.patch
+md-make-sure-get_array_info-ioctl-reports-correct-clean-status.patch
+irqchip-spear_shirq-fix-interrupt-offset.patch
--- /dev/null
+From f35f71244da6e51db4e1f2c7e318581f498ececf Mon Sep 17 00:00:00 2001
+From: Michal Nazarewicz <mina86@mina86.com>
+Date: Fri, 13 Jun 2014 15:38:05 +0200
+Subject: tools: ffs-test: fix header values endianess
+
+From: Michal Nazarewicz <mina86@mina86.com>
+
+commit f35f71244da6e51db4e1f2c7e318581f498ececf upstream.
+
+It appears that no one ever run ffs-test on a big-endian machine,
+since it used cpu-endianess for fs_count and hs_count fields which
+should be in little-endian format. Fix by wrapping the numbers in
+cpu_to_le32.
+
+Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
+Signed-off-by: Felipe Balbi <balbi@ti.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/usb/ffs-test.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/tools/usb/ffs-test.c
++++ b/tools/usb/ffs-test.c
+@@ -116,8 +116,8 @@ static const struct {
+ .header = {
+ .magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC),
+ .length = cpu_to_le32(sizeof descriptors),
+- .fs_count = 3,
+- .hs_count = 3,
++ .fs_count = cpu_to_le32(3),
++ .hs_count = cpu_to_le32(3),
+ },
+ .fs_descs = {
+ .intf = {
--- /dev/null
+From 099ed151675cd1d2dbeae1dac697975f6a68716d Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
+Date: Tue, 24 Jun 2014 23:50:09 -0400
+Subject: tracing: Remove ftrace_stop/start() from reading the trace file
+
+From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
+
+commit 099ed151675cd1d2dbeae1dac697975f6a68716d upstream.
+
+Disabling reading and writing to the trace file should not be able to
+disable all function tracing callbacks. There's other users today
+(like kprobes and perf). Reading a trace file should not stop those
+from happening.
+
+Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -1306,7 +1306,6 @@ void tracing_start(void)
+
+ arch_spin_unlock(&ftrace_max_lock);
+
+- ftrace_start();
+ out:
+ raw_spin_unlock_irqrestore(&global_trace.start_lock, flags);
+ }
+@@ -1353,7 +1352,6 @@ void tracing_stop(void)
+ struct ring_buffer *buffer;
+ unsigned long flags;
+
+- ftrace_stop();
+ raw_spin_lock_irqsave(&global_trace.start_lock, flags);
+ if (global_trace.stop_count++)
+ goto out;
projects / thirdparty / kernel / stable-queue.git / commitdiff
