From: Greg Kroah-Hartman Date: Mon, 7 Jul 2014 20:45:22 +0000 (-0700) Subject: 3.10-stable patches X-Git-Tag: v3.4.98~27 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=593e1ccb7f086dec15e84a585694ecdd5479164c;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: iio-of_iio_channel_get_by_name-returns-non-null-pointers-for-error-legs.patch irqchip-spear_shirq-fix-interrupt-offset.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 md-flush-writes-before-starting-a-recovery.patch md-make-sure-get_array_info-ioctl-reports-correct-clean-status.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 --- diff --git a/queue-3.10/iio-of_iio_channel_get_by_name-returns-non-null-pointers-for-error-legs.patch b/queue-3.10/iio-of_iio_channel_get_by_name-returns-non-null-pointers-for-error-legs.patch new file mode 100644 index 00000000000..4e2a68ea2a6 --- /dev/null +++ b/queue-3.10/iio-of_iio_channel_get_by_name-returns-non-null-pointers-for-error-legs.patch @@ -0,0 +1,54 @@ +From a2c12493ed7e63a18cef33a71686d12ffcd6600e Mon Sep 17 00:00:00 2001 +From: Adam Thomson +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 + +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 +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.10/irqchip-spear_shirq-fix-interrupt-offset.patch b/queue-3.10/irqchip-spear_shirq-fix-interrupt-offset.patch new file mode 100644 index 00000000000..5e4a5dfe443 --- /dev/null +++ b/queue-3.10/irqchip-spear_shirq-fix-interrupt-offset.patch @@ -0,0 +1,39 @@ +From 4f4366033945419b0c52118c29d3057d7c558765 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Thu, 19 Jun 2014 21:34:37 +0000 +Subject: irqchip: spear_shirq: Fix interrupt offset + +From: Thomas Gleixner + +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 +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 +Signed-off-by: Jason Cooper +Signed-off-by: Greg Kroah-Hartman + +--- + 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 = { diff --git a/queue-3.10/kvm-x86-increase-the-number-of-fixed-mtrr-regs-to-10.patch b/queue-3.10/kvm-x86-increase-the-number-of-fixed-mtrr-regs-to-10.patch new file mode 100644 index 00000000000..c79bf4dbc3a --- /dev/null +++ b/queue-3.10/kvm-x86-increase-the-number-of-fixed-mtrr-regs-to-10.patch @@ -0,0 +1,33 @@ +From 682367c494869008eb89ef733f196e99415ae862 Mon Sep 17 00:00:00 2001 +From: Nadav Amit +Date: Wed, 18 Jun 2014 17:21:19 +0300 +Subject: KVM: x86: Increase the number of fixed MTRR regs to 10 + +From: Nadav Amit + +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 +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + 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 + diff --git a/queue-3.10/kvm-x86-preserve-the-high-32-bits-of-the-pat-register.patch b/queue-3.10/kvm-x86-preserve-the-high-32-bits-of-the-pat-register.patch new file mode 100644 index 00000000000..dc14b5306b3 --- /dev/null +++ b/queue-3.10/kvm-x86-preserve-the-high-32-bits-of-the-pat-register.patch @@ -0,0 +1,32 @@ +From 7cb060a91c0efc5ff94f83c6df3ed705e143cdb9 Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Thu, 19 Jun 2014 11:40:18 +0200 +Subject: KVM: x86: preserve the high 32-bits of the PAT register + +From: Paolo Bonzini + +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 +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + 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]; diff --git a/queue-3.10/md-flush-writes-before-starting-a-recovery.patch b/queue-3.10/md-flush-writes-before-starting-a-recovery.patch new file mode 100644 index 00000000000..59d506ac819 --- /dev/null +++ b/queue-3.10/md-flush-writes-before-starting-a-recovery.patch @@ -0,0 +1,63 @@ +From 133d4527eab8d199a62eee6bd433f0776842df2e Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Wed, 2 Jul 2014 12:04:14 +1000 +Subject: md: flush writes before starting a recovery. + +From: NeilBrown + +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 +Tested-by: Bill +Link: http://lkml.kernel.org/r/53A518BB.60709@sbcglobal.net +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + 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)); diff --git a/queue-3.10/md-make-sure-get_array_info-ioctl-reports-correct-clean-status.patch b/queue-3.10/md-make-sure-get_array_info-ioctl-reports-correct-clean-status.patch new file mode 100644 index 00000000000..1ee5c022040 --- /dev/null +++ b/queue-3.10/md-make-sure-get_array_info-ioctl-reports-correct-clean-status.patch @@ -0,0 +1,36 @@ +From 9bd359203210efeb5d8f0d81c155079f34b47449 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Wed, 2 Jul 2014 11:35:06 +1000 +Subject: md: make sure GET_ARRAY_INFO ioctl reports correct "clean" status + +From: NeilBrown + +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 +Link: http://lkml.kernel.org/CAG__1a4MRV6gJL38XLAurtoSiD3rLBTmWpcS5HYvPpSfPR88UQ@mail.gmail.com +Fixes: 36fa30636fb84b209210299684e1be66d9e58217 (v2.6.14) +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + 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<bitmap && mddev->bitmap_info.offset) +- info.state = (1< +Date: Thu, 19 Jun 2014 16:44:48 -0400 +Subject: nfsd: fix rare symlink decoding bug + +From: "J. Bruce Fields" + +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 +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +--- + 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: diff --git a/queue-3.10/series b/queue-3.10/series index 8c8895d6fc0..cd8b691f482 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -34,3 +34,12 @@ b43-fix-frequency-reported-on-g-phy-with-new-firmware.patch 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 diff --git a/queue-3.10/tools-ffs-test-fix-header-values-endianess.patch b/queue-3.10/tools-ffs-test-fix-header-values-endianess.patch new file mode 100644 index 00000000000..dd3ca69eddb --- /dev/null +++ b/queue-3.10/tools-ffs-test-fix-header-values-endianess.patch @@ -0,0 +1,35 @@ +From f35f71244da6e51db4e1f2c7e318581f498ececf Mon Sep 17 00:00:00 2001 +From: Michal Nazarewicz +Date: Fri, 13 Jun 2014 15:38:05 +0200 +Subject: tools: ffs-test: fix header values endianess + +From: Michal Nazarewicz + +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 +Signed-off-by: Felipe Balbi +Signed-off-by: Greg Kroah-Hartman + +--- + 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 = { diff --git a/queue-3.10/tracing-remove-ftrace_stop-start-from-reading-the-trace-file.patch b/queue-3.10/tracing-remove-ftrace_stop-start-from-reading-the-trace-file.patch new file mode 100644 index 00000000000..c2bb70158fd --- /dev/null +++ b/queue-3.10/tracing-remove-ftrace_stop-start-from-reading-the-trace-file.patch @@ -0,0 +1,40 @@ +From 099ed151675cd1d2dbeae1dac697975f6a68716d Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Red Hat)" +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)" + +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 +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + 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;