From: Greg Kroah-Hartman Date: Mon, 7 Jul 2014 20:42:31 +0000 (-0700) Subject: 3.4-stable patches X-Git-Tag: v3.4.98~28 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=42cf4c19beb916b5e7808c8f09edd331c07f7246;p=thirdparty%2Fkernel%2Fstable-queue.git 3.4-stable patches added patches: 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 --- diff --git a/queue-3.4/kvm-x86-increase-the-number-of-fixed-mtrr-regs-to-10.patch b/queue-3.4/kvm-x86-increase-the-number-of-fixed-mtrr-regs-to-10.patch new file mode 100644 index 00000000000..61497f5fd10 --- /dev/null +++ b/queue-3.4/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 +@@ -102,7 +102,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.4/kvm-x86-preserve-the-high-32-bits-of-the-pat-register.patch b/queue-3.4/kvm-x86-preserve-the-high-32-bits-of-the-pat-register.patch new file mode 100644 index 00000000000..5f9f4151586 --- /dev/null +++ b/queue-3.4/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 +@@ -436,7 +436,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.4/md-flush-writes-before-starting-a-recovery.patch b/queue-3.4/md-flush-writes-before-starting-a-recovery.patch new file mode 100644 index 00000000000..15ed6f28b1c --- /dev/null +++ b/queue-3.4/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 +@@ -7180,6 +7180,19 @@ void md_do_sync(struct mddev *mddev) + 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.4/md-make-sure-get_array_info-ioctl-reports-correct-clean-status.patch b/queue-3.4/md-make-sure-get_array_info-ioctl-reports-correct-clean-status.patch new file mode 100644 index 00000000000..cedb9fca1a3 --- /dev/null +++ b/queue-3.4/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 +@@ -5409,7 +5409,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 +@@ -543,15 +543,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 +@@ -465,7 +465,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.4/series b/queue-3.4/series index 93db10aca96..2ad6fc23cb5 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -19,3 +19,9 @@ mac80211-don-t-check-netdev-state-for-debugfs-read-write.patch arm-omap2-fix-parser-bug-in-platform-muxing-code.patch 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 +kvm-x86-increase-the-number-of-fixed-mtrr-regs-to-10.patch +kvm-x86-preserve-the-high-32-bits-of-the-pat-register.patch +nfsd-fix-rare-symlink-decoding-bug.patch +tools-ffs-test-fix-header-values-endianess.patch +md-flush-writes-before-starting-a-recovery.patch +md-make-sure-get_array_info-ioctl-reports-correct-clean-status.patch diff --git a/queue-3.4/tools-ffs-test-fix-header-values-endianess.patch b/queue-3.4/tools-ffs-test-fix-header-values-endianess.patch new file mode 100644 index 00000000000..dd3ca69eddb --- /dev/null +++ b/queue-3.4/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 = {