--- /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
+@@ -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
+
--- /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
+@@ -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];
--- /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
+@@ -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));
--- /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
+@@ -5409,7 +5409,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
+@@ -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:
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
--- /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 = {
projects / thirdparty / kernel / stable-queue.git / commitdiff
