--- /dev/null
+From a5049a8ae34950249a7ae94c385d7c5c98914412 Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Thu, 19 Jun 2014 17:42:57 -0400
+Subject: blkcg: fix use-after-free in __blkg_release_rcu() by making blkcg_gq refcnt an atomic_t
+
+From: Tejun Heo <tj@kernel.org>
+
+commit a5049a8ae34950249a7ae94c385d7c5c98914412 upstream.
+
+Hello,
+
+So, this patch should do. Joe, Vivek, can one of you guys please
+verify that the oops goes away with this patch?
+
+Jens, the original thread can be read at
+
+ http://thread.gmane.org/gmane.linux.kernel/1720729
+
+The fix converts blkg->refcnt from int to atomic_t. It does some
+overhead but it should be minute compared to everything else which is
+going on and the involved cacheline bouncing, so I think it's highly
+unlikely to cause any noticeable difference. Also, the refcnt in
+question should be converted to a perpcu_ref for blk-mq anyway, so the
+atomic_t is likely to go away pretty soon anyway.
+
+Thanks.
+
+------- 8< -------
+__blkg_release_rcu() may be invoked after the associated request_queue
+is released with a RCU grace period inbetween. As such, the function
+and callbacks invoked from it must not dereference the associated
+request_queue. This is clearly indicated in the comment above the
+function.
+
+Unfortunately, while trying to fix a different issue, 2a4fd070ee85
+("blkcg: move bulk of blkcg_gq release operations to the RCU
+callback") ignored this and added [un]locking of @blkg->q->queue_lock
+to __blkg_release_rcu(). This of course can cause oops as the
+request_queue may be long gone by the time this code gets executed.
+
+ general protection fault: 0000 [#1] SMP
+ CPU: 21 PID: 30 Comm: rcuos/21 Not tainted 3.15.0 #1
+ Hardware name: Stratus ftServer 6400/G7LAZ, BIOS BIOS Version 6.3:57 12/25/2013
+ task: ffff880854021de0 ti: ffff88085403c000 task.ti: ffff88085403c000
+ RIP: 0010:[<ffffffff8162e9e5>] [<ffffffff8162e9e5>] _raw_spin_lock_irq+0x15/0x60
+ RSP: 0018:ffff88085403fdf0 EFLAGS: 00010086
+ RAX: 0000000000020000 RBX: 0000000000000010 RCX: 0000000000000000
+ RDX: 000060ef80008248 RSI: 0000000000000286 RDI: 6b6b6b6b6b6b6b6b
+ RBP: ffff88085403fdf0 R08: 0000000000000286 R09: 0000000000009f39
+ R10: 0000000000020001 R11: 0000000000020001 R12: ffff88103c17a130
+ R13: ffff88103c17a080 R14: 0000000000000000 R15: 0000000000000000
+ FS: 0000000000000000(0000) GS:ffff88107fca0000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 00000000006e5ab8 CR3: 000000000193d000 CR4: 00000000000407e0
+ Stack:
+ ffff88085403fe18 ffffffff812cbfc2 ffff88103c17a130 0000000000000000
+ ffff88103c17a130 ffff88085403fec0 ffffffff810d1d28 ffff880854021de0
+ ffff880854021de0 ffff88107fcaec58 ffff88085403fe80 ffff88107fcaec30
+ Call Trace:
+ [<ffffffff812cbfc2>] __blkg_release_rcu+0x72/0x150
+ [<ffffffff810d1d28>] rcu_nocb_kthread+0x1e8/0x300
+ [<ffffffff81091d81>] kthread+0xe1/0x100
+ [<ffffffff8163813c>] ret_from_fork+0x7c/0xb0
+ Code: ff 47 04 48 8b 7d 08 be 00 02 00 00 e8 55 48 a4 ff 5d c3 0f 1f 00 66 66 66 66 90 55 48 89 e5
+ +fa 66 66 90 66 66 90 b8 00 00 02 00 <f0> 0f c1 07 89 c2 c1 ea 10 66 39 c2 75 02 5d c3 83 e2 fe 0f
+ +b7
+ RIP [<ffffffff8162e9e5>] _raw_spin_lock_irq+0x15/0x60
+ RSP <ffff88085403fdf0>
+
+The request_queue locking was added because blkcg_gq->refcnt is an int
+protected with the queue lock and __blkg_release_rcu() needs to put
+the parent. Let's fix it by making blkcg_gq->refcnt an atomic_t and
+dropping queue locking in the function.
+
+Given the general heavy weight of the current request_queue and blkcg
+operations, this is unlikely to cause any noticeable overhead.
+Moreover, blkcg_gq->refcnt is likely to be converted to percpu_ref in
+the near future, so whatever (most likely negligible) overhead it may
+add is temporary.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
+Acked-by: Vivek Goyal <vgoyal@redhat.com>
+Link: http://lkml.kernel.org/g/alpine.DEB.2.02.1406081816540.17948@jlaw-desktop.mno.stratus.com
+Signed-off-by: Jens Axboe <axboe@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ block/blk-cgroup.c | 7 ++-----
+ block/blk-cgroup.h | 17 +++++++----------
+ 2 files changed, 9 insertions(+), 15 deletions(-)
+
+--- a/block/blk-cgroup.c
++++ b/block/blk-cgroup.c
+@@ -80,7 +80,7 @@ static struct blkcg_gq *blkg_alloc(struc
+ blkg->q = q;
+ INIT_LIST_HEAD(&blkg->q_node);
+ blkg->blkcg = blkcg;
+- blkg->refcnt = 1;
++ atomic_set(&blkg->refcnt, 1);
+
+ /* root blkg uses @q->root_rl, init rl only for !root blkgs */
+ if (blkcg != &blkcg_root) {
+@@ -399,11 +399,8 @@ void __blkg_release_rcu(struct rcu_head
+
+ /* release the blkcg and parent blkg refs this blkg has been holding */
+ css_put(&blkg->blkcg->css);
+- if (blkg->parent) {
+- spin_lock_irq(blkg->q->queue_lock);
++ if (blkg->parent)
+ blkg_put(blkg->parent);
+- spin_unlock_irq(blkg->q->queue_lock);
+- }
+
+ blkg_free(blkg);
+ }
+--- a/block/blk-cgroup.h
++++ b/block/blk-cgroup.h
+@@ -18,6 +18,7 @@
+ #include <linux/seq_file.h>
+ #include <linux/radix-tree.h>
+ #include <linux/blkdev.h>
++#include <linux/atomic.h>
+
+ /* Max limits for throttle policy */
+ #define THROTL_IOPS_MAX UINT_MAX
+@@ -104,7 +105,7 @@ struct blkcg_gq {
+ struct request_list rl;
+
+ /* reference count */
+- int refcnt;
++ atomic_t refcnt;
+
+ /* is this blkg online? protected by both blkcg and q locks */
+ bool online;
+@@ -253,13 +254,12 @@ static inline int blkg_path(struct blkcg
+ * blkg_get - get a blkg reference
+ * @blkg: blkg to get
+ *
+- * The caller should be holding queue_lock and an existing reference.
++ * The caller should be holding an existing reference.
+ */
+ static inline void blkg_get(struct blkcg_gq *blkg)
+ {
+- lockdep_assert_held(blkg->q->queue_lock);
+- WARN_ON_ONCE(!blkg->refcnt);
+- blkg->refcnt++;
++ WARN_ON_ONCE(atomic_read(&blkg->refcnt) <= 0);
++ atomic_inc(&blkg->refcnt);
+ }
+
+ void __blkg_release_rcu(struct rcu_head *rcu);
+@@ -267,14 +267,11 @@ void __blkg_release_rcu(struct rcu_head
+ /**
+ * blkg_put - put a blkg reference
+ * @blkg: blkg to put
+- *
+- * The caller should be holding queue_lock.
+ */
+ static inline void blkg_put(struct blkcg_gq *blkg)
+ {
+- lockdep_assert_held(blkg->q->queue_lock);
+- WARN_ON_ONCE(blkg->refcnt <= 0);
+- if (!--blkg->refcnt)
++ WARN_ON_ONCE(atomic_read(&blkg->refcnt) <= 0);
++ if (atomic_dec_and_test(&blkg->refcnt))
+ call_rcu(&blkg->rcu_head, __blkg_release_rcu);
+ }
+
--- /dev/null
+From c5c7b8ddfbf8cb3b2291e515a34ab1b8982f5a2d Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Sun, 15 Jun 2014 23:46:28 -0400
+Subject: ext4: Fix buffer double free in ext4_alloc_branch()
+
+From: Jan Kara <jack@suse.cz>
+
+commit c5c7b8ddfbf8cb3b2291e515a34ab1b8982f5a2d upstream.
+
+Error recovery in ext4_alloc_branch() calls ext4_forget() even for
+buffer corresponding to indirect block it did not allocate. This leads
+to brelse() being called twice for that buffer (once from ext4_forget()
+and once from cleanup in ext4_ind_map_blocks()) leading to buffer use
+count misaccounting. Eventually (but often much later because there
+are other users of the buffer) we will see messages like:
+VFS: brelse: Trying to free free buffer
+
+Another manifestation of this problem is an error:
+JBD2 unexpected failure: jbd2_journal_revoke: !buffer_revoked(bh);
+inconsistent data on disk
+
+The fix is easy - don't forget buffer we did not allocate. Also add an
+explanatory comment because the indexing at ext4_alloc_branch() is
+somewhat subtle.
+
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/indirect.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/fs/ext4/indirect.c
++++ b/fs/ext4/indirect.c
+@@ -389,7 +389,13 @@ static int ext4_alloc_branch(handle_t *h
+ return 0;
+ failed:
+ for (; i >= 0; i--) {
+- if (i != indirect_blks && branch[i].bh)
++ /*
++ * We want to ext4_forget() only freshly allocated indirect
++ * blocks. Buffer for new_blocks[i-1] is at branch[i].bh and
++ * buffer at branch[0].bh is indirect block / inode already
++ * existing before ext4_alloc_branch() was called.
++ */
++ if (i > 0 && i != indirect_blks && branch[i].bh)
+ ext4_forget(handle, 1, inode, branch[i].bh,
+ branch[i].bh->b_blocknr);
+ ext4_free_blocks(handle, inode, NULL, new_blocks[i],
--- /dev/null
+From a93cd4cf86466caa49cfe64607bea7f0bde3f916 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Thu, 26 Jun 2014 12:30:54 -0400
+Subject: ext4: Fix hole punching for files with indirect blocks
+
+From: Jan Kara <jack@suse.cz>
+
+commit a93cd4cf86466caa49cfe64607bea7f0bde3f916 upstream.
+
+Hole punching code for files with indirect blocks wrongly computed
+number of blocks which need to be cleared when traversing the indirect
+block tree. That could result in punching more blocks than actually
+requested and thus effectively cause a data loss. For example:
+
+fallocate -n -p 10240000 4096
+
+will punch the range 10240000 - 12632064 instead of the range 1024000 -
+10244096. Fix the calculation.
+
+Fixes: 8bad6fc813a3a5300f51369c39d315679fd88c72
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/indirect.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/fs/ext4/indirect.c
++++ b/fs/ext4/indirect.c
+@@ -1318,16 +1318,24 @@ static int free_hole_blocks(handle_t *ha
+ blk = *i_data;
+ if (level > 0) {
+ ext4_lblk_t first2;
++ ext4_lblk_t count2;
++
+ bh = sb_bread(inode->i_sb, le32_to_cpu(blk));
+ if (!bh) {
+ EXT4_ERROR_INODE_BLOCK(inode, le32_to_cpu(blk),
+ "Read failure");
+ return -EIO;
+ }
+- first2 = (first > offset) ? first - offset : 0;
++ if (first > offset) {
++ first2 = first - offset;
++ count2 = count;
++ } else {
++ first2 = 0;
++ count2 = count - (offset - first);
++ }
+ ret = free_hole_blocks(handle, inode, bh,
+ (__le32 *)bh->b_data, level - 1,
+- first2, count - offset,
++ first2, count2,
+ inode->i_sb->s_blocksize >> 2);
+ if (ret) {
+ brelse(bh);
--- /dev/null
+From 058504edd02667eef8fac9be27ab3ea74332e9b4 Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+Date: Wed, 2 Jul 2014 15:22:37 -0700
+Subject: fs/seq_file: fallback to vmalloc allocation
+
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+
+commit 058504edd02667eef8fac9be27ab3ea74332e9b4 upstream.
+
+There are a couple of seq_files which use the single_open() interface.
+This interface requires that the whole output must fit into a single
+buffer.
+
+E.g. for /proc/stat allocation failures have been observed because an
+order-4 memory allocation failed due to memory fragmentation. In such
+situations reading /proc/stat is not possible anymore.
+
+Therefore change the seq_file code to fallback to vmalloc allocations
+which will usually result in a couple of order-0 allocations and hence
+also work if memory is fragmented.
+
+For reference a call trace where reading from /proc/stat failed:
+
+ sadc: page allocation failure: order:4, mode:0x1040d0
+ CPU: 1 PID: 192063 Comm: sadc Not tainted 3.10.0-123.el7.s390x #1
+ [...]
+ Call Trace:
+ show_stack+0x6c/0xe8
+ warn_alloc_failed+0xd6/0x138
+ __alloc_pages_nodemask+0x9da/0xb68
+ __get_free_pages+0x2e/0x58
+ kmalloc_order_trace+0x44/0xc0
+ stat_open+0x5a/0xd8
+ proc_reg_open+0x8a/0x140
+ do_dentry_open+0x1bc/0x2c8
+ finish_open+0x46/0x60
+ do_last+0x382/0x10d0
+ path_openat+0xc8/0x4f8
+ do_filp_open+0x46/0xa8
+ do_sys_open+0x114/0x1f0
+ sysc_tracego+0x14/0x1a
+
+Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Tested-by: David Rientjes <rientjes@google.com>
+Cc: Ian Kent <raven@themaw.net>
+Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
+Cc: Thorsten Diehl <thorsten.diehl@de.ibm.com>
+Cc: Andrea Righi <andrea@betterlinux.com>
+Cc: Christoph Hellwig <hch@infradead.org>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Stefan Bader <stefan.bader@canonical.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/seq_file.c | 30 +++++++++++++++++++++---------
+ 1 file changed, 21 insertions(+), 9 deletions(-)
+
+--- a/fs/seq_file.c
++++ b/fs/seq_file.c
+@@ -8,8 +8,10 @@
+ #include <linux/fs.h>
+ #include <linux/export.h>
+ #include <linux/seq_file.h>
++#include <linux/vmalloc.h>
+ #include <linux/slab.h>
+ #include <linux/cred.h>
++#include <linux/mm.h>
+
+ #include <asm/uaccess.h>
+ #include <asm/page.h>
+@@ -30,6 +32,16 @@ static void seq_set_overflow(struct seq_
+ m->count = m->size;
+ }
+
++static void *seq_buf_alloc(unsigned long size)
++{
++ void *buf;
++
++ buf = kmalloc(size, GFP_KERNEL | __GFP_NOWARN);
++ if (!buf && size > PAGE_SIZE)
++ buf = vmalloc(size);
++ return buf;
++}
++
+ /**
+ * seq_open - initialize sequential file
+ * @file: file we initialize
+@@ -96,7 +108,7 @@ static int traverse(struct seq_file *m,
+ return 0;
+ }
+ if (!m->buf) {
+- m->buf = kmalloc(m->size = PAGE_SIZE, GFP_KERNEL);
++ m->buf = seq_buf_alloc(m->size = PAGE_SIZE);
+ if (!m->buf)
+ return -ENOMEM;
+ }
+@@ -135,9 +147,9 @@ static int traverse(struct seq_file *m,
+
+ Eoverflow:
+ m->op->stop(m, p);
+- kfree(m->buf);
++ kvfree(m->buf);
+ m->count = 0;
+- m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
++ m->buf = seq_buf_alloc(m->size <<= 1);
+ return !m->buf ? -ENOMEM : -EAGAIN;
+ }
+
+@@ -192,7 +204,7 @@ ssize_t seq_read(struct file *file, char
+
+ /* grab buffer if we didn't have one */
+ if (!m->buf) {
+- m->buf = kmalloc(m->size = PAGE_SIZE, GFP_KERNEL);
++ m->buf = seq_buf_alloc(m->size = PAGE_SIZE);
+ if (!m->buf)
+ goto Enomem;
+ }
+@@ -232,9 +244,9 @@ ssize_t seq_read(struct file *file, char
+ if (m->count < m->size)
+ goto Fill;
+ m->op->stop(m, p);
+- kfree(m->buf);
++ kvfree(m->buf);
+ m->count = 0;
+- m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
++ m->buf = seq_buf_alloc(m->size <<= 1);
+ if (!m->buf)
+ goto Enomem;
+ m->version = 0;
+@@ -350,7 +362,7 @@ EXPORT_SYMBOL(seq_lseek);
+ int seq_release(struct inode *inode, struct file *file)
+ {
+ struct seq_file *m = file->private_data;
+- kfree(m->buf);
++ kvfree(m->buf);
+ kfree(m);
+ return 0;
+ }
+@@ -605,13 +617,13 @@ EXPORT_SYMBOL(single_open);
+ int single_open_size(struct file *file, int (*show)(struct seq_file *, void *),
+ void *data, size_t size)
+ {
+- char *buf = kmalloc(size, GFP_KERNEL);
++ char *buf = seq_buf_alloc(size);
+ int ret;
+ if (!buf)
+ return -ENOMEM;
+ ret = single_open(file, show, data);
+ if (ret) {
+- kfree(buf);
++ kvfree(buf);
+ return ret;
+ }
+ ((struct seq_file *)file->private_data)->buf = buf;
--- /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 e1fa108d24697b78348fd4e5a531029a50d0d36d Mon Sep 17 00:00:00 2001
+From: Xiaoming Gao <newtongao@tencent.com>
+Date: Thu, 19 Jun 2014 19:14:57 +0800
+Subject: kvm: fix wrong address when writing Hyper-V tsc page
+
+From: Xiaoming Gao <newtongao@tencent.com>
+
+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 <newtongao@tencnet.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -1866,7 +1866,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);
--- /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
+@@ -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
+
--- /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
+@@ -462,7 +462,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
+@@ -7505,6 +7505,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
+@@ -5620,7 +5620,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 bc82878baa10c2a6a4a6affaf52c152935112142 Mon Sep 17 00:00:00 2001
+From: Jack Morgenstein <jackm@dev.mellanox.co.il>
+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 <jackm@dev.mellanox.co.il>
+
+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 <jackm@dev.mellanox.co.il>
+Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
+Signed-off-by: Roland Dreier <roland@purestorage.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -398,7 +398,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;
--- /dev/null
+From dc78327c0ea7da5186d8cbc1647bd6088c5c9fa5 Mon Sep 17 00:00:00 2001
+From: Michal Nazarewicz <mina86@mina86.com>
+Date: Wed, 2 Jul 2014 15:22:35 -0700
+Subject: mm: page_alloc: fix CMA area initialisation when pageblock > MAX_ORDER
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Michal Nazarewicz <mina86@mina86.com>
+
+commit dc78327c0ea7da5186d8cbc1647bd6088c5c9fa5 upstream.
+
+With a kernel configured with ARM64_64K_PAGES && !TRANSPARENT_HUGEPAGE,
+the following is triggered at early boot:
+
+ SMP: Total of 8 processors activated.
+ devtmpfs: initialized
+ Unable to handle kernel NULL pointer dereference at virtual address 00000008
+ pgd = fffffe0000050000
+ [00000008] *pgd=00000043fba00003, *pmd=00000043fba00003, *pte=00e0000078010407
+ Internal error: Oops: 96000006 [#1] SMP
+ Modules linked in:
+ CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc864k+ #44
+ task: fffffe03bc040000 ti: fffffe03bc080000 task.ti: fffffe03bc080000
+ PC is at __list_add+0x10/0xd4
+ LR is at free_one_page+0x270/0x638
+ ...
+ Call trace:
+ __list_add+0x10/0xd4
+ free_one_page+0x26c/0x638
+ __free_pages_ok.part.52+0x84/0xbc
+ __free_pages+0x74/0xbc
+ init_cma_reserved_pageblock+0xe8/0x104
+ cma_init_reserved_areas+0x190/0x1e4
+ do_one_initcall+0xc4/0x154
+ kernel_init_freeable+0x204/0x2a8
+ kernel_init+0xc/0xd4
+
+This happens because init_cma_reserved_pageblock() calls
+__free_one_page() with pageblock_order as page order but it is bigger
+than MAX_ORDER. This in turn causes accesses past zone->free_list[].
+
+Fix the problem by changing init_cma_reserved_pageblock() such that it
+splits pageblock into individual MAX_ORDER pages if pageblock is bigger
+than a MAX_ORDER page.
+
+In cases where !CONFIG_HUGETLB_PAGE_SIZE_VARIABLE, which is all
+architectures expect for ia64, powerpc and tile at the moment, the
+â\80\9cpageblock_order > MAX_ORDERâ\80\9d condition will be optimised out since both
+sides of the operator are constants. In cases where pageblock size is
+variable, the performance degradation should not be significant anyway
+since init_cma_reserved_pageblock() is called only at boot time at most
+MAX_CMA_AREAS times which by default is eight.
+
+Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
+Reported-by: Mark Salter <msalter@redhat.com>
+Tested-by: Mark Salter <msalter@redhat.com>
+Tested-by: Christopher Covington <cov@codeaurora.org>
+Cc: Mel Gorman <mgorman@suse.de>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/page_alloc.c | 16 ++++++++++++++--
+ 1 file changed, 14 insertions(+), 2 deletions(-)
+
+--- a/mm/page_alloc.c
++++ b/mm/page_alloc.c
+@@ -799,9 +799,21 @@ void __init init_cma_reserved_pageblock(
+ set_page_count(p, 0);
+ } while (++p, --i);
+
+- set_page_refcounted(page);
+ set_pageblock_migratetype(page, MIGRATE_CMA);
+- __free_pages(page, pageblock_order);
++
++ if (pageblock_order >= MAX_ORDER) {
++ i = pageblock_nr_pages;
++ p = page;
++ do {
++ set_page_refcounted(p);
++ __free_pages(p, MAX_ORDER - 1);
++ p += MAX_ORDER_NR_PAGES;
++ } while (i -= MAX_ORDER_NR_PAGES);
++ } else {
++ set_page_refcounted(page);
++ __free_pages(page, pageblock_order);
++ }
++
+ adjust_managed_page_count(page, pageblock_nr_pages);
+ }
+ #endif
--- /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
+@@ -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:
--- /dev/null
+From 39f1f78d53b9bcbca91967380c5f0f2305a5c55f Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Tue, 6 May 2014 14:02:53 -0400
+Subject: nick kvfree() from apparmor
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit 39f1f78d53b9bcbca91967380c5f0f2305a5c55f upstream.
+
+too many places open-code it
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/mm.h | 2 ++
+ mm/util.c | 10 ++++++++++
+ security/apparmor/include/apparmor.h | 1 -
+ security/apparmor/lib.c | 14 --------------
+ 4 files changed, 12 insertions(+), 15 deletions(-)
+
+--- a/include/linux/mm.h
++++ b/include/linux/mm.h
+@@ -362,6 +362,8 @@ static inline int is_vmalloc_or_module_a
+ }
+ #endif
+
++extern void kvfree(const void *addr);
++
+ static inline void compound_lock(struct page *page)
+ {
+ #ifdef CONFIG_TRANSPARENT_HUGEPAGE
+--- a/mm/util.c
++++ b/mm/util.c
+@@ -9,6 +9,7 @@
+ #include <linux/swapops.h>
+ #include <linux/mman.h>
+ #include <linux/hugetlb.h>
++#include <linux/vmalloc.h>
+
+ #include <asm/uaccess.h>
+
+@@ -386,6 +387,15 @@ unsigned long vm_mmap(struct file *file,
+ }
+ EXPORT_SYMBOL(vm_mmap);
+
++void kvfree(const void *addr)
++{
++ if (is_vmalloc_addr(addr))
++ vfree(addr);
++ else
++ kfree(addr);
++}
++EXPORT_SYMBOL(kvfree);
++
+ struct address_space *page_mapping(struct page *page)
+ {
+ struct address_space *mapping = page->mapping;
+--- a/security/apparmor/include/apparmor.h
++++ b/security/apparmor/include/apparmor.h
+@@ -66,7 +66,6 @@ extern int apparmor_initialized __initda
+ char *aa_split_fqname(char *args, char **ns_name);
+ void aa_info_message(const char *str);
+ void *__aa_kvmalloc(size_t size, gfp_t flags);
+-void kvfree(void *buffer);
+
+ static inline void *kvmalloc(size_t size)
+ {
+--- a/security/apparmor/lib.c
++++ b/security/apparmor/lib.c
+@@ -104,17 +104,3 @@ void *__aa_kvmalloc(size_t size, gfp_t f
+ }
+ return buffer;
+ }
+-
+-/**
+- * kvfree - free an allocation do by kvmalloc
+- * @buffer: buffer to free (MAYBE_NULL)
+- *
+- * Free a buffer allocated by kvmalloc
+- */
+-void kvfree(void *buffer)
+-{
+- if (is_vmalloc_addr(buffer))
+- vfree(buffer);
+- else
+- kfree(buffer);
+-}
--- /dev/null
+From f74373a5cc7a0155d232c4e999648c7a95435bb2 Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+Date: Wed, 2 Jul 2014 15:22:37 -0700
+Subject: /proc/stat: convert to single_open_size()
+
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+
+commit f74373a5cc7a0155d232c4e999648c7a95435bb2 upstream.
+
+These two patches are supposed to "fix" failed order-4 memory
+allocations which have been observed when reading /proc/stat. The
+problem has been observed on s390 as well as on x86.
+
+To address the problem change the seq_file memory allocations to
+fallback to use vmalloc, so that allocations also work if memory is
+fragmented.
+
+This approach seems to be simpler and less intrusive than changing
+/proc/stat to use an interator. Also it "fixes" other users as well,
+which use seq_file's single_open() interface.
+
+This patch (of 2):
+
+Use seq_file's single_open_size() to preallocate a buffer that is large
+enough to hold the whole output, instead of open coding it. Also
+calculate the requested size using the number of online cpus instead of
+possible cpus, since the size of the output only depends on the number
+of online cpus.
+
+Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Acked-by: David Rientjes <rientjes@google.com>
+Cc: Ian Kent <raven@themaw.net>
+Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
+Cc: Thorsten Diehl <thorsten.diehl@de.ibm.com>
+Cc: Andrea Righi <andrea@betterlinux.com>
+Cc: Christoph Hellwig <hch@infradead.org>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Stefan Bader <stefan.bader@canonical.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/proc/stat.c | 22 ++--------------------
+ 1 file changed, 2 insertions(+), 20 deletions(-)
+
+--- a/fs/proc/stat.c
++++ b/fs/proc/stat.c
+@@ -184,29 +184,11 @@ static int show_stat(struct seq_file *p,
+
+ static int stat_open(struct inode *inode, struct file *file)
+ {
+- size_t size = 1024 + 128 * num_possible_cpus();
+- char *buf;
+- struct seq_file *m;
+- int res;
++ size_t size = 1024 + 128 * num_online_cpus();
+
+ /* minimum size to display an interrupt count : 2 bytes */
+ size += 2 * nr_irqs;
+-
+- /* don't ask for more than the kmalloc() max size */
+- if (size > KMALLOC_MAX_SIZE)
+- size = KMALLOC_MAX_SIZE;
+- buf = kmalloc(size, GFP_KERNEL);
+- if (!buf)
+- return -ENOMEM;
+-
+- res = single_open(file, show_stat, NULL);
+- if (!res) {
+- m = file->private_data;
+- m->buf = buf;
+- m->size = ksize(buf);
+- } else
+- kfree(buf);
+- return res;
++ return single_open_size(file, show_stat, NULL, size);
+ }
+
+ static const struct file_operations proc_stat_operations = {
b43-fix-frequency-reported-on-g-phy-with-new-firmware.patch
fs-cifs-fix-regression-in-cifs_create_mf_symlink.patch
cifs-fix-mount-failure-with-broken-pathnames-when-smb3-mount-with-mapchars-option.patch
+blkcg-fix-use-after-free-in-__blkg_release_rcu-by-making-blkcg_gq-refcnt-an-atomic_t.patch
+ext4-fix-buffer-double-free-in-ext4_alloc_branch.patch
+ext4-fix-hole-punching-for-files-with-indirect-blocks.patch
+nick-kvfree-from-apparmor.patch
+fs-seq_file-fallback-to-vmalloc-allocation.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
+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
+mm-page_alloc-fix-cma-area-initialisation-when-pageblock-max_order.patch
+proc-stat-convert-to-single_open_size.patch
+mlx4_core-fix-incorrect-flags1-bitmap-test-in-mlx4_query_func_cap.patch
--- /dev/null
+From b70e19c222a64018d308ebc80333575aff9f4e51 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Fri, 20 Jun 2014 20:22:00 +0100
+Subject: staging: iio/ad7291: fix error code in ad7291_probe()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+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 <dan.carpenter@oracle.com>
+Signed-off-by: Jonathan Cameron <jic23@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /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
+@@ -1355,7 +1355,6 @@ void tracing_start(void)
+
+ arch_spin_unlock(&ftrace_max_lock);
+
+- ftrace_start();
+ out:
+ raw_spin_unlock_irqrestore(&global_trace.start_lock, flags);
+ }
+@@ -1402,7 +1401,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
