--- /dev/null
+From 31fad7d41e73731f05b8053d17078638cf850fa6 Mon Sep 17 00:00:00 2001
+From: Roberto Bergantinos Corpas <rbergant@redhat.com>
+Date: Tue, 28 May 2019 09:38:14 +0200
+Subject: CIFS: cifs_read_allocate_pages: don't iterate through whole page array on ENOMEM
+
+From: Roberto Bergantinos Corpas <rbergant@redhat.com>
+
+commit 31fad7d41e73731f05b8053d17078638cf850fa6 upstream.
+
+ In cifs_read_allocate_pages, in case of ENOMEM, we go through
+whole rdata->pages array but we have failed the allocation before
+nr_pages, therefore we may end up calling put_page with NULL
+pointer, causing oops
+
+Signed-off-by: Roberto Bergantinos Corpas <rbergant@redhat.com>
+Acked-by: Pavel Shilovsky <pshilov@microsoft.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/file.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/cifs/file.c
++++ b/fs/cifs/file.c
+@@ -2892,7 +2892,9 @@ cifs_read_allocate_pages(struct cifs_rea
+ }
+
+ if (rc) {
+- for (i = 0; i < nr_pages; i++) {
++ unsigned int nr_page_failed = i;
++
++ for (i = 0; i < nr_page_failed; i++) {
+ put_page(rdata->pages[i]);
+ rdata->pages[i] = NULL;
+ }
--- /dev/null
+From 3bc8088464712fdcb078eefb68837ccfcc413c88 Mon Sep 17 00:00:00 2001
+From: Jonathan Corbet <corbet@lwn.net>
+Date: Wed, 22 May 2019 14:30:45 -0600
+Subject: docs: Fix conf.py for Sphinx 2.0
+
+From: Jonathan Corbet <corbet@lwn.net>
+
+commit 3bc8088464712fdcb078eefb68837ccfcc413c88 upstream.
+
+Our version check in Documentation/conf.py never envisioned a world where
+Sphinx moved beyond 1.x. Now that the unthinkable has happened, fix our
+version check to handle higher version numbers correctly.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Jonathan Corbet <corbet@lwn.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/conf.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/Documentation/conf.py
++++ b/Documentation/conf.py
+@@ -37,7 +37,7 @@ from load_config import loadConfig
+ extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain']
+
+ # The name of the math extension changed on Sphinx 1.4
+-if major == 1 and minor > 3:
++if (major == 1 and minor > 3) or (major > 1):
+ extensions.append("sphinx.ext.imgmath")
+ else:
+ extensions.append("sphinx.ext.pngmath")
--- /dev/null
+From 342406e4fbba9a174125fbfe6aeac3d64ef90f76 Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Tue, 9 Apr 2019 16:23:30 -0400
+Subject: drm/nouveau/i2c: Disable i2c bus access after ->fini()
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit 342406e4fbba9a174125fbfe6aeac3d64ef90f76 upstream.
+
+For a while, we've had the problem of i2c bus access not grabbing
+a runtime PM ref when it's being used in userspace by i2c-dev, resulting
+in nouveau spamming the kernel log with errors if anything attempts to
+access the i2c bus while the GPU is in runtime suspend. An example:
+
+[ 130.078386] nouveau 0000:01:00.0: i2c: aux 000d: begin idle timeout ffffffff
+
+Since the GPU is in runtime suspend, the MMIO region that the i2c bus is
+on isn't accessible. On x86, the standard behavior for accessing an
+unavailable MMIO region is to just return ~0.
+
+Except, that turned out to be a lie. While computers with a clean
+concious will return ~0 in this scenario, some machines will actually
+completely hang a CPU on certian bad MMIO accesses. This was witnessed
+with someone's Lenovo ThinkPad P50, where sensors-detect attempting to
+access the i2c bus while the GPU was suspended would result in a CPU
+hang:
+
+ CPU: 5 PID: 12438 Comm: sensors-detect Not tainted 5.0.0-0.rc4.git3.1.fc30.x86_64 #1
+ Hardware name: LENOVO 20EQS64N17/20EQS64N17, BIOS N1EET74W (1.47 ) 11/21/2017
+ RIP: 0010:ioread32+0x2b/0x30
+ Code: 81 ff ff ff 03 00 77 20 48 81 ff 00 00 01 00 76 05 0f b7 d7 ed c3
+ 48 c7 c6 e1 0c 36 96 e8 2d ff ff ff b8 ff ff ff ff c3 8b 07 <c3> 0f 1f
+ 40 00 49 89 f0 48 81 fe ff ff 03 00 76 04 40 88 3e c3 48
+ RSP: 0018:ffffaac3c5007b48 EFLAGS: 00000292 ORIG_RAX: ffffffffffffff13
+ RAX: 0000000001111000 RBX: 0000000001111000 RCX: 0000043017a97186
+ RDX: 0000000000000aaa RSI: 0000000000000005 RDI: ffffaac3c400e4e4
+ RBP: ffff9e6443902c00 R08: ffffaac3c400e4e4 R09: ffffaac3c5007be7
+ R10: 0000000000000004 R11: 0000000000000001 R12: ffff9e6445dd0000
+ R13: 000000000000e4e4 R14: 00000000000003c4 R15: 0000000000000000
+ FS: 00007f253155a740(0000) GS:ffff9e644f600000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 00005630d1500358 CR3: 0000000417c44006 CR4: 00000000003606e0
+ DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+ DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+ Call Trace:
+ g94_i2c_aux_xfer+0x326/0x850 [nouveau]
+ nvkm_i2c_aux_i2c_xfer+0x9e/0x140 [nouveau]
+ __i2c_transfer+0x14b/0x620
+ i2c_smbus_xfer_emulated+0x159/0x680
+ ? _raw_spin_unlock_irqrestore+0x1/0x60
+ ? rt_mutex_slowlock.constprop.0+0x13d/0x1e0
+ ? __lock_is_held+0x59/0xa0
+ __i2c_smbus_xfer+0x138/0x5a0
+ i2c_smbus_xfer+0x4f/0x80
+ i2cdev_ioctl_smbus+0x162/0x2d0 [i2c_dev]
+ i2cdev_ioctl+0x1db/0x2c0 [i2c_dev]
+ do_vfs_ioctl+0x408/0x750
+ ksys_ioctl+0x5e/0x90
+ __x64_sys_ioctl+0x16/0x20
+ do_syscall_64+0x60/0x1e0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+ RIP: 0033:0x7f25317f546b
+ Code: 0f 1e fa 48 8b 05 1d da 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff
+ ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01
+ f0 ff ff 73 01 c3 48 8b 0d ed d9 0c 00 f7 d8 64 89 01 48
+ RSP: 002b:00007ffc88caab68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
+ RAX: ffffffffffffffda RBX: 00005630d0fe7260 RCX: 00007f25317f546b
+ RDX: 00005630d1598e80 RSI: 0000000000000720 RDI: 0000000000000003
+ RBP: 00005630d155b968 R08: 0000000000000001 R09: 00005630d15a1da0
+ R10: 0000000000000070 R11: 0000000000000246 R12: 00005630d1598e80
+ R13: 00005630d12f3d28 R14: 0000000000000720 R15: 00005630d12f3ce0
+ watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [sensors-detect:12438]
+
+Yikes! While I wanted to try to make it so that accessing an i2c bus on
+nouveau would wake up the GPU as needed, airlied pointed out that pretty
+much any usecase for userspace accessing an i2c bus on a GPU (mainly for
+the DDC brightness control that some displays have) is going to only be
+useful while there's at least one display enabled on the GPU anyway, and
+the GPU never sleeps while there's displays running.
+
+Since teaching the i2c bus to wake up the GPU on userspace accesses is a
+good deal more difficult than it might seem, mostly due to the fact that
+we have to use the i2c bus during runtime resume of the GPU, we instead
+opt for the easiest solution: don't let userspace access i2c busses on
+the GPU at all while it's in runtime suspend.
+
+Changes since v1:
+* Also disable i2c busses that run over DP AUX
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h | 2 +
+ drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 26 +++++++++++++++++++++-
+ drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h | 2 +
+ drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c | 15 ++++++++++++
+ drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c | 21 ++++++++++++++++-
+ drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.h | 1
+ 6 files changed, 65 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
++++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
+@@ -37,6 +37,7 @@ struct nvkm_i2c_bus {
+ struct mutex mutex;
+ struct list_head head;
+ struct i2c_adapter i2c;
++ u8 enabled;
+ };
+
+ int nvkm_i2c_bus_acquire(struct nvkm_i2c_bus *);
+@@ -56,6 +57,7 @@ struct nvkm_i2c_aux {
+ struct mutex mutex;
+ struct list_head head;
+ struct i2c_adapter i2c;
++ u8 enabled;
+
+ u32 intr;
+ };
+--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
+@@ -105,9 +105,15 @@ nvkm_i2c_aux_acquire(struct nvkm_i2c_aux
+ {
+ struct nvkm_i2c_pad *pad = aux->pad;
+ int ret;
++
+ AUX_TRACE(aux, "acquire");
+ mutex_lock(&aux->mutex);
+- ret = nvkm_i2c_pad_acquire(pad, NVKM_I2C_PAD_AUX);
++
++ if (aux->enabled)
++ ret = nvkm_i2c_pad_acquire(pad, NVKM_I2C_PAD_AUX);
++ else
++ ret = -EIO;
++
+ if (ret)
+ mutex_unlock(&aux->mutex);
+ return ret;
+@@ -141,6 +147,24 @@ nvkm_i2c_aux_del(struct nvkm_i2c_aux **p
+ }
+ }
+
++void
++nvkm_i2c_aux_init(struct nvkm_i2c_aux *aux)
++{
++ AUX_TRACE(aux, "init");
++ mutex_lock(&aux->mutex);
++ aux->enabled = true;
++ mutex_unlock(&aux->mutex);
++}
++
++void
++nvkm_i2c_aux_fini(struct nvkm_i2c_aux *aux)
++{
++ AUX_TRACE(aux, "fini");
++ mutex_lock(&aux->mutex);
++ aux->enabled = false;
++ mutex_unlock(&aux->mutex);
++}
++
+ int
+ nvkm_i2c_aux_ctor(const struct nvkm_i2c_aux_func *func,
+ struct nvkm_i2c_pad *pad, int id,
+--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h
++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h
+@@ -14,6 +14,8 @@ int nvkm_i2c_aux_ctor(const struct nvkm_
+ int nvkm_i2c_aux_new_(const struct nvkm_i2c_aux_func *, struct nvkm_i2c_pad *,
+ int id, struct nvkm_i2c_aux **);
+ void nvkm_i2c_aux_del(struct nvkm_i2c_aux **);
++void nvkm_i2c_aux_init(struct nvkm_i2c_aux *);
++void nvkm_i2c_aux_fini(struct nvkm_i2c_aux *);
+ int nvkm_i2c_aux_xfer(struct nvkm_i2c_aux *, bool retry, u8 type,
+ u32 addr, u8 *data, u8 size);
+
+--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
+@@ -160,8 +160,18 @@ nvkm_i2c_fini(struct nvkm_subdev *subdev
+ {
+ struct nvkm_i2c *i2c = nvkm_i2c(subdev);
+ struct nvkm_i2c_pad *pad;
++ struct nvkm_i2c_bus *bus;
++ struct nvkm_i2c_aux *aux;
+ u32 mask;
+
++ list_for_each_entry(aux, &i2c->aux, head) {
++ nvkm_i2c_aux_fini(aux);
++ }
++
++ list_for_each_entry(bus, &i2c->bus, head) {
++ nvkm_i2c_bus_fini(bus);
++ }
++
+ if ((mask = (1 << i2c->func->aux) - 1), i2c->func->aux_stat) {
+ i2c->func->aux_mask(i2c, NVKM_I2C_ANY, mask, 0);
+ i2c->func->aux_stat(i2c, &mask, &mask, &mask, &mask);
+@@ -180,6 +190,7 @@ nvkm_i2c_init(struct nvkm_subdev *subdev
+ struct nvkm_i2c *i2c = nvkm_i2c(subdev);
+ struct nvkm_i2c_bus *bus;
+ struct nvkm_i2c_pad *pad;
++ struct nvkm_i2c_aux *aux;
+
+ list_for_each_entry(pad, &i2c->pad, head) {
+ nvkm_i2c_pad_init(pad);
+@@ -189,6 +200,10 @@ nvkm_i2c_init(struct nvkm_subdev *subdev
+ nvkm_i2c_bus_init(bus);
+ }
+
++ list_for_each_entry(aux, &i2c->aux, head) {
++ nvkm_i2c_aux_init(aux);
++ }
++
+ return 0;
+ }
+
+--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c
++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c
+@@ -110,6 +110,19 @@ nvkm_i2c_bus_init(struct nvkm_i2c_bus *b
+ BUS_TRACE(bus, "init");
+ if (bus->func->init)
+ bus->func->init(bus);
++
++ mutex_lock(&bus->mutex);
++ bus->enabled = true;
++ mutex_unlock(&bus->mutex);
++}
++
++void
++nvkm_i2c_bus_fini(struct nvkm_i2c_bus *bus)
++{
++ BUS_TRACE(bus, "fini");
++ mutex_lock(&bus->mutex);
++ bus->enabled = false;
++ mutex_unlock(&bus->mutex);
+ }
+
+ void
+@@ -126,9 +139,15 @@ nvkm_i2c_bus_acquire(struct nvkm_i2c_bus
+ {
+ struct nvkm_i2c_pad *pad = bus->pad;
+ int ret;
++
+ BUS_TRACE(bus, "acquire");
+ mutex_lock(&bus->mutex);
+- ret = nvkm_i2c_pad_acquire(pad, NVKM_I2C_PAD_I2C);
++
++ if (bus->enabled)
++ ret = nvkm_i2c_pad_acquire(pad, NVKM_I2C_PAD_I2C);
++ else
++ ret = -EIO;
++
+ if (ret)
+ mutex_unlock(&bus->mutex);
+ return ret;
+--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.h
++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.h
+@@ -17,6 +17,7 @@ int nvkm_i2c_bus_new_(const struct nvkm_
+ int id, struct nvkm_i2c_bus **);
+ void nvkm_i2c_bus_del(struct nvkm_i2c_bus **);
+ void nvkm_i2c_bus_init(struct nvkm_i2c_bus *);
++void nvkm_i2c_bus_fini(struct nvkm_i2c_bus *);
+
+ int nvkm_i2c_bit_xfer(struct nvkm_i2c_bus *, struct i2c_msg *, int);
+
--- /dev/null
+From 7210e060155b9cf557fb13128353c3e494fa5ed3 Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Mon, 20 May 2019 11:50:42 -0700
+Subject: gcc-plugins: Fix build failures under Darwin host
+
+From: Kees Cook <keescook@chromium.org>
+
+commit 7210e060155b9cf557fb13128353c3e494fa5ed3 upstream.
+
+The gcc-common.h file did not take into account certain macros that
+might have already been defined in the build environment. This updates
+the header to avoid redefining the macros, as seen on a Darwin host
+using gcc 4.9.2:
+
+ HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o - due to: scripts/gcc-plugins/gcc-common.h
+In file included from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:0:
+scripts/gcc-plugins/gcc-common.h:153:0: warning: "__unused" redefined
+^
+In file included from /usr/include/stdio.h:64:0,
+ from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/system.h:40,
+ from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/gcc-plugin.h:28,
+ from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/plugin.h:23,
+ from scripts/gcc-plugins/gcc-common.h:9,
+ from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:
+/usr/include/sys/cdefs.h:161:0: note: this is the location of the previous definition
+^
+
+Reported-and-tested-by: "H. Nikolaus Schaller" <hns@goldelico.com>
+Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries")
+Cc: stable@vger.kernel.org
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ scripts/gcc-plugins/gcc-common.h | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/scripts/gcc-plugins/gcc-common.h
++++ b/scripts/gcc-plugins/gcc-common.h
+@@ -135,8 +135,12 @@ extern void print_gimple_expr(FILE *, gi
+ extern void dump_gimple_stmt(pretty_printer *, gimple, int, int);
+ #endif
+
++#ifndef __unused
+ #define __unused __attribute__((__unused__))
++#endif
++#ifndef __visible
+ #define __visible __attribute__((visibility("default")))
++#endif
+
+ #define DECL_NAME_POINTER(node) IDENTIFIER_POINTER(DECL_NAME(node))
+ #define DECL_NAME_LENGTH(node) IDENTIFIER_LENGTH(DECL_NAME(node))
--- /dev/null
+From 98af37d624ed8c83f1953b1b6b2f6866011fc064 Mon Sep 17 00:00:00 2001
+From: Zhenliang Wei <weizhenliang@huawei.com>
+Date: Fri, 31 May 2019 22:30:52 -0700
+Subject: kernel/signal.c: trace_signal_deliver when signal_group_exit
+
+From: Zhenliang Wei <weizhenliang@huawei.com>
+
+commit 98af37d624ed8c83f1953b1b6b2f6866011fc064 upstream.
+
+In the fixes commit, removing SIGKILL from each thread signal mask and
+executing "goto fatal" directly will skip the call to
+"trace_signal_deliver". At this point, the delivery tracking of the
+SIGKILL signal will be inaccurate.
+
+Therefore, we need to add trace_signal_deliver before "goto fatal" after
+executing sigdelset.
+
+Note: SEND_SIG_NOINFO matches the fact that SIGKILL doesn't have any info.
+
+Link: http://lkml.kernel.org/r/20190425025812.91424-1-weizhenliang@huawei.com
+Fixes: cf43a757fd4944 ("signal: Restore the stop PTRACE_EVENT_EXIT")
+Signed-off-by: Zhenliang Wei <weizhenliang@huawei.com>
+Reviewed-by: Christian Brauner <christian@brauner.io>
+Reviewed-by: Oleg Nesterov <oleg@redhat.com>
+Cc: Eric W. Biederman <ebiederm@xmission.com>
+Cc: Ivan Delalande <colona@arista.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Deepa Dinamani <deepa.kernel@gmail.com>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: <stable@vger.kernel.org>
+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>
+
+---
+ kernel/signal.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/kernel/signal.c
++++ b/kernel/signal.c
+@@ -2244,6 +2244,8 @@ relock:
+ if (signal_group_exit(signal)) {
+ ksig->info.si_signo = signr = SIGKILL;
+ sigdelset(¤t->pending.signal, SIGKILL);
++ trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO,
++ &sighand->action[SIGKILL - 1]);
+ recalc_sigpending();
+ goto fatal;
+ }
--- /dev/null
+From 3e8589963773a5c23e2f1fe4bcad0e9a90b7f471 Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Fri, 31 May 2019 22:30:26 -0700
+Subject: memcg: make it work on sparse non-0-node systems
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+commit 3e8589963773a5c23e2f1fe4bcad0e9a90b7f471 upstream.
+
+We have a single node system with node 0 disabled:
+ Scanning NUMA topology in Northbridge 24
+ Number of physical nodes 2
+ Skipping disabled node 0
+ Node 1 MemBase 0000000000000000 Limit 00000000fbff0000
+ NODE_DATA(1) allocated [mem 0xfbfda000-0xfbfeffff]
+
+This causes crashes in memcg when system boots:
+ BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
+ #PF error: [normal kernel read fault]
+...
+ RIP: 0010:list_lru_add+0x94/0x170
+...
+ Call Trace:
+ d_lru_add+0x44/0x50
+ dput.part.34+0xfc/0x110
+ __fput+0x108/0x230
+ task_work_run+0x9f/0xc0
+ exit_to_usermode_loop+0xf5/0x100
+
+It is reproducible as far as 4.12. I did not try older kernels. You have
+to have a new enough systemd, e.g. 241 (the reason is unknown -- was not
+investigated). Cannot be reproduced with systemd 234.
+
+The system crashes because the size of lru array is never updated in
+memcg_update_all_list_lrus and the reads are past the zero-sized array,
+causing dereferences of random memory.
+
+The root cause are list_lru_memcg_aware checks in the list_lru code. The
+test in list_lru_memcg_aware is broken: it assumes node 0 is always
+present, but it is not true on some systems as can be seen above.
+
+So fix this by avoiding checks on node 0. Remember the memcg-awareness by
+a bool flag in struct list_lru.
+
+Link: http://lkml.kernel.org/r/20190522091940.3615-1-jslaby@suse.cz
+Fixes: 60d3fd32a7a9 ("list_lru: introduce per-memcg lists")
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Suggested-by: Vladimir Davydov <vdavydov.dev@gmail.com>
+Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
+Reviewed-by: Shakeel Butt <shakeelb@google.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
+Cc: <stable@vger.kernel.org>
+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>
+
+---
+ include/linux/list_lru.h | 1 +
+ mm/list_lru.c | 8 +++-----
+ 2 files changed, 4 insertions(+), 5 deletions(-)
+
+--- a/include/linux/list_lru.h
++++ b/include/linux/list_lru.h
+@@ -51,6 +51,7 @@ struct list_lru {
+ struct list_lru_node *node;
+ #if defined(CONFIG_MEMCG) && !defined(CONFIG_SLOB)
+ struct list_head list;
++ bool memcg_aware;
+ #endif
+ };
+
+--- a/mm/list_lru.c
++++ b/mm/list_lru.c
+@@ -42,11 +42,7 @@ static void list_lru_unregister(struct l
+ #if defined(CONFIG_MEMCG) && !defined(CONFIG_SLOB)
+ static inline bool list_lru_memcg_aware(struct list_lru *lru)
+ {
+- /*
+- * This needs node 0 to be always present, even
+- * in the systems supporting sparse numa ids.
+- */
+- return !!lru->node[0].memcg_lrus;
++ return lru->memcg_aware;
+ }
+
+ static inline struct list_lru_one *
+@@ -389,6 +385,8 @@ static int memcg_init_list_lru(struct li
+ {
+ int i;
+
++ lru->memcg_aware = memcg_aware;
++
+ if (!memcg_aware)
+ return 0;
+
btrfs-fix-race-updating-log-root-item-during-fsync.patch
powerpc-perf-fix-mmcra-corruption-by-bhrb_filter.patch
alsa-hda-realtek-set-default-power-save-node-to-0.patch
+drm-nouveau-i2c-disable-i2c-bus-access-after-fini.patch
+tty-serial-msm_serial-fix-xon-xoff.patch
+tty-max310x-fix-external-crystal-register-setup.patch
+memcg-make-it-work-on-sparse-non-0-node-systems.patch
+kernel-signal.c-trace_signal_deliver-when-signal_group_exit.patch
+docs-fix-conf.py-for-sphinx-2.0.patch
+staging-vc04_services-prevent-integer-overflow-in-create_pagelist.patch
+cifs-cifs_read_allocate_pages-don-t-iterate-through-whole-page-array-on-enomem.patch
+gcc-plugins-fix-build-failures-under-darwin-host.patch
--- /dev/null
+From ca641bae6da977d638458e78cd1487b6160a2718 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Wed, 15 May 2019 12:38:33 +0300
+Subject: staging: vc04_services: prevent integer overflow in create_pagelist()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit ca641bae6da977d638458e78cd1487b6160a2718 upstream.
+
+The create_pagelist() "count" parameter comes from the user in
+vchiq_ioctl() and it could overflow. If you look at how create_page()
+is called in vchiq_prepare_bulk_data(), then the "size" variable is an
+int so it doesn't make sense to allow negatives or larger than INT_MAX.
+
+I don't know this code terribly well, but I believe that typical values
+of "count" are typically quite low and I don't think this check will
+affect normal valid uses at all.
+
+The "pagelist_size" calculation can also overflow on 32 bit systems, but
+not on 64 bit systems. I have added an integer overflow check for that
+as well.
+
+The Raspberry PI doesn't offer the same level of memory protection that
+x86 does so these sorts of bugs are probably not super critical to fix.
+
+Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
++++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+@@ -381,9 +381,18 @@ create_pagelist(char __user *buf, size_t
+ int run, addridx, actual_pages;
+ unsigned long *need_release;
+
++ if (count >= INT_MAX - PAGE_SIZE)
++ return NULL;
++
+ offset = (unsigned int)buf & (PAGE_SIZE - 1);
+ num_pages = (count + offset + PAGE_SIZE - 1) / PAGE_SIZE;
+
++ if (num_pages > (SIZE_MAX - sizeof(struct pagelist) -
++ sizeof(struct vchiq_pagelist_info)) /
++ (sizeof(u32) + sizeof(pages[0]) +
++ sizeof(struct scatterlist)))
++ return NULL;
++
+ *ppagelist = NULL;
+
+ /* Allocate enough storage to hold the page pointers and the page
--- /dev/null
+From 5d24f455c182d5116dd5db8e1dc501115ecc9c2c Mon Sep 17 00:00:00 2001
+From: Joe Burmeister <joe.burmeister@devtank.co.uk>
+Date: Mon, 13 May 2019 11:23:57 +0100
+Subject: tty: max310x: Fix external crystal register setup
+
+From: Joe Burmeister <joe.burmeister@devtank.co.uk>
+
+commit 5d24f455c182d5116dd5db8e1dc501115ecc9c2c upstream.
+
+The datasheet states:
+
+ Bit 4: ClockEnSet the ClockEn bit high to enable an external clocking
+(crystal or clock generator at XIN). Set the ClockEn bit to 0 to disable
+clocking
+ Bit 1: CrystalEnSet the CrystalEn bit high to enable the crystal
+oscillator. When using an external clock source at XIN, CrystalEn must
+be set low.
+
+The bit 4, MAX310X_CLKSRC_EXTCLK_BIT, should be set and was not.
+
+This was required to make the MAX3107 with an external crystal on our
+board able to send or receive data.
+
+Signed-off-by: Joe Burmeister <joe.burmeister@devtank.co.uk>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/max310x.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/max310x.c
++++ b/drivers/tty/serial/max310x.c
+@@ -579,7 +579,7 @@ static int max310x_set_ref_clk(struct ma
+ }
+
+ /* Configure clock source */
+- clksrc = xtal ? MAX310X_CLKSRC_CRYST_BIT : MAX310X_CLKSRC_EXTCLK_BIT;
++ clksrc = MAX310X_CLKSRC_EXTCLK_BIT | (xtal ? MAX310X_CLKSRC_CRYST_BIT : 0);
+
+ /* Configure PLL */
+ if (pllcfg) {
--- /dev/null
+From 61c0e37950b88bad590056286c1d766b1f167f4e Mon Sep 17 00:00:00 2001
+From: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
+Date: Mon, 20 May 2019 20:38:48 +0200
+Subject: tty: serial: msm_serial: Fix XON/XOFF
+
+From: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
+
+commit 61c0e37950b88bad590056286c1d766b1f167f4e upstream.
+
+When the tty layer requests the uart to throttle, the current code
+executing in msm_serial will trigger "Bad mode in Error Handler" and
+generate an invalid stack frame in pstore before rebooting (that is if
+pstore is indeed configured: otherwise the user shall just notice a
+reboot with no further information dumped to the console).
+
+This patch replaces the PIO byte accessor with the word accessor
+already used in PIO mode.
+
+Fixes: 68252424a7c7 ("tty: serial: msm: Support big-endian CPUs")
+Cc: stable@vger.kernel.org
+Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
+Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Reviewed-by: Stephen Boyd <swboyd@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/msm_serial.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/msm_serial.c
++++ b/drivers/tty/serial/msm_serial.c
+@@ -868,6 +868,7 @@ static void msm_handle_tx(struct uart_po
+ struct circ_buf *xmit = &msm_port->uart.state->xmit;
+ struct msm_dma *dma = &msm_port->tx_dma;
+ unsigned int pio_count, dma_count, dma_min;
++ char buf[4] = { 0 };
+ void __iomem *tf;
+ int err = 0;
+
+@@ -877,10 +878,12 @@ static void msm_handle_tx(struct uart_po
+ else
+ tf = port->membase + UART_TF;
+
++ buf[0] = port->x_char;
++
+ if (msm_port->is_uartdm)
+ msm_reset_dm_count(port, 1);
+
+- iowrite8_rep(tf, &port->x_char, 1);
++ iowrite32_rep(tf, buf, 1);
+ port->icount.tx++;
+ port->x_char = 0;
+ return;
projects / thirdparty / kernel / stable-queue.git / commitdiff
