From: Greg Kroah-Hartman Date: Mon, 7 Jul 2014 20:45:38 +0000 (-0700) Subject: 3.15-stable patches X-Git-Tag: v3.4.98~25 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c3d6366b10240fd4a084cfa344e0dd07ebb71f69;p=thirdparty%2Fkernel%2Fstable-queue.git 3.15-stable patches added patches: arc-fix-build-breakage-for-config_arc_dw2_unwind.patch btrfs-only-unlock-block-in-verify_parent_transid-if-we-locked-it.patch iio-of_iio_channel_get_by_name-returns-non-null-pointers-for-error-legs.patch irqchip-spear_shirq-fix-interrupt-offset.patch kvm-fix-wrong-address-when-writing-hyper-v-tsc-page.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 mlx4_core-fix-incorrect-flags1-bitmap-test-in-mlx4_query_func_cap.patch net-mlx4_core-keep-only-one-driver-entry-release-mlx4_priv.patch nfsd-fix-rare-symlink-decoding-bug.patch staging-iio-ad7291-fix-error-code-in-ad7291_probe.patch staging-tidspbridge-fix-an-erroneous-removal-of-parentheses.patch tools-ffs-test-fix-header-values-endianess.patch tracing-remove-ftrace_stop-start-from-reading-the-trace-file.patch tracing-uprobes-fix-the-usage-of-uprobe_buffer_enable-in-probe_event_enable.patch tracing-uprobes-revert-support-mix-of-ftrace-and-perf.patch --- diff --git a/queue-3.15/arc-fix-build-breakage-for-config_arc_dw2_unwind.patch b/queue-3.15/arc-fix-build-breakage-for-config_arc_dw2_unwind.patch new file mode 100644 index 00000000000..34778cba1ed --- /dev/null +++ b/queue-3.15/arc-fix-build-breakage-for-config_arc_dw2_unwind.patch @@ -0,0 +1,31 @@ +From ba25915fb2cd18152cb14b144dbe8bf2f2bd8e45 Mon Sep 17 00:00:00 2001 +From: Vineet Gupta +Date: Tue, 24 Jun 2014 19:33:39 +0530 +Subject: ARC: Fix build breakage for !CONFIG_ARC_DW2_UNWIND + +From: Vineet Gupta + +commit ba25915fb2cd18152cb14b144dbe8bf2f2bd8e45 upstream. + +Fixes: ec7ac6afd07b (ARC: switch to generic ENTRY/END assembler annotations) +Reported-by: Anton Kolesov +Signed-off-by: Vineet Gupta +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arc/kernel/ctx_sw_asm.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arc/kernel/ctx_sw_asm.S ++++ b/arch/arc/kernel/ctx_sw_asm.S +@@ -10,9 +10,9 @@ + * -This is the more "natural" hand written assembler + */ + ++#include + #include /* For the SAVE_* macros */ + #include +-#include + + #define KSP_WORD_OFF ((TASK_THREAD + THREAD_KSP) / 4) + diff --git a/queue-3.15/btrfs-only-unlock-block-in-verify_parent_transid-if-we-locked-it.patch b/queue-3.15/btrfs-only-unlock-block-in-verify_parent_transid-if-we-locked-it.patch new file mode 100644 index 00000000000..cda653f9c0a --- /dev/null +++ b/queue-3.15/btrfs-only-unlock-block-in-verify_parent_transid-if-we-locked-it.patch @@ -0,0 +1,33 @@ +From 472b909ff6f4884d235ef7b9d3847fad5efafbff Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Wed, 25 Jun 2014 13:45:41 -0700 +Subject: btrfs: only unlock block in verify_parent_transid if we locked it + +From: Josef Bacik + +commit 472b909ff6f4884d235ef7b9d3847fad5efafbff upstream. + +This is a regression from my patch a26e8c9f75b0bfd8cccc9e8f110737b136eb5994, we +need to only unlock the block if we were the one who locked it. Otherwise this +will trip BUG_ON()'s in locking.c Thanks, + +Signed-off-by: Josef Bacik +Signed-off-by: Chris Mason +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/disk-io.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -368,7 +368,8 @@ static int verify_parent_transid(struct + out: + unlock_extent_cached(io_tree, eb->start, eb->start + eb->len - 1, + &cached_state, GFP_NOFS); +- btrfs_tree_read_unlock_blocking(eb); ++ if (need_lock) ++ btrfs_tree_read_unlock_blocking(eb); + return ret; + } + diff --git a/queue-3.15/iio-of_iio_channel_get_by_name-returns-non-null-pointers-for-error-legs.patch b/queue-3.15/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.15/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.15/irqchip-spear_shirq-fix-interrupt-offset.patch b/queue-3.15/irqchip-spear_shirq-fix-interrupt-offset.patch new file mode 100644 index 00000000000..5e4a5dfe443 --- /dev/null +++ b/queue-3.15/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.15/kvm-fix-wrong-address-when-writing-hyper-v-tsc-page.patch b/queue-3.15/kvm-fix-wrong-address-when-writing-hyper-v-tsc-page.patch new file mode 100644 index 00000000000..a870f941686 --- /dev/null +++ b/queue-3.15/kvm-fix-wrong-address-when-writing-hyper-v-tsc-page.patch @@ -0,0 +1,35 @@ +From e1fa108d24697b78348fd4e5a531029a50d0d36d Mon Sep 17 00:00:00 2001 +From: Xiaoming Gao +Date: Thu, 19 Jun 2014 19:14:57 +0800 +Subject: kvm: fix wrong address when writing Hyper-V tsc page + +From: Xiaoming Gao + +commit e1fa108d24697b78348fd4e5a531029a50d0d36d upstream. + +When kvm_write_guest writes the tsc_ref structure to the guest, or it will lead +the low HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT bits of the TSC page address +must be cleared, or the guest can see a non-zero sequence number. + +Otherwise Windows guests would not be able to get a correct clocksource +(QueryPerformanceCounter will always return 0) which causes serious chaos. + +Signed-off-by: Xiaoming Gao +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/x86.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -1912,7 +1912,7 @@ static int set_msr_hyperv_pw(struct kvm_ + if (!(data & HV_X64_MSR_TSC_REFERENCE_ENABLE)) + break; + gfn = data >> HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT; +- if (kvm_write_guest(kvm, data, ++ if (kvm_write_guest(kvm, gfn << HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT, + &tsc_ref, sizeof(tsc_ref))) + return 1; + mark_page_dirty(kvm, gfn); diff --git a/queue-3.15/kvm-x86-increase-the-number-of-fixed-mtrr-regs-to-10.patch b/queue-3.15/kvm-x86-increase-the-number-of-fixed-mtrr-regs-to-10.patch new file mode 100644 index 00000000000..434dbe1c8c4 --- /dev/null +++ b/queue-3.15/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 +@@ -99,7 +99,7 @@ static inline gfn_t gfn_to_index(gfn_t g + #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.15/kvm-x86-preserve-the-high-32-bits-of-the-pat-register.patch b/queue-3.15/kvm-x86-preserve-the-high-32-bits-of-the-pat-register.patch new file mode 100644 index 00000000000..73d3215e71a --- /dev/null +++ b/queue-3.15/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 +@@ -466,7 +466,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; + + unsigned switch_db_regs; + unsigned long db[KVM_NR_DB_REGS]; diff --git a/queue-3.15/md-flush-writes-before-starting-a-recovery.patch b/queue-3.15/md-flush-writes-before-starting-a-recovery.patch new file mode 100644 index 00000000000..43488367b44 --- /dev/null +++ b/queue-3.15/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 +@@ -7491,6 +7491,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.15/md-make-sure-get_array_info-ioctl-reports-correct-clean-status.patch b/queue-3.15/md-make-sure-get_array_info-ioctl-reports-correct-clean-status.patch new file mode 100644 index 00000000000..63aca7677f0 --- /dev/null +++ b/queue-3.15/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 +@@ -5593,7 +5593,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, 29 May 2014 16:31:00 +0300 +Subject: mlx4_core: Fix incorrect FLAGS1 bitmap test in mlx4_QUERY_FUNC_CAP + +From: Jack Morgenstein + +commit bc82878baa10c2a6a4a6affaf52c152935112142 upstream. + +Commit eb17711bc1d6 ("net/mlx4_core: Introduce nic_info new flag in +QUERY_FUNC_CAP") did: + + if (func_cap->flags1 & QUERY_FUNC_CAP_FLAGS1_OFFSET) { + +which should be: + + if (func_cap->flags1 & QUERY_FUNC_CAP_FLAGS1_FORCE_VLAN) { + +Fix that. + +Fixes: eb17711bc1d6 ("net/mlx4_core: Introduce nic_info new flag in QUERY_FUNC_CAP") +Signed-off-by: Jack Morgenstein +Signed-off-by: Or Gerlitz +Signed-off-by: Roland Dreier +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/ethernet/mellanox/mlx4/fw.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/mellanox/mlx4/fw.c ++++ b/drivers/net/ethernet/mellanox/mlx4/fw.c +@@ -414,7 +414,7 @@ int mlx4_QUERY_FUNC_CAP(struct mlx4_dev + + MLX4_GET(func_cap->flags1, outbox, QUERY_FUNC_CAP_FLAGS1_OFFSET); + if (dev->caps.port_type[gen_or_port] == MLX4_PORT_TYPE_ETH) { +- if (func_cap->flags1 & QUERY_FUNC_CAP_FLAGS1_OFFSET) { ++ if (func_cap->flags1 & QUERY_FUNC_CAP_FLAGS1_FORCE_VLAN) { + mlx4_err(dev, "VLAN is enforced on this port\n"); + err = -EPROTONOSUPPORT; + goto out; diff --git a/queue-3.15/net-mlx4_core-keep-only-one-driver-entry-release-mlx4_priv.patch b/queue-3.15/net-mlx4_core-keep-only-one-driver-entry-release-mlx4_priv.patch new file mode 100644 index 00000000000..d2eae4c9fa7 --- /dev/null +++ b/queue-3.15/net-mlx4_core-keep-only-one-driver-entry-release-mlx4_priv.patch @@ -0,0 +1,46 @@ +From da1de8dfff09d33d4a5345762c21b487028e25f5 Mon Sep 17 00:00:00 2001 +From: Wei Yang +Date: Sun, 8 Jun 2014 13:49:46 +0300 +Subject: net/mlx4_core: Keep only one driver entry release mlx4_priv + +From: Wei Yang + +commit da1de8dfff09d33d4a5345762c21b487028e25f5 upstream. + +Following commit befdf89 "net/mlx4_core: Preserve pci_dev_data after +__mlx4_remove_one()", there are two mlx4 pci callbacks which will +attempt to release the mlx4_priv object -- .shutdown and .remove. + +This leads to a use-after-free access to the already freed mlx4_priv +instance and trigger a "Kernel access of bad area" crash when both +.shutdown and .remove are called. + +During reboot or kexec, .shutdown is called, with the VFs probed to +the host going through shutdown first and then the PF. Later, the PF +will trigger VFs' .remove since VFs still have driver attached. + +Fix that by keeping only one driver entry which releases mlx4_priv. + +Fixes: befdf89 ('net/mlx4_core: Preserve pci_dev_data after __mlx4_remove_one()') +CC: Bjorn Helgaas +Signed-off-by: Or Gerlitz +Signed-off-by: Jack Morgenstein +Signed-off-by: Wei Yang +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/ethernet/mellanox/mlx4/main.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/mellanox/mlx4/main.c ++++ b/drivers/net/ethernet/mellanox/mlx4/main.c +@@ -2800,7 +2800,7 @@ static struct pci_driver mlx4_driver = { + .name = DRV_NAME, + .id_table = mlx4_pci_table, + .probe = mlx4_init_one, +- .shutdown = mlx4_remove_one, ++ .shutdown = __mlx4_remove_one, + .remove = mlx4_remove_one, + .err_handler = &mlx4_err_handler, + }; diff --git a/queue-3.15/nfsd-fix-rare-symlink-decoding-bug.patch b/queue-3.15/nfsd-fix-rare-symlink-decoding-bug.patch new file mode 100644 index 00000000000..e8ee9a7e94d --- /dev/null +++ b/queue-3.15/nfsd-fix-rare-symlink-decoding-bug.patch @@ -0,0 +1,96 @@ +From 76f47128f9b33af1e96819746550d789054c9664 Mon Sep 17 00:00:00 2001 +From: "J. Bruce Fields" +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 +@@ -618,15 +618,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 +@@ -602,7 +602,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.15/series b/queue-3.15/series index fb2d2c3a626..3fc5d8aeaac 100644 --- a/queue-3.15/series +++ b/queue-3.15/series @@ -93,3 +93,21 @@ fs-seq_file-fallback-to-vmalloc-allocation.patch mm-page_alloc-fix-cma-area-initialisation-when-pageblock-max_order.patch zram-revalidate-disk-after-capacity-change.patch proc-stat-convert-to-single_open_size.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 +kvm-fix-wrong-address-when-writing-hyper-v-tsc-page.patch +iio-of_iio_channel_get_by_name-returns-non-null-pointers-for-error-legs.patch +staging-iio-ad7291-fix-error-code-in-ad7291_probe.patch +nfsd-fix-rare-symlink-decoding-bug.patch +tools-ffs-test-fix-header-values-endianess.patch +staging-tidspbridge-fix-an-erroneous-removal-of-parentheses.patch +tracing-remove-ftrace_stop-start-from-reading-the-trace-file.patch +tracing-uprobes-revert-support-mix-of-ftrace-and-perf.patch +tracing-uprobes-fix-the-usage-of-uprobe_buffer_enable-in-probe_event_enable.patch +btrfs-only-unlock-block-in-verify_parent_transid-if-we-locked-it.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 +arc-fix-build-breakage-for-config_arc_dw2_unwind.patch +mlx4_core-fix-incorrect-flags1-bitmap-test-in-mlx4_query_func_cap.patch +net-mlx4_core-keep-only-one-driver-entry-release-mlx4_priv.patch diff --git a/queue-3.15/staging-iio-ad7291-fix-error-code-in-ad7291_probe.patch b/queue-3.15/staging-iio-ad7291-fix-error-code-in-ad7291_probe.patch new file mode 100644 index 00000000000..ce49e1e7194 --- /dev/null +++ b/queue-3.15/staging-iio-ad7291-fix-error-code-in-ad7291_probe.patch @@ -0,0 +1,43 @@ +From b70e19c222a64018d308ebc80333575aff9f4e51 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Fri, 20 Jun 2014 20:22:00 +0100 +Subject: staging: iio/ad7291: fix error code in ad7291_probe() + +From: Dan Carpenter + +commit b70e19c222a64018d308ebc80333575aff9f4e51 upstream. + +We should be returning a negative error code instead of success here. + +This would have been detected by GCC, except that the "ret" variable was +initialized with a bogus value to disable GCC's uninitialized variable +warnings. I've cleaned that up, as well. + +Signed-off-by: Dan Carpenter +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/staging/iio/adc/ad7291.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/staging/iio/adc/ad7291.c ++++ b/drivers/staging/iio/adc/ad7291.c +@@ -465,7 +465,7 @@ static int ad7291_probe(struct i2c_clien + struct ad7291_platform_data *pdata = client->dev.platform_data; + struct ad7291_chip_info *chip; + struct iio_dev *indio_dev; +- int ret = 0; ++ int ret; + + indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*chip)); + if (!indio_dev) +@@ -475,7 +475,7 @@ static int ad7291_probe(struct i2c_clien + if (pdata && pdata->use_external_ref) { + chip->reg = devm_regulator_get(&client->dev, "vref"); + if (IS_ERR(chip->reg)) +- return ret; ++ return PTR_ERR(chip->reg); + + ret = regulator_enable(chip->reg); + if (ret) diff --git a/queue-3.15/staging-tidspbridge-fix-an-erroneous-removal-of-parentheses.patch b/queue-3.15/staging-tidspbridge-fix-an-erroneous-removal-of-parentheses.patch new file mode 100644 index 00000000000..a5f79ed4c56 --- /dev/null +++ b/queue-3.15/staging-tidspbridge-fix-an-erroneous-removal-of-parentheses.patch @@ -0,0 +1,46 @@ +From ff4f58f0ca5dee33a80a72393dd195de9284702b Mon Sep 17 00:00:00 2001 +From: Suman Anna +Date: Tue, 24 Jun 2014 00:24:25 -0500 +Subject: staging: tidspbridge: fix an erroneous removal of parentheses + +From: Suman Anna + +commit ff4f58f0ca5dee33a80a72393dd195de9284702b upstream. + +Commit 4a9fdbb (staging: core: tiomap3430.c Fix line over 80 characters.) +erroneously removed the parentheses around the function pointer leading +to the following build error (when enabling the build of TI DSP/Bridge +driver): + +drivers/staging/tidspbridge/core/tiomap3430.c: In function 'bridge_brd_monitor': +drivers/staging/tidspbridge/core/tiomap3430.c:283:10: error: invalid type argument of unary '*' (have 'u32') +make[3]: *** [drivers/staging/tidspbridge/core/tiomap3430.o] Error 1 + +Fix this build error properly. + +Fixes: 4a9fdbb (staging: core: tiomap3430.c Fix line over 80 characters.) +Cc: Aybuke Ozdemir +Cc: Peter P Waskiewicz Jr +Cc: Omar Ramirez Luna +Signed-off-by: Suman Anna +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/staging/tidspbridge/core/tiomap3430.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/staging/tidspbridge/core/tiomap3430.c ++++ b/drivers/staging/tidspbridge/core/tiomap3430.c +@@ -280,8 +280,10 @@ static int bridge_brd_monitor(struct bri + OMAP3430_IVA2_MOD, OMAP2_CM_CLKSTCTRL); + + /* Wait until the state has moved to ON */ +- while (*pdata->dsp_prm_read(OMAP3430_IVA2_MOD, OMAP2_PM_PWSTST)& +- OMAP_INTRANSITION_MASK); ++ while ((*pdata->dsp_prm_read)(OMAP3430_IVA2_MOD, ++ OMAP2_PM_PWSTST) & ++ OMAP_INTRANSITION_MASK) ++ ; + /* Disable Automatic transition */ + (*pdata->dsp_cm_write)(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, + OMAP3430_IVA2_MOD, OMAP2_CM_CLKSTCTRL); diff --git a/queue-3.15/tools-ffs-test-fix-header-values-endianess.patch b/queue-3.15/tools-ffs-test-fix-header-values-endianess.patch new file mode 100644 index 00000000000..dd3ca69eddb --- /dev/null +++ b/queue-3.15/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.15/tracing-remove-ftrace_stop-start-from-reading-the-trace-file.patch b/queue-3.15/tracing-remove-ftrace_stop-start-from-reading-the-trace-file.patch new file mode 100644 index 00000000000..df8d2edf2a3 --- /dev/null +++ b/queue-3.15/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 +@@ -1367,7 +1367,6 @@ void tracing_start(void) + + arch_spin_unlock(&ftrace_max_lock); + +- ftrace_start(); + out: + raw_spin_unlock_irqrestore(&global_trace.start_lock, flags); + } +@@ -1414,7 +1413,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; diff --git a/queue-3.15/tracing-uprobes-fix-the-usage-of-uprobe_buffer_enable-in-probe_event_enable.patch b/queue-3.15/tracing-uprobes-fix-the-usage-of-uprobe_buffer_enable-in-probe_event_enable.patch new file mode 100644 index 00000000000..f90725f25f5 --- /dev/null +++ b/queue-3.15/tracing-uprobes-fix-the-usage-of-uprobe_buffer_enable-in-probe_event_enable.patch @@ -0,0 +1,81 @@ +From fb6bab6a5ad46d00b5ffa22268f21df1cd7c59df Mon Sep 17 00:00:00 2001 +From: Oleg Nesterov +Date: Fri, 27 Jun 2014 19:01:46 +0200 +Subject: tracing/uprobes: Fix the usage of uprobe_buffer_enable() in probe_event_enable() + +From: Oleg Nesterov + +commit fb6bab6a5ad46d00b5ffa22268f21df1cd7c59df upstream. + +The usage of uprobe_buffer_enable() added by dcad1a20 is very wrong, + +1. uprobe_buffer_enable() and uprobe_buffer_disable() are not balanced, + _enable() should be called only if !enabled. + +2. If uprobe_buffer_enable() fails probe_event_enable() should clear + tp.flags and free event_file_link. + +3. If uprobe_register() fails it should do uprobe_buffer_disable(). + +Link: http://lkml.kernel.org/p/20140627170146.GA18332@redhat.com + +Acked-by: Namhyung Kim +Acked-by: Srikar Dronamraju +Reviewed-by: Masami Hiramatsu +Fixes: dcad1a204f72 "tracing/uprobes: Fetch args before reserving a ring buffer" +Signed-off-by: Oleg Nesterov +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/trace_uprobe.c | 31 +++++++++++++++++++------------ + 1 file changed, 19 insertions(+), 12 deletions(-) + +--- a/kernel/trace/trace_uprobe.c ++++ b/kernel/trace/trace_uprobe.c +@@ -911,26 +911,33 @@ probe_event_enable(struct trace_uprobe * + tu->tp.flags |= TP_FLAG_PROFILE; + } + +- ret = uprobe_buffer_enable(); +- if (ret < 0) +- return ret; +- + WARN_ON(!uprobe_filter_is_empty(&tu->filter)); + + if (enabled) + return 0; + ++ ret = uprobe_buffer_enable(); ++ if (ret) ++ goto err_flags; ++ + tu->consumer.filter = filter; + ret = uprobe_register(tu->inode, tu->offset, &tu->consumer); +- if (ret) { +- if (file) { +- list_del(&link->list); +- kfree(link); +- tu->tp.flags &= ~TP_FLAG_TRACE; +- } else +- tu->tp.flags &= ~TP_FLAG_PROFILE; +- } ++ if (ret) ++ goto err_buffer; ++ ++ return 0; + ++ err_buffer: ++ uprobe_buffer_disable(); ++ ++ err_flags: ++ if (file) { ++ list_del(&link->list); ++ kfree(link); ++ tu->tp.flags &= ~TP_FLAG_TRACE; ++ } else { ++ tu->tp.flags &= ~TP_FLAG_PROFILE; ++ } + return ret; + } + diff --git a/queue-3.15/tracing-uprobes-revert-support-mix-of-ftrace-and-perf.patch b/queue-3.15/tracing-uprobes-revert-support-mix-of-ftrace-and-perf.patch new file mode 100644 index 00000000000..786a65bcda2 --- /dev/null +++ b/queue-3.15/tracing-uprobes-revert-support-mix-of-ftrace-and-perf.patch @@ -0,0 +1,68 @@ +From 48212542067a7ff6cbe829dbae279c2ff7557b44 Mon Sep 17 00:00:00 2001 +From: Oleg Nesterov +Date: Fri, 27 Jun 2014 19:01:36 +0200 +Subject: tracing/uprobes: Revert "Support mix of ftrace and perf" + +From: Oleg Nesterov + +commit 48212542067a7ff6cbe829dbae279c2ff7557b44 upstream. + +This reverts commit 43fe98913c9f67e3b523615ee3316f9520a623e0. + +This patch is very wrong. Firstly, this change leads to unbalanced +uprobe_unregister(). Just for example, + + # perf probe -x /lib/libc.so.6 syscall + # echo 1 >> /sys/kernel/debug/tracing/events/probe_libc/enable + # perf record -e probe_libc:syscall whatever + +after that uprobe is dead (unregistered) but the user of ftrace/perf +can't know this, and it looks as if nobody hits this probe. + +This would be easy to fix, but there are other reasons why it is not +simple to mix ftrace and perf. If nothing else, they can't share the +same ->consumer.filter. This is fixable too, but probably we need to +fix the poorly designed uprobe_register() interface first. At least +"register" and "apply" should be clearly separated. + +Link: http://lkml.kernel.org/p/20140627170136.GA18319@redhat.com + +Cc: Tom Zanussi +Cc: "zhangwei(Jovi)" +Acked-by: Namhyung Kim +Acked-by: Srikar Dronamraju +Reviewed-by: Masami Hiramatsu +Signed-off-by: Oleg Nesterov +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/trace_uprobe.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/kernel/trace/trace_uprobe.c ++++ b/kernel/trace/trace_uprobe.c +@@ -893,6 +893,9 @@ probe_event_enable(struct trace_uprobe * + int ret; + + if (file) { ++ if (tu->tp.flags & TP_FLAG_PROFILE) ++ return -EINTR; ++ + link = kmalloc(sizeof(*link), GFP_KERNEL); + if (!link) + return -ENOMEM; +@@ -901,8 +904,12 @@ probe_event_enable(struct trace_uprobe * + list_add_tail_rcu(&link->list, &tu->tp.files); + + tu->tp.flags |= TP_FLAG_TRACE; +- } else ++ } else { ++ if (tu->tp.flags & TP_FLAG_TRACE) ++ return -EINTR; ++ + tu->tp.flags |= TP_FLAG_PROFILE; ++ } + + ret = uprobe_buffer_enable(); + if (ret < 0)