]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 7 Sep 2018 10:20:05 +0000 (12:20 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 7 Sep 2018 10:20:05 +0000 (12:20 +0200)
added patches:
9p-fix-multiple-null-pointer-dereferences.patch
9p-net-fix-zero-copy-path-in-the-9p-virtio-transport.patch
9p-virtio-fix-off-by-one-error-in-sg-list-bounds-check.patch
dm-cache-metadata-save-in-core-policy_hint_size-to-on-disk-superblock.patch
drm-i915-userptr-reject-zero-user_size.patch
fs-9p-xattr.c-catch-the-error-of-p9_client_clunk-when-setting-xattr-failed.patch
iio-ad9523-fix-displayed-phase.patch
iio-ad9523-fix-return-value-for-ad952x_store.patch
kthread-tracing-don-t-expose-half-written-comm-when-creating-kthreads.patch
net-6lowpan-fix-reserved-space-for-single-frames.patch
net-9p-client.c-version-pointer-uninitialized.patch
net-9p-trans_fd.c-fix-race-condition-by-flushing-workqueue-before-the-kfree.patch
net-lan78xx-fix-misplaced-tasklet_schedule-call.patch
net-mac802154-tx-expand-tailroom-if-necessary.patch
powerpc-fadump-handle-crash-memory-ranges-array-index-overflow.patch
powerpc-pseries-fix-endianness-while-restoring-of-r3-in-mce-handler.patch
spi-davinci-fix-a-null-pointer-dereference.patch
tracing-blktrace-fix-to-allow-setting-same-value.patch
tracing-do-not-call-start-stop-functions-when-tracing_on-does-not-change.patch
uart-fix-race-between-uart_put_char-and-uart_shutdown.patch
uprobes-use-synchronize_rcu-not-synchronize_sched.patch
vmw_balloon-do-not-use-2mb-without-batching.patch
vmw_balloon-fix-inflation-of-64-bit-gfns.patch
vmw_balloon-fix-vmci-use-when-balloon-built-into-kernel.patch
vmw_balloon-vmci_doorbell_set-does-not-check-status.patch
x86-mm-pat-fix-l1tf-stable-backport-for-cpa-2nd-call.patch

26 files changed:
queue-4.4/9p-fix-multiple-null-pointer-dereferences.patch [new file with mode: 0644]
queue-4.4/9p-net-fix-zero-copy-path-in-the-9p-virtio-transport.patch [new file with mode: 0644]
queue-4.4/9p-virtio-fix-off-by-one-error-in-sg-list-bounds-check.patch [new file with mode: 0644]
queue-4.4/dm-cache-metadata-save-in-core-policy_hint_size-to-on-disk-superblock.patch [new file with mode: 0644]
queue-4.4/drm-i915-userptr-reject-zero-user_size.patch [new file with mode: 0644]
queue-4.4/fs-9p-xattr.c-catch-the-error-of-p9_client_clunk-when-setting-xattr-failed.patch [new file with mode: 0644]
queue-4.4/iio-ad9523-fix-displayed-phase.patch [new file with mode: 0644]
queue-4.4/iio-ad9523-fix-return-value-for-ad952x_store.patch [new file with mode: 0644]
queue-4.4/kthread-tracing-don-t-expose-half-written-comm-when-creating-kthreads.patch [new file with mode: 0644]
queue-4.4/net-6lowpan-fix-reserved-space-for-single-frames.patch [new file with mode: 0644]
queue-4.4/net-9p-client.c-version-pointer-uninitialized.patch [new file with mode: 0644]
queue-4.4/net-9p-trans_fd.c-fix-race-condition-by-flushing-workqueue-before-the-kfree.patch [new file with mode: 0644]
queue-4.4/net-lan78xx-fix-misplaced-tasklet_schedule-call.patch [new file with mode: 0644]
queue-4.4/net-mac802154-tx-expand-tailroom-if-necessary.patch [new file with mode: 0644]
queue-4.4/powerpc-fadump-handle-crash-memory-ranges-array-index-overflow.patch [new file with mode: 0644]
queue-4.4/powerpc-pseries-fix-endianness-while-restoring-of-r3-in-mce-handler.patch [new file with mode: 0644]
queue-4.4/spi-davinci-fix-a-null-pointer-dereference.patch [new file with mode: 0644]
queue-4.4/tracing-blktrace-fix-to-allow-setting-same-value.patch [new file with mode: 0644]
queue-4.4/tracing-do-not-call-start-stop-functions-when-tracing_on-does-not-change.patch [new file with mode: 0644]
queue-4.4/uart-fix-race-between-uart_put_char-and-uart_shutdown.patch [new file with mode: 0644]
queue-4.4/uprobes-use-synchronize_rcu-not-synchronize_sched.patch [new file with mode: 0644]
queue-4.4/vmw_balloon-do-not-use-2mb-without-batching.patch [new file with mode: 0644]
queue-4.4/vmw_balloon-fix-inflation-of-64-bit-gfns.patch [new file with mode: 0644]
queue-4.4/vmw_balloon-fix-vmci-use-when-balloon-built-into-kernel.patch [new file with mode: 0644]
queue-4.4/vmw_balloon-vmci_doorbell_set-does-not-check-status.patch [new file with mode: 0644]
queue-4.4/x86-mm-pat-fix-l1tf-stable-backport-for-cpa-2nd-call.patch [new file with mode: 0644]

diff --git a/queue-4.4/9p-fix-multiple-null-pointer-dereferences.patch b/queue-4.4/9p-fix-multiple-null-pointer-dereferences.patch
new file mode 100644 (file)
index 0000000..d89bed0
--- /dev/null
@@ -0,0 +1,69 @@
+From 10aa14527f458e9867cf3d2cc6b8cb0f6704448b Mon Sep 17 00:00:00 2001
+From: Tomas Bortoli <tomasbortoli@gmail.com>
+Date: Fri, 27 Jul 2018 13:05:58 +0200
+Subject: 9p: fix multiple NULL-pointer-dereferences
+
+From: Tomas Bortoli <tomasbortoli@gmail.com>
+
+commit 10aa14527f458e9867cf3d2cc6b8cb0f6704448b upstream.
+
+Added checks to prevent GPFs from raising.
+
+Link: http://lkml.kernel.org/r/20180727110558.5479-1-tomasbortoli@gmail.com
+Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
+Reported-by: syzbot+1a262da37d3bead15c39@syzkaller.appspotmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/9p/trans_fd.c     |    5 ++++-
+ net/9p/trans_rdma.c   |    3 +++
+ net/9p/trans_virtio.c |    3 +++
+ 3 files changed, 10 insertions(+), 1 deletion(-)
+
+--- a/net/9p/trans_fd.c
++++ b/net/9p/trans_fd.c
+@@ -935,7 +935,7 @@ p9_fd_create_tcp(struct p9_client *clien
+       if (err < 0)
+               return err;
+-      if (valid_ipaddr4(addr) < 0)
++      if (addr == NULL || valid_ipaddr4(addr) < 0)
+               return -EINVAL;
+       csocket = NULL;
+@@ -983,6 +983,9 @@ p9_fd_create_unix(struct p9_client *clie
+       csocket = NULL;
++      if (addr == NULL)
++              return -EINVAL;
++
+       if (strlen(addr) >= UNIX_PATH_MAX) {
+               pr_err("%s (%d): address too long: %s\n",
+                      __func__, task_pid_nr(current), addr);
+--- a/net/9p/trans_rdma.c
++++ b/net/9p/trans_rdma.c
+@@ -644,6 +644,9 @@ rdma_create_trans(struct p9_client *clie
+       struct ib_qp_init_attr qp_attr;
+       struct ib_cq_init_attr cq_attr = {};
++      if (addr == NULL)
++              return -EINVAL;
++
+       /* Parse the transport specific mount options */
+       err = parse_opts(args, &opts);
+       if (err < 0)
+--- a/net/9p/trans_virtio.c
++++ b/net/9p/trans_virtio.c
+@@ -654,6 +654,9 @@ p9_virtio_create(struct p9_client *clien
+       int ret = -ENOENT;
+       int found = 0;
++      if (devname == NULL)
++              return -EINVAL;
++
+       mutex_lock(&virtio_9p_lock);
+       list_for_each_entry(chan, &virtio_chan_list, chan_list) {
+               if (!strncmp(devname, chan->tag, chan->tag_len) &&
diff --git a/queue-4.4/9p-net-fix-zero-copy-path-in-the-9p-virtio-transport.patch b/queue-4.4/9p-net-fix-zero-copy-path-in-the-9p-virtio-transport.patch
new file mode 100644 (file)
index 0000000..f37c6c0
--- /dev/null
@@ -0,0 +1,59 @@
+From d28c756caee6e414d9ba367d0b92da24145af2a8 Mon Sep 17 00:00:00 2001
+From: Chirantan Ekbote <chirantan@chromium.org>
+Date: Mon, 16 Jul 2018 17:35:29 -0700
+Subject: 9p/net: Fix zero-copy path in the 9p virtio transport
+
+From: Chirantan Ekbote <chirantan@chromium.org>
+
+commit d28c756caee6e414d9ba367d0b92da24145af2a8 upstream.
+
+The zero-copy optimization when reading or writing large chunks of data
+is quite useful.  However, the 9p messages created through the zero-copy
+write path have an incorrect message size: it should be the size of the
+header + size of the data being written but instead it's just the size
+of the header.
+
+This only works if the server ignores the size field of the message and
+otherwise breaks the framing of the protocol. Fix this by re-writing the
+message size field with the correct value.
+
+Tested by running `dd if=/dev/zero of=out bs=4k count=1` inside a
+virtio-9p mount.
+
+Link: http://lkml.kernel.org/r/20180717003529.114368-1-chirantan@chromium.org
+Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
+Reviewed-by: Greg Kurz <groug@kaod.org>
+Tested-by: Greg Kurz <groug@kaod.org>
+Cc: Dylan Reid <dgreid@chromium.org>
+Cc: Guenter Roeck <groeck@chromium.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/9p/trans_virtio.c |    7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/net/9p/trans_virtio.c
++++ b/net/9p/trans_virtio.c
+@@ -409,6 +409,7 @@ p9_virtio_zc_request(struct p9_client *c
+       p9_debug(P9_DEBUG_TRANS, "virtio request\n");
+       if (uodata) {
++              __le32 sz;
+               int n = p9_get_mapped_pages(chan, &out_pages, uodata,
+                                           outlen, &offs, &need_drop);
+               if (n < 0)
+@@ -419,6 +420,12 @@ p9_virtio_zc_request(struct p9_client *c
+                       memcpy(&req->tc->sdata[req->tc->size - 4], &v, 4);
+                       outlen = n;
+               }
++              /* The size field of the message must include the length of the
++               * header and the length of the data.  We didn't actually know
++               * the length of the data until this point so add it in now.
++               */
++              sz = cpu_to_le32(req->tc->size + outlen);
++              memcpy(&req->tc->sdata[0], &sz, sizeof(sz));
+       } else if (uidata) {
+               int n = p9_get_mapped_pages(chan, &in_pages, uidata,
+                                           inlen, &offs, &need_drop);
diff --git a/queue-4.4/9p-virtio-fix-off-by-one-error-in-sg-list-bounds-check.patch b/queue-4.4/9p-virtio-fix-off-by-one-error-in-sg-list-bounds-check.patch
new file mode 100644 (file)
index 0000000..8e5ebd5
--- /dev/null
@@ -0,0 +1,44 @@
+From 23cba9cbde0bba05d772b335fe5f66aa82b9ad19 Mon Sep 17 00:00:00 2001
+From: jiangyiwen <jiangyiwen@huawei.com>
+Date: Fri, 3 Aug 2018 12:11:34 +0800
+Subject: 9p/virtio: fix off-by-one error in sg list bounds check
+
+From: jiangyiwen <jiangyiwen@huawei.com>
+
+commit 23cba9cbde0bba05d772b335fe5f66aa82b9ad19 upstream.
+
+Because the value of limit is VIRTQUEUE_NUM, if index is equal to
+limit, it will cause sg array out of bounds, so correct the judgement
+of BUG_ON.
+
+Link: http://lkml.kernel.org/r/5B63D5F6.6080109@huawei.com
+Signed-off-by: Yiwen Jiang <jiangyiwen@huawei.com>
+Reported-By: Dan Carpenter <dan.carpenter@oracle.com>
+Acked-by: Jun Piao <piaojun@huawei.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/9p/trans_virtio.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/9p/trans_virtio.c
++++ b/net/9p/trans_virtio.c
+@@ -192,7 +192,7 @@ static int pack_sg_list(struct scatterli
+               s = rest_of_page(data);
+               if (s > count)
+                       s = count;
+-              BUG_ON(index > limit);
++              BUG_ON(index >= limit);
+               /* Make sure we don't terminate early. */
+               sg_unmark_end(&sg[index]);
+               sg_set_buf(&sg[index++], data, s);
+@@ -237,6 +237,7 @@ pack_sg_list_p(struct scatterlist *sg, i
+               s = PAGE_SIZE - data_off;
+               if (s > count)
+                       s = count;
++              BUG_ON(index >= limit);
+               /* Make sure we don't terminate early. */
+               sg_unmark_end(&sg[index]);
+               sg_set_page(&sg[index++], pdata[i++], s, data_off);
diff --git a/queue-4.4/dm-cache-metadata-save-in-core-policy_hint_size-to-on-disk-superblock.patch b/queue-4.4/dm-cache-metadata-save-in-core-policy_hint_size-to-on-disk-superblock.patch
new file mode 100644 (file)
index 0000000..652c5a1
--- /dev/null
@@ -0,0 +1,53 @@
+From fd2fa95416188a767a63979296fa3e169a9ef5ec Mon Sep 17 00:00:00 2001
+From: Mike Snitzer <snitzer@redhat.com>
+Date: Thu, 2 Aug 2018 16:08:52 -0400
+Subject: dm cache metadata: save in-core policy_hint_size to on-disk superblock
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+commit fd2fa95416188a767a63979296fa3e169a9ef5ec upstream.
+
+policy_hint_size starts as 0 during __write_initial_superblock().  It
+isn't until the policy is loaded that policy_hint_size is set in-core
+(cmd->policy_hint_size).  But it never got recorded in the on-disk
+superblock because __commit_transaction() didn't deal with transfering
+the in-core cmd->policy_hint_size to the on-disk superblock.
+
+The in-core cmd->policy_hint_size gets initialized by metadata_open()'s
+__begin_transaction_flags() which re-reads all superblock fields.
+Because the superblock's policy_hint_size was never properly stored, when
+the cache was created, hints_array_available() would always return false
+when re-activating a previously created cache.  This means
+__load_mappings() always considered the hints invalid and never made use
+of the hints (these hints served to optimize).
+
+Another detremental side-effect of this oversight is the cache_check
+utility would fail with: "invalid hint width: 0"
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-cache-metadata.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/dm-cache-metadata.c
++++ b/drivers/md/dm-cache-metadata.c
+@@ -337,7 +337,7 @@ static int __write_initial_superblock(st
+       disk_super->version = cpu_to_le32(MAX_CACHE_VERSION);
+       memset(disk_super->policy_name, 0, sizeof(disk_super->policy_name));
+       memset(disk_super->policy_version, 0, sizeof(disk_super->policy_version));
+-      disk_super->policy_hint_size = 0;
++      disk_super->policy_hint_size = cpu_to_le32(0);
+       __copy_sm_root(cmd, disk_super);
+@@ -652,6 +652,7 @@ static int __commit_transaction(struct d
+       disk_super->policy_version[0] = cpu_to_le32(cmd->policy_version[0]);
+       disk_super->policy_version[1] = cpu_to_le32(cmd->policy_version[1]);
+       disk_super->policy_version[2] = cpu_to_le32(cmd->policy_version[2]);
++      disk_super->policy_hint_size = cpu_to_le32(cmd->policy_hint_size);
+       disk_super->read_hits = cpu_to_le32(cmd->stats.read_hits);
+       disk_super->read_misses = cpu_to_le32(cmd->stats.read_misses);
diff --git a/queue-4.4/drm-i915-userptr-reject-zero-user_size.patch b/queue-4.4/drm-i915-userptr-reject-zero-user_size.patch
new file mode 100644 (file)
index 0000000..2e2c8a0
--- /dev/null
@@ -0,0 +1,37 @@
+From c11c7bfd213495784b22ef82a69b6489f8d0092f Mon Sep 17 00:00:00 2001
+From: Matthew Auld <matthew.auld@intel.com>
+Date: Wed, 2 May 2018 20:50:21 +0100
+Subject: drm/i915/userptr: reject zero user_size
+
+From: Matthew Auld <matthew.auld@intel.com>
+
+commit c11c7bfd213495784b22ef82a69b6489f8d0092f upstream.
+
+Operating on a zero sized GEM userptr object will lead to explosions.
+
+Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")
+Testcase: igt/gem_userptr_blits/input-checking
+Signed-off-by: Matthew Auld <matthew.auld@intel.com>
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Link: https://patchwork.freedesktop.org/patch/msgid/20180502195021.30900-1-matthew.auld@intel.com
+Cc: Loic <hackurx@opensec.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem_userptr.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
++++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
+@@ -842,6 +842,9 @@ i915_gem_userptr_ioctl(struct drm_device
+                           I915_USERPTR_UNSYNCHRONIZED))
+               return -EINVAL;
++      if (!args->user_size)
++              return -EINVAL;
++
+       if (offset_in_page(args->user_ptr | args->user_size))
+               return -EINVAL;
diff --git a/queue-4.4/fs-9p-xattr.c-catch-the-error-of-p9_client_clunk-when-setting-xattr-failed.patch b/queue-4.4/fs-9p-xattr.c-catch-the-error-of-p9_client_clunk-when-setting-xattr-failed.patch
new file mode 100644 (file)
index 0000000..5149820
--- /dev/null
@@ -0,0 +1,62 @@
+From 3111784bee81591ea2815011688d28b65df03627 Mon Sep 17 00:00:00 2001
+From: piaojun <piaojun@huawei.com>
+Date: Wed, 25 Jul 2018 11:13:16 +0800
+Subject: fs/9p/xattr.c: catch the error of p9_client_clunk when setting xattr failed
+
+From: piaojun <piaojun@huawei.com>
+
+commit 3111784bee81591ea2815011688d28b65df03627 upstream.
+
+In my testing, v9fs_fid_xattr_set will return successfully even if the
+backend ext4 filesystem has no space to store xattr key-value. That will
+cause inconsistent behavior between front end and back end. The reason is
+that lsetxattr will be triggered by p9_client_clunk, and unfortunately we
+did not catch the error. This patch will catch the error to notify upper
+caller.
+
+p9_client_clunk (in 9p)
+  p9_client_rpc(clnt, P9_TCLUNK, "d", fid->fid);
+    v9fs_clunk (in qemu)
+      put_fid
+        free_fid
+          v9fs_xattr_fid_clunk
+            v9fs_co_lsetxattr
+              s->ops->lsetxattr
+                ext4_xattr_user_set (in host ext4 filesystem)
+
+Link: http://lkml.kernel.org/r/5B57EACC.2060900@huawei.com
+Signed-off-by: Jun Piao <piaojun@huawei.com>
+Cc: Eric Van Hensbergen <ericvh@gmail.com>
+Cc: Ron Minnich <rminnich@sandia.gov>
+Cc: Latchesar Ionkov <lucho@ionkov.net>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/9p/xattr.c |    6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/fs/9p/xattr.c
++++ b/fs/9p/xattr.c
+@@ -107,7 +107,7 @@ int v9fs_fid_xattr_set(struct p9_fid *fi
+ {
+       struct kvec kvec = {.iov_base = (void *)value, .iov_len = value_len};
+       struct iov_iter from;
+-      int retval;
++      int retval, err;
+       iov_iter_kvec(&from, WRITE | ITER_KVEC, &kvec, 1, value_len);
+@@ -128,7 +128,9 @@ int v9fs_fid_xattr_set(struct p9_fid *fi
+                        retval);
+       else
+               p9_client_write(fid, 0, &from, &retval);
+-      p9_client_clunk(fid);
++      err = p9_client_clunk(fid);
++      if (!retval && err)
++              retval = err;
+       return retval;
+ }
diff --git a/queue-4.4/iio-ad9523-fix-displayed-phase.patch b/queue-4.4/iio-ad9523-fix-displayed-phase.patch
new file mode 100644 (file)
index 0000000..cbd676c
--- /dev/null
@@ -0,0 +1,36 @@
+From 5a4e33c1c53ae7d4425f7d94e60e4458a37b349e Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Mon, 25 Jun 2018 11:03:07 +0300
+Subject: iio: ad9523: Fix displayed phase
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 5a4e33c1c53ae7d4425f7d94e60e4458a37b349e upstream.
+
+Fix the displayed phase for the ad9523 driver. Currently the most
+significant decimal place is dropped and all other digits are shifted one
+to the left. This is due to a multiplication by 10, which is not necessary,
+so remove it.
+
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
+Fixes: cd1678f9632 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator")
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/frequency/ad9523.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/frequency/ad9523.c
++++ b/drivers/iio/frequency/ad9523.c
+@@ -641,7 +641,7 @@ static int ad9523_read_raw(struct iio_de
+               code = (AD9523_CLK_DIST_DIV_PHASE_REV(ret) * 3141592) /
+                       AD9523_CLK_DIST_DIV_REV(ret);
+               *val = code / 1000000;
+-              *val2 = (code % 1000000) * 10;
++              *val2 = code % 1000000;
+               return IIO_VAL_INT_PLUS_MICRO;
+       default:
+               return -EINVAL;
diff --git a/queue-4.4/iio-ad9523-fix-return-value-for-ad952x_store.patch b/queue-4.4/iio-ad9523-fix-return-value-for-ad952x_store.patch
new file mode 100644 (file)
index 0000000..7f79fc0
--- /dev/null
@@ -0,0 +1,40 @@
+From 9a5094ca29ea9b1da301b31fd377c0c0c4c23034 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Fri, 27 Jul 2018 09:42:45 +0300
+Subject: iio: ad9523: Fix return value for ad952x_store()
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 9a5094ca29ea9b1da301b31fd377c0c0c4c23034 upstream.
+
+A sysfs write callback function needs to either return the number of
+consumed characters or an error.
+
+The ad952x_store() function currently returns 0 if the input value was "0",
+this will signal that no characters have been consumed and the function
+will be called repeatedly in a loop indefinitely. Fix this by returning
+number of supplied characters to indicate that the whole input string has
+been consumed.
+
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
+Fixes: cd1678f96329 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator")
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/frequency/ad9523.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/frequency/ad9523.c
++++ b/drivers/iio/frequency/ad9523.c
+@@ -507,7 +507,7 @@ static ssize_t ad9523_store(struct devic
+               return ret;
+       if (!state)
+-              return 0;
++              return len;
+       mutex_lock(&indio_dev->mlock);
+       switch ((u32)this_attr->address) {
diff --git a/queue-4.4/kthread-tracing-don-t-expose-half-written-comm-when-creating-kthreads.patch b/queue-4.4/kthread-tracing-don-t-expose-half-written-comm-when-creating-kthreads.patch
new file mode 100644 (file)
index 0000000..e0dce4b
--- /dev/null
@@ -0,0 +1,83 @@
+From 3e536e222f2930534c252c1cc7ae799c725c5ff9 Mon Sep 17 00:00:00 2001
+From: Snild Dolkow <snild@sony.com>
+Date: Thu, 26 Jul 2018 09:15:39 +0200
+Subject: kthread, tracing: Don't expose half-written comm when creating kthreads
+
+From: Snild Dolkow <snild@sony.com>
+
+commit 3e536e222f2930534c252c1cc7ae799c725c5ff9 upstream.
+
+There is a window for racing when printing directly to task->comm,
+allowing other threads to see a non-terminated string. The vsnprintf
+function fills the buffer, counts the truncated chars, then finally
+writes the \0 at the end.
+
+       creator                     other
+       vsnprintf:
+         fill (not terminated)
+         count the rest            trace_sched_waking(p):
+         ...                         memcpy(comm, p->comm, TASK_COMM_LEN)
+         write \0
+
+The consequences depend on how 'other' uses the string. In our case,
+it was copied into the tracing system's saved cmdlines, a buffer of
+adjacent TASK_COMM_LEN-byte buffers (note the 'n' where 0 should be):
+
+       crash-arm64> x/1024s savedcmd->saved_cmdlines | grep 'evenk'
+       0xffffffd5b3818640:     "irq/497-pwr_evenkworker/u16:12"
+
+...and a strcpy out of there would cause stack corruption:
+
+       [224761.522292] Kernel panic - not syncing: stack-protector:
+           Kernel stack is corrupted in: ffffff9bf9783c78
+
+       crash-arm64> kbt | grep 'comm\|trace_print_context'
+       #6  0xffffff9bf9783c78 in trace_print_context+0x18c(+396)
+             comm (char [16]) =  "irq/497-pwr_even"
+
+       crash-arm64> rd 0xffffffd4d0e17d14 8
+       ffffffd4d0e17d14:  2f71726900000000 5f7277702d373934   ....irq/497-pwr_
+       ffffffd4d0e17d24:  726f776b6e657665 3a3631752f72656b   evenkworker/u16:
+       ffffffd4d0e17d34:  f9780248ff003231 cede60e0ffffff9b   12..H.x......`..
+       ffffffd4d0e17d44:  cede60c8ffffffd4 00000fffffffffd4   .....`..........
+
+The workaround in e09e28671 (use strlcpy in __trace_find_cmdline) was
+likely needed because of this same bug.
+
+Solved by vsnprintf:ing to a local buffer, then using set_task_comm().
+This way, there won't be a window where comm is not terminated.
+
+Link: http://lkml.kernel.org/r/20180726071539.188015-1-snild@sony.com
+
+Cc: stable@vger.kernel.org
+Fixes: bc0c38d139ec7 ("ftrace: latency tracer infrastructure")
+Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Snild Dolkow <snild@sony.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+[backported to 3.18 / 4.4 by Snild]
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/kthread.c |    8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/kernel/kthread.c
++++ b/kernel/kthread.c
+@@ -313,10 +313,16 @@ struct task_struct *kthread_create_on_no
+       task = create->result;
+       if (!IS_ERR(task)) {
+               static const struct sched_param param = { .sched_priority = 0 };
++              char name[TASK_COMM_LEN];
+               va_list args;
+               va_start(args, namefmt);
+-              vsnprintf(task->comm, sizeof(task->comm), namefmt, args);
++              /*
++               * task is already visible to other tasks, so updating
++               * COMM must be protected.
++               */
++              vsnprintf(name, sizeof(name), namefmt, args);
++              set_task_comm(task, name);
+               va_end(args);
+               /*
+                * root may have changed our (kthreadd's) priority or CPU mask.
diff --git a/queue-4.4/net-6lowpan-fix-reserved-space-for-single-frames.patch b/queue-4.4/net-6lowpan-fix-reserved-space-for-single-frames.patch
new file mode 100644 (file)
index 0000000..4ac5668
--- /dev/null
@@ -0,0 +1,57 @@
+From ac74f87c789af40936a80131c4759f3e72579c3a Mon Sep 17 00:00:00 2001
+From: Alexander Aring <aring@mojatatu.com>
+Date: Sat, 14 Jul 2018 12:52:10 -0400
+Subject: net: 6lowpan: fix reserved space for single frames
+
+From: Alexander Aring <aring@mojatatu.com>
+
+commit ac74f87c789af40936a80131c4759f3e72579c3a upstream.
+
+This patch fixes patch add handling to take care tail and headroom for
+single 6lowpan frames. We need to be sure we have a skb with the right
+head and tailroom for single frames. This patch do it by using
+skb_copy_expand() if head and tailroom is not enough allocated by upper
+layer.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195059
+Reported-by: David Palma <david.palma@ntnu.no>
+Reported-by: Rabi Narayan Sahoo <rabinarayans0828@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Alexander Aring <aring@mojatatu.com>
+Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/ieee802154/6lowpan/tx.c |   21 ++++++++++++++++++---
+ 1 file changed, 18 insertions(+), 3 deletions(-)
+
+--- a/net/ieee802154/6lowpan/tx.c
++++ b/net/ieee802154/6lowpan/tx.c
+@@ -265,9 +265,24 @@ netdev_tx_t lowpan_xmit(struct sk_buff *
+       /* We must take a copy of the skb before we modify/replace the ipv6
+        * header as the header could be used elsewhere
+        */
+-      skb = skb_unshare(skb, GFP_ATOMIC);
+-      if (!skb)
+-              return NET_XMIT_DROP;
++      if (unlikely(skb_headroom(skb) < ldev->needed_headroom ||
++                   skb_tailroom(skb) < ldev->needed_tailroom)) {
++              struct sk_buff *nskb;
++
++              nskb = skb_copy_expand(skb, ldev->needed_headroom,
++                                     ldev->needed_tailroom, GFP_ATOMIC);
++              if (likely(nskb)) {
++                      consume_skb(skb);
++                      skb = nskb;
++              } else {
++                      kfree_skb(skb);
++                      return NET_XMIT_DROP;
++              }
++      } else {
++              skb = skb_unshare(skb, GFP_ATOMIC);
++              if (!skb)
++                      return NET_XMIT_DROP;
++      }
+       ret = lowpan_header(skb, ldev, &dgram_size, &dgram_offset);
+       if (ret < 0) {
diff --git a/queue-4.4/net-9p-client.c-version-pointer-uninitialized.patch b/queue-4.4/net-9p-client.c-version-pointer-uninitialized.patch
new file mode 100644 (file)
index 0000000..2fae030
--- /dev/null
@@ -0,0 +1,43 @@
+From 7913690dcc5e18e235769fd87c34143072f5dbea Mon Sep 17 00:00:00 2001
+From: Tomas Bortoli <tomasbortoli@gmail.com>
+Date: Tue, 10 Jul 2018 00:29:43 +0200
+Subject: net/9p/client.c: version pointer uninitialized
+
+From: Tomas Bortoli <tomasbortoli@gmail.com>
+
+commit 7913690dcc5e18e235769fd87c34143072f5dbea upstream.
+
+The p9_client_version() does not initialize the version pointer. If the
+call to p9pdu_readf() returns an error and version has not been allocated
+in p9pdu_readf(), then the program will jump to the "error" label and will
+try to free the version pointer. If version is not initialized, free()
+will be called with uninitialized, garbage data and will provoke a crash.
+
+Link: http://lkml.kernel.org/r/20180709222943.19503-1-tomasbortoli@gmail.com
+Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
+Reported-by: syzbot+65c6b72f284a39d416b4@syzkaller.appspotmail.com
+Reviewed-by: Jun Piao <piaojun@huawei.com>
+Reviewed-by: Yiwen Jiang <jiangyiwen@huawei.com>
+Cc: Eric Van Hensbergen <ericvh@gmail.com>
+Cc: Ron Minnich <rminnich@sandia.gov>
+Cc: Latchesar Ionkov <lucho@ionkov.net>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/9p/client.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/9p/client.c
++++ b/net/9p/client.c
+@@ -931,7 +931,7 @@ static int p9_client_version(struct p9_c
+ {
+       int err = 0;
+       struct p9_req_t *req;
+-      char *version;
++      char *version = NULL;
+       int msize;
+       p9_debug(P9_DEBUG_9P, ">>> TVERSION msize %d protocol %d\n",
diff --git a/queue-4.4/net-9p-trans_fd.c-fix-race-condition-by-flushing-workqueue-before-the-kfree.patch b/queue-4.4/net-9p-trans_fd.c-fix-race-condition-by-flushing-workqueue-before-the-kfree.patch
new file mode 100644 (file)
index 0000000..b54af0a
--- /dev/null
@@ -0,0 +1,39 @@
+From 430ac66eb4c5b5c4eb846b78ebf65747510b30f1 Mon Sep 17 00:00:00 2001
+From: Tomas Bortoli <tomasbortoli@gmail.com>
+Date: Fri, 20 Jul 2018 11:27:30 +0200
+Subject: net/9p/trans_fd.c: fix race-condition by flushing workqueue before the kfree()
+
+From: Tomas Bortoli <tomasbortoli@gmail.com>
+
+commit 430ac66eb4c5b5c4eb846b78ebf65747510b30f1 upstream.
+
+The patch adds the flush in p9_mux_poll_stop() as it the function used by
+p9_conn_destroy(), in turn called by p9_fd_close() to stop the async
+polling associated with the data regarding the connection.
+
+Link: http://lkml.kernel.org/r/20180720092730.27104-1-tomasbortoli@gmail.com
+Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
+Reported-by: syzbot+39749ed7d9ef6dfb23f6@syzkaller.appspotmail.com
+To: Eric Van Hensbergen <ericvh@gmail.com>
+To: Ron Minnich <rminnich@sandia.gov>
+To: Latchesar Ionkov <lucho@ionkov.net>
+Cc: Yiwen Jiang <jiangyiwen@huwei.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/9p/trans_fd.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/9p/trans_fd.c
++++ b/net/9p/trans_fd.c
+@@ -185,6 +185,8 @@ static void p9_mux_poll_stop(struct p9_c
+       spin_lock_irqsave(&p9_poll_lock, flags);
+       list_del_init(&m->poll_pending_link);
+       spin_unlock_irqrestore(&p9_poll_lock, flags);
++
++      flush_work(&p9_poll_work);
+ }
+ /**
diff --git a/queue-4.4/net-lan78xx-fix-misplaced-tasklet_schedule-call.patch b/queue-4.4/net-lan78xx-fix-misplaced-tasklet_schedule-call.patch
new file mode 100644 (file)
index 0000000..e3e997f
--- /dev/null
@@ -0,0 +1,47 @@
+From ben.hutchings@codethink.co.uk  Fri Sep  7 10:43:25 2018
+From: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Date: Fri, 7 Sep 2018 01:13:40 +0100
+Subject: net: lan78xx: Fix misplaced tasklet_schedule() call
+To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: stable@vger.kernel.org, Stefan Wahren <stefan.wahren@i2se.com>
+Message-ID: <20180907001340.kjnyoby6dwhtdlar@xylophone.i.decadent.org.uk>
+Content-Disposition: inline
+
+From: Ben Hutchings <ben.hutchings@codethink.co.uk>
+
+Commit 136f55f66019 ("net: lan78xx: fix rx handling before first
+packet is send") was not correctly backported to 4.4.  The call to
+tasklet_schedule() belongs in lan78xx_link_reset().
+
+Fixes: d1fc12d8475c ("net: lan78xx: fix rx handling before first packet is send")
+Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+This is for 4.4 only; the backports to other stable branches look OK.
+I didn't test the driver on any branch though.
+
+Ben.
+
+ drivers/net/usb/lan78xx.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/usb/lan78xx.c
++++ b/drivers/net/usb/lan78xx.c
+@@ -902,6 +902,8 @@ static int lan78xx_link_reset(struct lan
+               ret = lan78xx_update_flowcontrol(dev, ecmd.duplex, ladv, radv);
+               netif_carrier_on(dev->net);
++
++              tasklet_schedule(&dev->bh);
+       }
+       return ret;
+@@ -1361,8 +1363,6 @@ static void lan78xx_init_mac_address(str
+                       netif_dbg(dev, ifup, dev->net,
+                                 "MAC address set to random addr");
+               }
+-
+-              tasklet_schedule(&dev->bh);
+       }
+       ret = lan78xx_write_reg(dev, MAF_LO(0), addr_lo);
diff --git a/queue-4.4/net-mac802154-tx-expand-tailroom-if-necessary.patch b/queue-4.4/net-mac802154-tx-expand-tailroom-if-necessary.patch
new file mode 100644 (file)
index 0000000..1d55dee
--- /dev/null
@@ -0,0 +1,48 @@
+From f9c52831133050c6b82aa8b6831c92da2bbf2a0b Mon Sep 17 00:00:00 2001
+From: Alexander Aring <aring@mojatatu.com>
+Date: Mon, 2 Jul 2018 16:32:03 -0400
+Subject: net: mac802154: tx: expand tailroom if necessary
+
+From: Alexander Aring <aring@mojatatu.com>
+
+commit f9c52831133050c6b82aa8b6831c92da2bbf2a0b upstream.
+
+This patch is necessary if case of AF_PACKET or other socket interface
+which I am aware of it and didn't allocated the necessary room.
+
+Reported-by: David Palma <david.palma@ntnu.no>
+Reported-by: Rabi Narayan Sahoo <rabinarayans0828@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Alexander Aring <aring@mojatatu.com>
+Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac802154/tx.c |   15 ++++++++++++++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+--- a/net/mac802154/tx.c
++++ b/net/mac802154/tx.c
+@@ -72,8 +72,21 @@ ieee802154_tx(struct ieee802154_local *l
+       int ret;
+       if (!(local->hw.flags & IEEE802154_HW_TX_OMIT_CKSUM)) {
+-              u16 crc = crc_ccitt(0, skb->data, skb->len);
++              struct sk_buff *nskb;
++              u16 crc;
++              if (unlikely(skb_tailroom(skb) < IEEE802154_FCS_LEN)) {
++                      nskb = skb_copy_expand(skb, 0, IEEE802154_FCS_LEN,
++                                             GFP_ATOMIC);
++                      if (likely(nskb)) {
++                              consume_skb(skb);
++                              skb = nskb;
++                      } else {
++                              goto err_tx;
++                      }
++              }
++
++              crc = crc_ccitt(0, skb->data, skb->len);
+               put_unaligned_le16(crc, skb_put(skb, 2));
+       }
diff --git a/queue-4.4/powerpc-fadump-handle-crash-memory-ranges-array-index-overflow.patch b/queue-4.4/powerpc-fadump-handle-crash-memory-ranges-array-index-overflow.patch
new file mode 100644 (file)
index 0000000..6e0c02c
--- /dev/null
@@ -0,0 +1,253 @@
+From 1bd6a1c4b80a28d975287630644e6b47d0f977a5 Mon Sep 17 00:00:00 2001
+From: Hari Bathini <hbathini@linux.ibm.com>
+Date: Tue, 7 Aug 2018 02:12:45 +0530
+Subject: powerpc/fadump: handle crash memory ranges array index overflow
+
+From: Hari Bathini <hbathini@linux.ibm.com>
+
+commit 1bd6a1c4b80a28d975287630644e6b47d0f977a5 upstream.
+
+Crash memory ranges is an array of memory ranges of the crashing kernel
+to be exported as a dump via /proc/vmcore file. The size of the array
+is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases
+where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS
+value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since
+commit 142b45a72e22 ("memblock: Add array resizing support").
+
+On large memory systems with a few DLPAR operations, the memblock memory
+regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such
+systems, registering fadump results in crash or other system failures
+like below:
+
+  task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000
+  NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180
+  REGS: c00000000b73b570 TRAP: 0300   Tainted: G          L   X  (4.4.140+)
+  MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 22004484  XER: 20000000
+  CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0
+  ...
+  NIP [c000000000047df4] smp_send_reschedule+0x24/0x80
+  LR [c0000000000f9e58] resched_curr+0x138/0x160
+  Call Trace:
+    resched_curr+0x138/0x160 (unreliable)
+    check_preempt_curr+0xc8/0xf0
+    ttwu_do_wakeup+0x38/0x150
+    try_to_wake_up+0x224/0x4d0
+    __wake_up_common+0x94/0x100
+    ep_poll_callback+0xac/0x1c0
+    __wake_up_common+0x94/0x100
+    __wake_up_sync_key+0x70/0xa0
+    sock_def_readable+0x58/0xa0
+    unix_stream_sendmsg+0x2dc/0x4c0
+    sock_sendmsg+0x68/0xa0
+    ___sys_sendmsg+0x2cc/0x2e0
+    __sys_sendmsg+0x5c/0xc0
+    SyS_socketcall+0x36c/0x3f0
+    system_call+0x3c/0x100
+
+as array index overflow is not checked for while setting up crash memory
+ranges causing memory corruption. To resolve this issue, dynamically
+allocate memory for crash memory ranges and resize it incrementally,
+in units of pagesize, on hitting array size limit.
+
+Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.")
+Cc: stable@vger.kernel.org # v3.4+
+Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
+Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
+[mpe: Just use PAGE_SIZE directly, fixup variable placement]
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/include/asm/fadump.h |    3 -
+ arch/powerpc/kernel/fadump.c      |   91 ++++++++++++++++++++++++++++++++------
+ 2 files changed, 77 insertions(+), 17 deletions(-)
+
+--- a/arch/powerpc/include/asm/fadump.h
++++ b/arch/powerpc/include/asm/fadump.h
+@@ -194,9 +194,6 @@ struct fadump_crash_info_header {
+       struct cpumask  cpu_online_mask;
+ };
+-/* Crash memory ranges */
+-#define INIT_CRASHMEM_RANGES  (INIT_MEMBLOCK_REGIONS + 2)
+-
+ struct fad_crash_memory_ranges {
+       unsigned long long      base;
+       unsigned long long      size;
+--- a/arch/powerpc/kernel/fadump.c
++++ b/arch/powerpc/kernel/fadump.c
+@@ -48,8 +48,10 @@ static struct fadump_mem_struct fdm;
+ static const struct fadump_mem_struct *fdm_active;
+ static DEFINE_MUTEX(fadump_mutex);
+-struct fad_crash_memory_ranges crash_memory_ranges[INIT_CRASHMEM_RANGES];
++struct fad_crash_memory_ranges *crash_memory_ranges;
++int crash_memory_ranges_size;
+ int crash_mem_ranges;
++int max_crash_mem_ranges;
+ /* Scan the Firmware Assisted dump configuration details. */
+ int __init early_init_dt_scan_fw_dump(unsigned long node,
+@@ -726,38 +728,88 @@ static int __init process_fadump(const s
+       return 0;
+ }
+-static inline void fadump_add_crash_memory(unsigned long long base,
+-                                      unsigned long long end)
++static void free_crash_memory_ranges(void)
++{
++      kfree(crash_memory_ranges);
++      crash_memory_ranges = NULL;
++      crash_memory_ranges_size = 0;
++      max_crash_mem_ranges = 0;
++}
++
++/*
++ * Allocate or reallocate crash memory ranges array in incremental units
++ * of PAGE_SIZE.
++ */
++static int allocate_crash_memory_ranges(void)
++{
++      struct fad_crash_memory_ranges *new_array;
++      u64 new_size;
++
++      new_size = crash_memory_ranges_size + PAGE_SIZE;
++      pr_debug("Allocating %llu bytes of memory for crash memory ranges\n",
++               new_size);
++
++      new_array = krealloc(crash_memory_ranges, new_size, GFP_KERNEL);
++      if (new_array == NULL) {
++              pr_err("Insufficient memory for setting up crash memory ranges\n");
++              free_crash_memory_ranges();
++              return -ENOMEM;
++      }
++
++      crash_memory_ranges = new_array;
++      crash_memory_ranges_size = new_size;
++      max_crash_mem_ranges = (new_size /
++                              sizeof(struct fad_crash_memory_ranges));
++      return 0;
++}
++
++static inline int fadump_add_crash_memory(unsigned long long base,
++                                        unsigned long long end)
+ {
+       if (base == end)
+-              return;
++              return 0;
++
++      if (crash_mem_ranges == max_crash_mem_ranges) {
++              int ret;
++
++              ret = allocate_crash_memory_ranges();
++              if (ret)
++                      return ret;
++      }
+       pr_debug("crash_memory_range[%d] [%#016llx-%#016llx], %#llx bytes\n",
+               crash_mem_ranges, base, end - 1, (end - base));
+       crash_memory_ranges[crash_mem_ranges].base = base;
+       crash_memory_ranges[crash_mem_ranges].size = end - base;
+       crash_mem_ranges++;
++      return 0;
+ }
+-static void fadump_exclude_reserved_area(unsigned long long start,
++static int fadump_exclude_reserved_area(unsigned long long start,
+                                       unsigned long long end)
+ {
+       unsigned long long ra_start, ra_end;
++      int ret = 0;
+       ra_start = fw_dump.reserve_dump_area_start;
+       ra_end = ra_start + fw_dump.reserve_dump_area_size;
+       if ((ra_start < end) && (ra_end > start)) {
+               if ((start < ra_start) && (end > ra_end)) {
+-                      fadump_add_crash_memory(start, ra_start);
+-                      fadump_add_crash_memory(ra_end, end);
++                      ret = fadump_add_crash_memory(start, ra_start);
++                      if (ret)
++                              return ret;
++
++                      ret = fadump_add_crash_memory(ra_end, end);
+               } else if (start < ra_start) {
+-                      fadump_add_crash_memory(start, ra_start);
++                      ret = fadump_add_crash_memory(start, ra_start);
+               } else if (ra_end < end) {
+-                      fadump_add_crash_memory(ra_end, end);
++                      ret = fadump_add_crash_memory(ra_end, end);
+               }
+       } else
+-              fadump_add_crash_memory(start, end);
++              ret = fadump_add_crash_memory(start, end);
++
++      return ret;
+ }
+ static int fadump_init_elfcore_header(char *bufp)
+@@ -793,10 +845,11 @@ static int fadump_init_elfcore_header(ch
+  * Traverse through memblock structure and setup crash memory ranges. These
+  * ranges will be used create PT_LOAD program headers in elfcore header.
+  */
+-static void fadump_setup_crash_memory_ranges(void)
++static int fadump_setup_crash_memory_ranges(void)
+ {
+       struct memblock_region *reg;
+       unsigned long long start, end;
++      int ret;
+       pr_debug("Setup crash memory ranges.\n");
+       crash_mem_ranges = 0;
+@@ -807,7 +860,9 @@ static void fadump_setup_crash_memory_ra
+        * specified during fadump registration. We need to create a separate
+        * program header for this chunk with the correct offset.
+        */
+-      fadump_add_crash_memory(RMA_START, fw_dump.boot_memory_size);
++      ret = fadump_add_crash_memory(RMA_START, fw_dump.boot_memory_size);
++      if (ret)
++              return ret;
+       for_each_memblock(memory, reg) {
+               start = (unsigned long long)reg->base;
+@@ -816,8 +871,12 @@ static void fadump_setup_crash_memory_ra
+                       start = fw_dump.boot_memory_size;
+               /* add this range excluding the reserved dump area. */
+-              fadump_exclude_reserved_area(start, end);
++              ret = fadump_exclude_reserved_area(start, end);
++              if (ret)
++                      return ret;
+       }
++
++      return 0;
+ }
+ /*
+@@ -941,6 +1000,7 @@ static void register_fadump(void)
+ {
+       unsigned long addr;
+       void *vaddr;
++      int ret;
+       /*
+        * If no memory is reserved then we can not register for firmware-
+@@ -949,7 +1009,9 @@ static void register_fadump(void)
+       if (!fw_dump.reserve_dump_area_size)
+               return;
+-      fadump_setup_crash_memory_ranges();
++      ret = fadump_setup_crash_memory_ranges();
++      if (ret)
++              return ret;
+       addr = be64_to_cpu(fdm.rmr_region.destination_address) + be64_to_cpu(fdm.rmr_region.source_len);
+       /* Initialize fadump crash info header. */
+@@ -1028,6 +1090,7 @@ void fadump_cleanup(void)
+       } else if (fw_dump.dump_registered) {
+               /* Un-register Firmware-assisted dump if it was registered. */
+               fadump_unregister_dump(&fdm);
++              free_crash_memory_ranges();
+       }
+ }
diff --git a/queue-4.4/powerpc-pseries-fix-endianness-while-restoring-of-r3-in-mce-handler.patch b/queue-4.4/powerpc-pseries-fix-endianness-while-restoring-of-r3-in-mce-handler.patch
new file mode 100644 (file)
index 0000000..73b7d71
--- /dev/null
@@ -0,0 +1,71 @@
+From cd813e1cd7122f2c261dce5b54d1e0c97f80e1a5 Mon Sep 17 00:00:00 2001
+From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
+Date: Tue, 7 Aug 2018 19:46:46 +0530
+Subject: powerpc/pseries: Fix endianness while restoring of r3 in MCE handler.
+
+From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
+
+commit cd813e1cd7122f2c261dce5b54d1e0c97f80e1a5 upstream.
+
+During Machine Check interrupt on pseries platform, register r3 points
+RTAS extended event log passed by hypervisor. Since hypervisor uses r3
+to pass pointer to rtas log, it stores the original r3 value at the
+start of the memory (first 8 bytes) pointed by r3. Since hypervisor
+stores this info and rtas log is in BE format, linux should make
+sure to restore r3 value in correct endian format.
+
+Without this patch when MCE handler, after recovery, returns to code that
+that caused the MCE may end up with Data SLB access interrupt for invalid
+address followed by kernel panic or hang.
+
+  Severe Machine check interrupt [Recovered]
+    NIP [d00000000ca301b8]: init_module+0x1b8/0x338 [bork_kernel]
+    Initiator: CPU
+    Error type: SLB [Multihit]
+      Effective address: d00000000ca70000
+  cpu 0xa: Vector: 380 (Data SLB Access) at [c0000000fc7775b0]
+      pc: c0000000009694c0: vsnprintf+0x80/0x480
+      lr: c0000000009698e0: vscnprintf+0x20/0x60
+      sp: c0000000fc777830
+     msr: 8000000002009033
+     dar: a803a30c000000d0
+    current = 0xc00000000bc9ef00
+    paca    = 0xc00000001eca5c00        softe: 3        irq_happened: 0x01
+      pid   = 8860, comm = insmod
+  vscnprintf+0x20/0x60
+  vprintk_emit+0xb4/0x4b0
+  vprintk_func+0x5c/0xd0
+  printk+0x38/0x4c
+  init_module+0x1c0/0x338 [bork_kernel]
+  do_one_initcall+0x54/0x230
+  do_init_module+0x8c/0x248
+  load_module+0x12b8/0x15b0
+  sys_finit_module+0xa8/0x110
+  system_call+0x58/0x6c
+  --- Exception: c00 (System Call) at 00007fff8bda0644
+  SP (7fffdfbfe980) is in userspace
+
+This patch fixes this issue.
+
+Fixes: a08a53ea4c97 ("powerpc/le: Enable RTAS events support")
+Cc: stable@vger.kernel.org # v3.15+
+Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
+Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/pseries/ras.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/powerpc/platforms/pseries/ras.c
++++ b/arch/powerpc/platforms/pseries/ras.c
+@@ -300,7 +300,7 @@ static struct rtas_error_log *fwnmi_get_
+       }
+       savep = __va(regs->gpr[3]);
+-      regs->gpr[3] = savep[0];        /* restore original r3 */
++      regs->gpr[3] = be64_to_cpu(savep[0]);   /* restore original r3 */
+       /* If it isn't an extended log we can use the per cpu 64bit buffer */
+       h = (struct rtas_error_log *)&savep[1];
diff --git a/queue-4.4/spi-davinci-fix-a-null-pointer-dereference.patch b/queue-4.4/spi-davinci-fix-a-null-pointer-dereference.patch
new file mode 100644 (file)
index 0000000..69eec4f
--- /dev/null
@@ -0,0 +1,32 @@
+From 563a53f3906a6b43692498e5b3ae891fac93a4af Mon Sep 17 00:00:00 2001
+From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Date: Fri, 10 Aug 2018 11:13:52 +0200
+Subject: spi: davinci: fix a NULL pointer dereference
+
+From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+
+commit 563a53f3906a6b43692498e5b3ae891fac93a4af upstream.
+
+On non-OF systems spi->controlled_data may be NULL. This causes a NULL
+pointer derefence on dm365-evm.
+
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi-davinci.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/spi/spi-davinci.c
++++ b/drivers/spi/spi-davinci.c
+@@ -220,7 +220,7 @@ static void davinci_spi_chipselect(struc
+       pdata = &dspi->pdata;
+       /* program delay transfers if tx_delay is non zero */
+-      if (spicfg->wdelay)
++      if (spicfg && spicfg->wdelay)
+               spidat1 |= SPIDAT1_WDEL;
+       /*
diff --git a/queue-4.4/tracing-blktrace-fix-to-allow-setting-same-value.patch b/queue-4.4/tracing-blktrace-fix-to-allow-setting-same-value.patch
new file mode 100644 (file)
index 0000000..c6a9027
--- /dev/null
@@ -0,0 +1,63 @@
+From 757d9140072054528b13bbe291583d9823cde195 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Thu, 16 Aug 2018 16:08:37 -0400
+Subject: tracing/blktrace: Fix to allow setting same value
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 757d9140072054528b13bbe291583d9823cde195 upstream.
+
+Masami Hiramatsu reported:
+
+  Current trace-enable attribute in sysfs returns an error
+  if user writes the same setting value as current one,
+  e.g.
+
+    # cat /sys/block/sda/trace/enable
+    0
+    # echo 0 > /sys/block/sda/trace/enable
+    bash: echo: write error: Invalid argument
+    # echo 1 > /sys/block/sda/trace/enable
+    # echo 1 > /sys/block/sda/trace/enable
+    bash: echo: write error: Device or resource busy
+
+  But this is not a preferred behavior, it should ignore
+  if new setting is same as current one. This fixes the
+  problem as below.
+
+    # cat /sys/block/sda/trace/enable
+    0
+    # echo 0 > /sys/block/sda/trace/enable
+    # echo 1 > /sys/block/sda/trace/enable
+    # echo 1 > /sys/block/sda/trace/enable
+
+Link: http://lkml.kernel.org/r/20180816103802.08678002@gandalf.local.home
+
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Jens Axboe <axboe@kernel.dk>
+Cc: linux-block@vger.kernel.org
+Cc: stable@vger.kernel.org
+Fixes: cd649b8bb830d ("blktrace: remove sysfs_blk_trace_enable_show/store()")
+Reported-by: Masami Hiramatsu <mhiramat@kernel.org>
+Tested-by: Masami Hiramatsu <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/blktrace.c |    4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/kernel/trace/blktrace.c
++++ b/kernel/trace/blktrace.c
+@@ -1716,6 +1716,10 @@ static ssize_t sysfs_blk_trace_attr_stor
+       mutex_lock(&bdev->bd_mutex);
+       if (attr == &dev_attr_enable) {
++              if (!!value == !!q->blk_trace) {
++                      ret = 0;
++                      goto out_unlock_bdev;
++              }
+               if (value)
+                       ret = blk_trace_setup_queue(q, bdev);
+               else
diff --git a/queue-4.4/tracing-do-not-call-start-stop-functions-when-tracing_on-does-not-change.patch b/queue-4.4/tracing-do-not-call-start-stop-functions-when-tracing_on-does-not-change.patch
new file mode 100644 (file)
index 0000000..f177699
--- /dev/null
@@ -0,0 +1,41 @@
+From f143641bfef9a4a60c57af30de26c63057e7e695 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Wed, 1 Aug 2018 15:40:57 -0400
+Subject: tracing: Do not call start/stop() functions when tracing_on does not change
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit f143641bfef9a4a60c57af30de26c63057e7e695 upstream.
+
+Currently, when one echo's in 1 into tracing_on, the current tracer's
+"start()" function is executed, even if tracing_on was already one. This can
+lead to strange side effects. One being that if the hwlat tracer is enabled,
+and someone does "echo 1 > tracing_on" into tracing_on, the hwlat tracer's
+start() function is called again which will recreate another kernel thread,
+and make it unable to remove the old one.
+
+Link: http://lkml.kernel.org/r/1533120354-22923-1-git-send-email-erica.bugden@linutronix.de
+
+Cc: stable@vger.kernel.org
+Fixes: 2df8f8a6a897e ("tracing: Fix regression with irqsoff tracer and tracing_on file")
+Reported-by: Erica Bugden <erica.bugden@linutronix.de>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace.c |    4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -6496,7 +6496,9 @@ rb_simple_write(struct file *filp, const
+       if (buffer) {
+               mutex_lock(&trace_types_lock);
+-              if (val) {
++              if (!!val == tracer_tracing_is_on(tr)) {
++                      val = 0; /* do nothing */
++              } else if (val) {
+                       tracer_tracing_on(tr);
+                       if (tr->current_trace->start)
+                               tr->current_trace->start(tr);
diff --git a/queue-4.4/uart-fix-race-between-uart_put_char-and-uart_shutdown.patch b/queue-4.4/uart-fix-race-between-uart_put_char-and-uart_shutdown.patch
new file mode 100644 (file)
index 0000000..fee4530
--- /dev/null
@@ -0,0 +1,186 @@
+From a5ba1d95e46ecaea638ddd7cd144107c783acb5d Mon Sep 17 00:00:00 2001
+From: Tycho Andersen <tycho@tycho.ws>
+Date: Fri, 6 Jul 2018 10:24:57 -0600
+Subject: uart: fix race between uart_put_char() and uart_shutdown()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Tycho Andersen <tycho@tycho.ws>
+
+commit a5ba1d95e46ecaea638ddd7cd144107c783acb5d upstream.
+
+We have reports of the following crash:
+
+    PID: 7 TASK: ffff88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0"
+    #0 [ffff88085c6db710] machine_kexec at ffffffff81046239
+    #1 [ffff88085c6db760] crash_kexec at ffffffff810fc248
+    #2 [ffff88085c6db830] oops_end at ffffffff81008ae7
+    #3 [ffff88085c6db860] no_context at ffffffff81050b8f
+    #4 [ffff88085c6db8b0] __bad_area_nosemaphore at ffffffff81050d75
+    #5 [ffff88085c6db900] bad_area_nosemaphore at ffffffff81050e83
+    #6 [ffff88085c6db910] __do_page_fault at ffffffff8105132e
+    #7 [ffff88085c6db9b0] do_page_fault at ffffffff8105152c
+    #8 [ffff88085c6db9c0] page_fault at ffffffff81a3f122
+    [exception RIP: uart_put_char+149]
+    RIP: ffffffff814b67b5 RSP: ffff88085c6dba78 RFLAGS: 00010006
+    RAX: 0000000000000292 RBX: ffffffff827c5120 RCX: 0000000000000081
+    RDX: 0000000000000000 RSI: 000000000000005f RDI: ffffffff827c5120
+    RBP: ffff88085c6dba98 R8: 000000000000012c R9: ffffffff822ea320
+    R10: ffff88085fe4db04 R11: 0000000000000001 R12: ffff881059f9c000
+    R13: 0000000000000001 R14: 000000000000005f R15: 0000000000000fba
+    ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
+    #9 [ffff88085c6dbaa0] tty_put_char at ffffffff81497544
+    #10 [ffff88085c6dbac0] do_output_char at ffffffff8149c91c
+    #11 [ffff88085c6dbae0] __process_echoes at ffffffff8149cb8b
+    #12 [ffff88085c6dbb30] commit_echoes at ffffffff8149cdc2
+    #13 [ffff88085c6dbb60] n_tty_receive_buf_fast at ffffffff8149e49b
+    #14 [ffff88085c6dbbc0] __receive_buf at ffffffff8149ef5a
+    #15 [ffff88085c6dbc20] n_tty_receive_buf_common at ffffffff8149f016
+    #16 [ffff88085c6dbca0] n_tty_receive_buf2 at ffffffff8149f194
+    #17 [ffff88085c6dbcb0] flush_to_ldisc at ffffffff814a238a
+    #18 [ffff88085c6dbd50] process_one_work at ffffffff81090be2
+    #19 [ffff88085c6dbe20] worker_thread at ffffffff81091b4d
+    #20 [ffff88085c6dbeb0] kthread at ffffffff81096384
+    #21 [ffff88085c6dbf50] ret_from_fork at ffffffff81a3d69f​
+
+after slogging through some dissasembly:
+
+ffffffff814b6720 <uart_put_char>:
+ffffffff814b6720:      55                      push   %rbp
+ffffffff814b6721:      48 89 e5                mov    %rsp,%rbp
+ffffffff814b6724:      48 83 ec 20             sub    $0x20,%rsp
+ffffffff814b6728:      48 89 1c 24             mov    %rbx,(%rsp)
+ffffffff814b672c:      4c 89 64 24 08          mov    %r12,0x8(%rsp)
+ffffffff814b6731:      4c 89 6c 24 10          mov    %r13,0x10(%rsp)
+ffffffff814b6736:      4c 89 74 24 18          mov    %r14,0x18(%rsp)
+ffffffff814b673b:      e8 b0 8e 58 00          callq  ffffffff81a3f5f0 <mcount>
+ffffffff814b6740:      4c 8b a7 88 02 00 00    mov    0x288(%rdi),%r12
+ffffffff814b6747:      45 31 ed                xor    %r13d,%r13d
+ffffffff814b674a:      41 89 f6                mov    %esi,%r14d
+ffffffff814b674d:      49 83 bc 24 70 01 00    cmpq   $0x0,0x170(%r12)
+ffffffff814b6754:      00 00
+ffffffff814b6756:      49 8b 9c 24 80 01 00    mov    0x180(%r12),%rbx
+ffffffff814b675d:      00
+ffffffff814b675e:      74 2f                   je     ffffffff814b678f <uart_put_char+0x6f>
+ffffffff814b6760:      48 89 df                mov    %rbx,%rdi
+ffffffff814b6763:      e8 a8 67 58 00          callq  ffffffff81a3cf10 <_raw_spin_lock_irqsave>
+ffffffff814b6768:      41 8b 8c 24 78 01 00    mov    0x178(%r12),%ecx
+ffffffff814b676f:      00
+ffffffff814b6770:      89 ca                   mov    %ecx,%edx
+ffffffff814b6772:      f7 d2                   not    %edx
+ffffffff814b6774:      41 03 94 24 7c 01 00    add    0x17c(%r12),%edx
+ffffffff814b677b:      00
+ffffffff814b677c:      81 e2 ff 0f 00 00       and    $0xfff,%edx
+ffffffff814b6782:      75 23                   jne    ffffffff814b67a7 <uart_put_char+0x87>
+ffffffff814b6784:      48 89 c6                mov    %rax,%rsi
+ffffffff814b6787:      48 89 df                mov    %rbx,%rdi
+ffffffff814b678a:      e8 e1 64 58 00          callq  ffffffff81a3cc70 <_raw_spin_unlock_irqrestore>
+ffffffff814b678f:      44 89 e8                mov    %r13d,%eax
+ffffffff814b6792:      48 8b 1c 24             mov    (%rsp),%rbx
+ffffffff814b6796:      4c 8b 64 24 08          mov    0x8(%rsp),%r12
+ffffffff814b679b:      4c 8b 6c 24 10          mov    0x10(%rsp),%r13
+ffffffff814b67a0:      4c 8b 74 24 18          mov    0x18(%rsp),%r14
+ffffffff814b67a5:      c9                      leaveq
+ffffffff814b67a6:      c3                      retq
+ffffffff814b67a7:      49 8b 94 24 70 01 00    mov    0x170(%r12),%rdx
+ffffffff814b67ae:      00
+ffffffff814b67af:      48 63 c9                movslq %ecx,%rcx
+ffffffff814b67b2:      41 b5 01                mov    $0x1,%r13b
+ffffffff814b67b5:      44 88 34 0a             mov    %r14b,(%rdx,%rcx,1)
+ffffffff814b67b9:      41 8b 94 24 78 01 00    mov    0x178(%r12),%edx
+ffffffff814b67c0:      00
+ffffffff814b67c1:      83 c2 01                add    $0x1,%edx
+ffffffff814b67c4:      81 e2 ff 0f 00 00       and    $0xfff,%edx
+ffffffff814b67ca:      41 89 94 24 78 01 00    mov    %edx,0x178(%r12)
+ffffffff814b67d1:      00
+ffffffff814b67d2:      eb b0                   jmp    ffffffff814b6784 <uart_put_char+0x64>
+ffffffff814b67d4:      66 66 66 2e 0f 1f 84    data32 data32 nopw %cs:0x0(%rax,%rax,1)
+ffffffff814b67db:      00 00 00 00 00
+
+for our build, this is crashing at:
+
+    circ->buf[circ->head] = c;
+
+Looking in uart_port_startup(), it seems that circ->buf (state->xmit.buf)
+protected by the "per-port mutex", which based on uart_port_check() is
+state->port.mutex. Indeed, the lock acquired in uart_put_char() is
+uport->lock, i.e. not the same lock.
+
+Anyway, since the lock is not acquired, if uart_shutdown() is called, the
+last chunk of that function may release state->xmit.buf before its assigned
+to null, and cause the race above.
+
+To fix it, let's lock uport->lock when allocating/deallocating
+state->xmit.buf in addition to the per-port mutex.
+
+v2: switch to locking uport->lock on allocation/deallocation instead of
+    locking the per-port mutex in uart_put_char. Note that since
+    uport->lock is a spin lock, we have to switch the allocation to
+    GFP_ATOMIC.
+v3: move the allocation outside the lock, so we can switch back to
+    GFP_KERNEL
+
+Signed-off-by: Tycho Andersen <tycho@tycho.ws>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/serial_core.c |   17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+--- a/drivers/tty/serial/serial_core.c
++++ b/drivers/tty/serial/serial_core.c
+@@ -136,6 +136,7 @@ static int uart_port_startup(struct tty_
+ {
+       struct uart_port *uport = state->uart_port;
+       unsigned long page;
++      unsigned long flags = 0;
+       int retval = 0;
+       if (uport->type == PORT_UNKNOWN)
+@@ -150,15 +151,18 @@ static int uart_port_startup(struct tty_
+        * Initialise and allocate the transmit and temporary
+        * buffer.
+        */
+-      if (!state->xmit.buf) {
+-              /* This is protected by the per port mutex */
+-              page = get_zeroed_page(GFP_KERNEL);
+-              if (!page)
+-                      return -ENOMEM;
++      page = get_zeroed_page(GFP_KERNEL);
++      if (!page)
++              return -ENOMEM;
++      uart_port_lock(state, flags);
++      if (!state->xmit.buf) {
+               state->xmit.buf = (unsigned char *) page;
+               uart_circ_clear(&state->xmit);
++      } else {
++              free_page(page);
+       }
++      uart_port_unlock(uport, flags);
+       retval = uport->ops->startup(uport);
+       if (retval == 0) {
+@@ -226,6 +230,7 @@ static void uart_shutdown(struct tty_str
+ {
+       struct uart_port *uport = state->uart_port;
+       struct tty_port *port = &state->port;
++      unsigned long flags = 0;
+       /*
+        * Set the TTY IO error marker
+@@ -256,10 +261,12 @@ static void uart_shutdown(struct tty_str
+       /*
+        * Free the transmit buffer page.
+        */
++      uart_port_lock(state, flags);
+       if (state->xmit.buf) {
+               free_page((unsigned long)state->xmit.buf);
+               state->xmit.buf = NULL;
+       }
++      uart_port_unlock(uport, flags);
+ }
+ /**
diff --git a/queue-4.4/uprobes-use-synchronize_rcu-not-synchronize_sched.patch b/queue-4.4/uprobes-use-synchronize_rcu-not-synchronize_sched.patch
new file mode 100644 (file)
index 0000000..8a71382
--- /dev/null
@@ -0,0 +1,39 @@
+From 016f8ffc48cb01d1e7701649c728c5d2e737d295 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Thu, 9 Aug 2018 15:37:59 -0400
+Subject: uprobes: Use synchronize_rcu() not synchronize_sched()
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 016f8ffc48cb01d1e7701649c728c5d2e737d295 upstream.
+
+While debugging another bug, I was looking at all the synchronize*()
+functions being used in kernel/trace, and noticed that trace_uprobes was
+using synchronize_sched(), with a comment to synchronize with
+{u,ret}_probe_trace_func(). When looking at those functions, the data is
+protected with "rcu_read_lock()" and not with "rcu_read_lock_sched()". This
+is using the wrong synchronize_*() function.
+
+Link: http://lkml.kernel.org/r/20180809160553.469e1e32@gandalf.local.home
+
+Cc: stable@vger.kernel.org
+Fixes: 70ed91c6ec7f8 ("tracing/uprobes: Support ftrace_event_file base multibuffer")
+Acked-by: Oleg Nesterov <oleg@redhat.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace_uprobe.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_uprobe.c
++++ b/kernel/trace/trace_uprobe.c
+@@ -969,7 +969,7 @@ probe_event_disable(struct trace_uprobe
+               list_del_rcu(&link->list);
+               /* synchronize with u{,ret}probe_trace_func */
+-              synchronize_sched();
++              synchronize_rcu();
+               kfree(link);
+               if (!list_empty(&tu->tp.files))
diff --git a/queue-4.4/vmw_balloon-do-not-use-2mb-without-batching.patch b/queue-4.4/vmw_balloon-do-not-use-2mb-without-batching.patch
new file mode 100644 (file)
index 0000000..cacaa33
--- /dev/null
@@ -0,0 +1,44 @@
+From 5081efd112560d3febb328e627176235b250d59d Mon Sep 17 00:00:00 2001
+From: Nadav Amit <namit@vmware.com>
+Date: Tue, 19 Jun 2018 16:00:25 -0700
+Subject: vmw_balloon: do not use 2MB without batching
+
+From: Nadav Amit <namit@vmware.com>
+
+commit 5081efd112560d3febb328e627176235b250d59d upstream.
+
+If the hypervisor sets 2MB batching is on, while batching is cleared,
+the balloon code breaks. In this case the legacy mechanism is used with
+2MB page. The VM would report a 2MB page is ballooned, and the
+hypervisor would only take the first 4KB.
+
+While the hypervisor should not report such settings, make the code more
+robust by not enabling 2MB support without batching.
+
+Fixes: 365bd7ef7ec8e ("VMware balloon: Support 2m page ballooning.")
+Cc: stable@vger.kernel.org
+Reviewed-by: Xavier Deguillard <xdeguillard@vmware.com>
+Signed-off-by: Nadav Amit <nadav.amit@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/vmw_balloon.c |    8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/misc/vmw_balloon.c
++++ b/drivers/misc/vmw_balloon.c
+@@ -341,7 +341,13 @@ static bool vmballoon_send_start(struct
+               success = false;
+       }
+-      if (b->capabilities & VMW_BALLOON_BATCHED_2M_CMDS)
++      /*
++       * 2MB pages are only supported with batching. If batching is for some
++       * reason disabled, do not use 2MB pages, since otherwise the legacy
++       * mechanism is used with 2MB pages, causing a failure.
++       */
++      if ((b->capabilities & VMW_BALLOON_BATCHED_2M_CMDS) &&
++          (b->capabilities & VMW_BALLOON_BATCHED_CMDS))
+               b->supported_page_sizes = 2;
+       else
+               b->supported_page_sizes = 1;
diff --git a/queue-4.4/vmw_balloon-fix-inflation-of-64-bit-gfns.patch b/queue-4.4/vmw_balloon-fix-inflation-of-64-bit-gfns.patch
new file mode 100644 (file)
index 0000000..e5fd61b
--- /dev/null
@@ -0,0 +1,70 @@
+From 09755690c6b7c1eabdc4651eb3b276f8feb1e447 Mon Sep 17 00:00:00 2001
+From: Nadav Amit <namit@vmware.com>
+Date: Tue, 19 Jun 2018 16:00:24 -0700
+Subject: vmw_balloon: fix inflation of 64-bit GFNs
+
+From: Nadav Amit <namit@vmware.com>
+
+commit 09755690c6b7c1eabdc4651eb3b276f8feb1e447 upstream.
+
+When balloon batching is not supported by the hypervisor, the guest
+frame number (GFN) must fit in 32-bit. However, due to a bug, this check
+was mistakenly ignored. In practice, when total RAM is greater than
+16TB, the balloon does not work currently, making this bug unlikely to
+happen.
+
+Fixes: ef0f8f112984 ("VMware balloon: partially inline vmballoon_reserve_page.")
+Cc: stable@vger.kernel.org
+Reviewed-by: Xavier Deguillard <xdeguillard@vmware.com>
+Signed-off-by: Nadav Amit <namit@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/vmw_balloon.c |   13 +++++++------
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+--- a/drivers/misc/vmw_balloon.c
++++ b/drivers/misc/vmw_balloon.c
+@@ -450,7 +450,7 @@ static int vmballoon_send_lock_page(stru
+       pfn32 = (u32)pfn;
+       if (pfn32 != pfn)
+-              return -1;
++              return -EINVAL;
+       STATS_INC(b->stats.lock[false]);
+@@ -460,7 +460,7 @@ static int vmballoon_send_lock_page(stru
+       pr_debug("%s - ppn %lx, hv returns %ld\n", __func__, pfn, status);
+       STATS_INC(b->stats.lock_fail[false]);
+-      return 1;
++      return -EIO;
+ }
+ static int vmballoon_send_batched_lock(struct vmballoon *b,
+@@ -597,11 +597,12 @@ static int vmballoon_lock_page(struct vm
+       locked = vmballoon_send_lock_page(b, page_to_pfn(page), &hv_status,
+                                                               target);
+-      if (locked > 0) {
++      if (locked) {
+               STATS_INC(b->stats.refused_alloc[false]);
+-              if (hv_status == VMW_BALLOON_ERROR_RESET ||
+-                              hv_status == VMW_BALLOON_ERROR_PPN_NOTNEEDED) {
++              if (locked == -EIO &&
++                  (hv_status == VMW_BALLOON_ERROR_RESET ||
++                   hv_status == VMW_BALLOON_ERROR_PPN_NOTNEEDED)) {
+                       vmballoon_free_page(page, false);
+                       return -EIO;
+               }
+@@ -617,7 +618,7 @@ static int vmballoon_lock_page(struct vm
+               } else {
+                       vmballoon_free_page(page, false);
+               }
+-              return -EIO;
++              return locked;
+       }
+       /* track allocated page */
diff --git a/queue-4.4/vmw_balloon-fix-vmci-use-when-balloon-built-into-kernel.patch b/queue-4.4/vmw_balloon-fix-vmci-use-when-balloon-built-into-kernel.patch
new file mode 100644 (file)
index 0000000..61f2e9b
--- /dev/null
@@ -0,0 +1,53 @@
+From c3cc1b0fc27508da53fe955a3b23d03964410682 Mon Sep 17 00:00:00 2001
+From: Nadav Amit <namit@vmware.com>
+Date: Tue, 19 Jun 2018 16:00:27 -0700
+Subject: vmw_balloon: fix VMCI use when balloon built into kernel
+
+From: Nadav Amit <namit@vmware.com>
+
+commit c3cc1b0fc27508da53fe955a3b23d03964410682 upstream.
+
+Currently, when all modules, including VMCI and VMware balloon are built
+into the kernel, the initialization of the balloon happens before the
+VMCI is probed. As a result, the balloon fails to initialize the VMCI
+doorbell, which it uses to get asynchronous requests for balloon size
+changes.
+
+The problem can be seen in the logs, in the form of the following
+message:
+       "vmw_balloon: failed to initialize vmci doorbell"
+
+The driver would work correctly but slightly less efficiently, probing
+for requests periodically. This patch changes the balloon to be
+initialized using late_initcall() instead of module_init() to address
+this issue. It does not address a situation in which VMCI is built as a
+module and the balloon is built into the kernel.
+
+Fixes: 48e3d668b790 ("VMware balloon: Enable notification via VMCI")
+Cc: stable@vger.kernel.org
+Reviewed-by: Xavier Deguillard <xdeguillard@vmware.com>
+Signed-off-by: Nadav Amit <namit@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/vmw_balloon.c |    9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/misc/vmw_balloon.c
++++ b/drivers/misc/vmw_balloon.c
+@@ -1297,7 +1297,14 @@ static int __init vmballoon_init(void)
+       return 0;
+ }
+-module_init(vmballoon_init);
++
++/*
++ * Using late_initcall() instead of module_init() allows the balloon to use the
++ * VMCI doorbell even when the balloon is built into the kernel. Otherwise the
++ * VMCI is probed only after the balloon is initialized. If the balloon is used
++ * as a module, late_initcall() is equivalent to module_init().
++ */
++late_initcall(vmballoon_init);
+ static void __exit vmballoon_exit(void)
+ {
diff --git a/queue-4.4/vmw_balloon-vmci_doorbell_set-does-not-check-status.patch b/queue-4.4/vmw_balloon-vmci_doorbell_set-does-not-check-status.patch
new file mode 100644 (file)
index 0000000..fb30d60
--- /dev/null
@@ -0,0 +1,76 @@
+From ce664331b2487a5d244a51cbdd8cb54f866fbe5d Mon Sep 17 00:00:00 2001
+From: Nadav Amit <namit@vmware.com>
+Date: Tue, 19 Jun 2018 16:00:26 -0700
+Subject: vmw_balloon: VMCI_DOORBELL_SET does not check status
+
+From: Nadav Amit <namit@vmware.com>
+
+commit ce664331b2487a5d244a51cbdd8cb54f866fbe5d upstream.
+
+When vmballoon_vmci_init() sets a doorbell using VMCI_DOORBELL_SET, for
+some reason it does not consider the status and looks at the result.
+However, the hypervisor does not update the result - it updates the
+status. This might cause VMCI doorbell not to be enabled, resulting in
+degraded performance.
+
+Fixes: 48e3d668b790 ("VMware balloon: Enable notification via VMCI")
+Cc: stable@vger.kernel.org
+Reviewed-by: Xavier Deguillard <xdeguillard@vmware.com>
+Signed-off-by: Nadav Amit <namit@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/vmw_balloon.c |   37 +++++++++++++++++++------------------
+ 1 file changed, 19 insertions(+), 18 deletions(-)
+
+--- a/drivers/misc/vmw_balloon.c
++++ b/drivers/misc/vmw_balloon.c
+@@ -1036,29 +1036,30 @@ static void vmballoon_vmci_cleanup(struc
+  */
+ static int vmballoon_vmci_init(struct vmballoon *b)
+ {
+-      int error = 0;
++      unsigned long error, dummy;
+-      if ((b->capabilities & VMW_BALLOON_SIGNALLED_WAKEUP_CMD) != 0) {
+-              error = vmci_doorbell_create(&b->vmci_doorbell,
+-                              VMCI_FLAG_DELAYED_CB,
+-                              VMCI_PRIVILEGE_FLAG_RESTRICTED,
+-                              vmballoon_doorbell, b);
+-
+-              if (error == VMCI_SUCCESS) {
+-                      VMWARE_BALLOON_CMD(VMCI_DOORBELL_SET,
+-                                      b->vmci_doorbell.context,
+-                                      b->vmci_doorbell.resource, error);
+-                      STATS_INC(b->stats.doorbell_set);
+-              }
+-      }
++      if ((b->capabilities & VMW_BALLOON_SIGNALLED_WAKEUP_CMD) == 0)
++              return 0;
+-      if (error != 0) {
+-              vmballoon_vmci_cleanup(b);
++      error = vmci_doorbell_create(&b->vmci_doorbell, VMCI_FLAG_DELAYED_CB,
++                                   VMCI_PRIVILEGE_FLAG_RESTRICTED,
++                                   vmballoon_doorbell, b);
+-              return -EIO;
+-      }
++      if (error != VMCI_SUCCESS)
++              goto fail;
++
++      error = VMWARE_BALLOON_CMD(VMCI_DOORBELL_SET, b->vmci_doorbell.context,
++                                 b->vmci_doorbell.resource, dummy);
++
++      STATS_INC(b->stats.doorbell_set);
++
++      if (error != VMW_BALLOON_SUCCESS)
++              goto fail;
+       return 0;
++fail:
++      vmballoon_vmci_cleanup(b);
++      return -EIO;
+ }
+ /*
diff --git a/queue-4.4/x86-mm-pat-fix-l1tf-stable-backport-for-cpa-2nd-call.patch b/queue-4.4/x86-mm-pat-fix-l1tf-stable-backport-for-cpa-2nd-call.patch
new file mode 100644 (file)
index 0000000..3ec91a8
--- /dev/null
@@ -0,0 +1,57 @@
+From jslaby@suse.cz  Fri Sep  7 11:30:04 2018
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Fri,  7 Sep 2018 11:13:07 +0200
+Subject: x86/mm/pat: Fix L1TF stable backport for CPA, 2nd call
+To: gregkh@linuxfoundation.org
+Cc: stable@vger.kernel.org, Jiri Slaby <jslaby@suse.cz>, Andi Kleen <ak@linux.intel.com>
+Message-ID: <20180907091307.19644-1-jslaby@suse.cz>
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+Mostly recycling the commit log from adaba23ccd7d which fixed
+populate_pmd, but did not fix populate_pud. The same problem exists
+there.
+
+Stable trees reverted the following patch:
+  Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"
+
+    This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is
+    commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream.
+
+but the L1TF patch 02ff2769edbc backported here
+
+  x86/mm/pat: Make set_memory_np() L1TF safe
+
+    commit 958f79b9ee55dfaf00c8106ed1c22a2919e0028b upstream
+
+    set_memory_np() is used to mark kernel mappings not present, but it has
+    it's own open coded mechanism which does not have the L1TF protection of
+    inverting the address bits.
+
+assumed that cpa->pfn contains a PFN. With the above patch reverted
+it does not, which causes the PUD to be set to an incorrect address
+shifted by 12 bits, which can cause various failures.
+
+Convert the address to a PFN before passing it to pud_pfn().
+
+This is a 4.4 stable only patch to fix the L1TF patches backport there.
+
+Cc: stable@vger.kernel.org # 4.4-only
+Cc: Andi Kleen <ak@linux.intel.com>
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/mm/pageattr.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/mm/pageattr.c
++++ b/arch/x86/mm/pageattr.c
+@@ -1079,7 +1079,7 @@ static int populate_pud(struct cpa_data
+        * Map everything starting from the Gb boundary, possibly with 1G pages
+        */
+       while (end - start >= PUD_SIZE) {
+-              set_pud(pud, pud_mkhuge(pfn_pud(cpa->pfn,
++              set_pud(pud, pud_mkhuge(pfn_pud(cpa->pfn >> PAGE_SHIFT,
+                                  canon_pgprot(pud_pgprot))));
+               start     += PUD_SIZE;