+ * extents that haven't had their dirty pages IO start writeout yet
+ * actually get run and error out properly.
+ */
-+ btrfs_wait_ordered_roots(fs_info, -1, 0, (u64)-1);
++ btrfs_wait_ordered_roots(fs_info, -1);
}
static int btrfs_destroy_delayed_refs(struct btrfs_transaction *trans,
--- /dev/null
+From a214720cbf50cd8c3f76bbb9c3f5c283910e9d33 Mon Sep 17 00:00:00 2001
+From: YunQiang Su <ysu@wavecomp.com>
+Date: Tue, 8 Jan 2019 13:45:10 +0800
+Subject: Disable MSI also when pcie-octeon.pcie_disable on
+
+From: YunQiang Su <ysu@wavecomp.com>
+
+commit a214720cbf50cd8c3f76bbb9c3f5c283910e9d33 upstream.
+
+Octeon has an boot-time option to disable pcie.
+
+Since MSI depends on PCI-E, we should also disable MSI also with
+this option is on in order to avoid inadvertently accessing PCIe
+registers.
+
+Signed-off-by: YunQiang Su <ysu@wavecomp.com>
+Signed-off-by: Paul Burton <paul.burton@mips.com>
+Cc: pburton@wavecomp.com
+Cc: linux-mips@vger.kernel.org
+Cc: aaro.koskinen@iki.fi
+Cc: stable@vger.kernel.org # v3.3+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/pci/msi-octeon.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/mips/pci/msi-octeon.c
++++ b/arch/mips/pci/msi-octeon.c
+@@ -369,7 +369,9 @@ int __init octeon_msi_initialize(void)
+ int irq;
+ struct irq_chip *msi;
+
+- if (octeon_dma_bar_type == OCTEON_DMA_BAR_TYPE_PCIE) {
++ if (octeon_dma_bar_type == OCTEON_DMA_BAR_TYPE_INVALID) {
++ return 0;
++ } else if (octeon_dma_bar_type == OCTEON_DMA_BAR_TYPE_PCIE) {
+ msi_rcv_reg[0] = CVMX_PEXP_NPEI_MSI_RCV0;
+ msi_rcv_reg[1] = CVMX_PEXP_NPEI_MSI_RCV1;
+ msi_rcv_reg[2] = CVMX_PEXP_NPEI_MSI_RCV2;
--- /dev/null
+From a5795fd38ee8194451ba3f281f075301a3696ce2 Mon Sep 17 00:00:00 2001
+From: James Morris <james.morris@microsoft.com>
+Date: Wed, 16 Jan 2019 15:41:11 -0800
+Subject: LSM: Check for NULL cred-security on free
+
+From: James Morris <james.morris@microsoft.com>
+
+commit a5795fd38ee8194451ba3f281f075301a3696ce2 upstream.
+
+From: Casey Schaufler <casey@schaufler-ca.com>
+
+Check that the cred security blob has been set before trying
+to clean it up. There is a case during credential initialization
+that could result in this.
+
+Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
+Acked-by: John Johansen <john.johansen@canonical.com>
+Signed-off-by: James Morris <james.morris@microsoft.com>
+Reported-by: syzbot+69ca07954461f189e808@syzkaller.appspotmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/security.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/security/security.c
++++ b/security/security.c
+@@ -861,6 +861,13 @@ int security_cred_alloc_blank(struct cre
+
+ void security_cred_free(struct cred *cred)
+ {
++ /*
++ * There is a failure case in prepare_creds() that
++ * may result in a call here with ->security being NULL.
++ */
++ if (unlikely(cred->security == NULL))
++ return;
++
+ call_void_hook(cred_free, cred);
+ }
+
--- /dev/null
+From cd26d1c4d1bc947b56ae404998ae2276df7b39b7 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil@xs4all.nl>
+Date: Tue, 13 Nov 2018 09:06:46 -0500
+Subject: media: vb2: vb2_mmap: move lock up
+
+From: Hans Verkuil <hverkuil@xs4all.nl>
+
+commit cd26d1c4d1bc947b56ae404998ae2276df7b39b7 upstream.
+
+If a filehandle is dup()ped, then it is possible to close it from one fd
+and call mmap from the other. This creates a race condition in vb2_mmap
+where it is using queue data that __vb2_queue_free (called from close())
+is in the process of releasing.
+
+By moving up the mutex_lock(mmap_lock) in vb2_mmap this race is avoided
+since __vb2_queue_free is called with the same mutex locked. So vb2_mmap
+now reads consistent buffer data.
+
+Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
+Reported-by: syzbot+be93025dd45dccd8923c@syzkaller.appspotmail.com
+Signed-off-by: Hans Verkuil <hansverk@cisco.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/v4l2-core/videobuf2-core.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/media/v4l2-core/videobuf2-core.c
++++ b/drivers/media/v4l2-core/videobuf2-core.c
+@@ -1976,9 +1976,13 @@ int vb2_mmap(struct vb2_queue *q, struct
+ return -EINVAL;
+ }
+ }
++
++ mutex_lock(&q->mmap_lock);
++
+ if (vb2_fileio_is_active(q)) {
+ dprintk(1, "mmap: file io in progress\n");
+- return -EBUSY;
++ ret = -EBUSY;
++ goto unlock;
+ }
+
+ /*
+@@ -1986,7 +1990,7 @@ int vb2_mmap(struct vb2_queue *q, struct
+ */
+ ret = __find_plane_by_offset(q, off, &buffer, &plane);
+ if (ret)
+- return ret;
++ goto unlock;
+
+ vb = q->bufs[buffer];
+
+@@ -2002,8 +2006,9 @@ int vb2_mmap(struct vb2_queue *q, struct
+ return -EINVAL;
+ }
+
+- mutex_lock(&q->mmap_lock);
+ ret = call_memop(vb, mmap, vb->planes[plane].mem_priv, vma);
++
++unlock:
+ mutex_unlock(&q->mmap_lock);
+ if (ret)
+ return ret;
--- /dev/null
+From 701f49bc028edb19ffccd101997dd84f0d71e279 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Mon, 29 Oct 2018 06:15:31 -0400
+Subject: media: vivid: fix error handling of kthread_run
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit 701f49bc028edb19ffccd101997dd84f0d71e279 upstream.
+
+kthread_run returns an error pointer, but elsewhere in the code
+dev->kthread_vid_cap/out is checked against NULL.
+
+If kthread_run returns an error, then set the pointer to NULL.
+
+I chose this method over changing all kthread_vid_cap/out tests
+elsewhere since this is more robust.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Reported-by: syzbot+53d5b2df0d9744411e2e@syzkaller.appspotmail.com
+Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/platform/vivid/vivid-kthread-cap.c | 5 ++++-
+ drivers/media/platform/vivid/vivid-kthread-out.c | 5 ++++-
+ 2 files changed, 8 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/platform/vivid/vivid-kthread-cap.c
++++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
+@@ -863,8 +863,11 @@ int vivid_start_generating_vid_cap(struc
+ "%s-vid-cap", dev->v4l2_dev.name);
+
+ if (IS_ERR(dev->kthread_vid_cap)) {
++ int err = PTR_ERR(dev->kthread_vid_cap);
++
++ dev->kthread_vid_cap = NULL;
+ v4l2_err(&dev->v4l2_dev, "kernel_thread() failed\n");
+- return PTR_ERR(dev->kthread_vid_cap);
++ return err;
+ }
+ *pstreaming = true;
+ vivid_grab_controls(dev, true);
+--- a/drivers/media/platform/vivid/vivid-kthread-out.c
++++ b/drivers/media/platform/vivid/vivid-kthread-out.c
+@@ -248,8 +248,11 @@ int vivid_start_generating_vid_out(struc
+ "%s-vid-out", dev->v4l2_dev.name);
+
+ if (IS_ERR(dev->kthread_vid_out)) {
++ int err = PTR_ERR(dev->kthread_vid_out);
++
++ dev->kthread_vid_out = NULL;
+ v4l2_err(&dev->v4l2_dev, "kernel_thread() failed\n");
+- return PTR_ERR(dev->kthread_vid_out);
++ return err;
+ }
+ *pstreaming = true;
+ vivid_grab_controls(dev, true);
--- /dev/null
+From 9729d6d282a6d7ce88e64c9119cecdf79edf4e88 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Mon, 29 Oct 2018 13:32:38 -0400
+Subject: media: vivid: set min width/height to a value > 0
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit 9729d6d282a6d7ce88e64c9119cecdf79edf4e88 upstream.
+
+The capture DV timings capabilities allowed for a minimum width and
+height of 0. So passing a timings struct with 0 values is allowed
+and will later cause a division by zero.
+
+Ensure that the width and height must be >= 16 to avoid this.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Reported-by: syzbot+57c3d83d71187054d56f@syzkaller.appspotmail.com
+Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/platform/vivid/vivid-vid-common.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/platform/vivid/vivid-vid-common.c
++++ b/drivers/media/platform/vivid/vivid-vid-common.c
+@@ -33,7 +33,7 @@ const struct v4l2_dv_timings_cap vivid_d
+ .type = V4L2_DV_BT_656_1120,
+ /* keep this initialization for compatibility with GCC < 4.4.6 */
+ .reserved = { 0 },
+- V4L2_INIT_BT_TIMINGS(0, MAX_WIDTH, 0, MAX_HEIGHT, 14000000, 775000000,
++ V4L2_INIT_BT_TIMINGS(16, MAX_WIDTH, 16, MAX_HEIGHT, 14000000, 775000000,
+ V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
+ V4L2_DV_BT_STD_CVT | V4L2_DV_BT_STD_GTF,
+ V4L2_DV_BT_CAP_PROGRESSIVE | V4L2_DV_BT_CAP_INTERLACED)
--- /dev/null
+From ac4ca4b9f4623ba5e1ea7a582f286567c611e027 Mon Sep 17 00:00:00 2001
+From: Jonathan Hunter <jonathanh@nvidia.com>
+Date: Tue, 13 Nov 2018 08:56:31 +0000
+Subject: mfd: tps6586x: Handle interrupts on suspend
+
+From: Jonathan Hunter <jonathanh@nvidia.com>
+
+commit ac4ca4b9f4623ba5e1ea7a582f286567c611e027 upstream.
+
+The tps6586x driver creates an irqchip that is used by its various child
+devices for managing interrupts. The tps6586x-rtc device is one of its
+children that uses the tps6586x irqchip. When using the tps6586x-rtc as
+a wake-up device from suspend, the following is seen:
+
+ PM: Syncing filesystems ... done.
+ Freezing user space processes ... (elapsed 0.001 seconds) done.
+ OOM killer disabled.
+ Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
+ Disabling non-boot CPUs ...
+ Entering suspend state LP1
+ Enabling non-boot CPUs ...
+ CPU1 is up
+ tps6586x 3-0034: failed to read interrupt status
+ tps6586x 3-0034: failed to read interrupt status
+
+The reason why the tps6586x interrupt status cannot be read is because
+the tps6586x interrupt is not masked during suspend and when the
+tps6586x-rtc interrupt occurs, to wake-up the device, the interrupt is
+seen before the i2c controller has been resumed in order to read the
+tps6586x interrupt status.
+
+The tps6586x-rtc driver sets it's interrupt as a wake-up source during
+suspend, which gets propagated to the parent tps6586x interrupt.
+However, the tps6586x-rtc driver cannot disable it's interrupt during
+suspend otherwise we would never be woken up and so the tps6586x must
+disable it's interrupt instead.
+
+Prevent the tps6586x interrupt handler from executing on exiting suspend
+before the i2c controller has been resumed by disabling the tps6586x
+interrupt on entering suspend and re-enabling it on resuming from
+suspend.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
+Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
+Tested-by: Dmitry Osipenko <digetx@gmail.com>
+Acked-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mfd/tps6586x.c | 24 ++++++++++++++++++++++++
+ 1 file changed, 24 insertions(+)
+
+--- a/drivers/mfd/tps6586x.c
++++ b/drivers/mfd/tps6586x.c
+@@ -594,6 +594,29 @@ static int tps6586x_i2c_remove(struct i2
+ return 0;
+ }
+
++static int __maybe_unused tps6586x_i2c_suspend(struct device *dev)
++{
++ struct tps6586x *tps6586x = dev_get_drvdata(dev);
++
++ if (tps6586x->client->irq)
++ disable_irq(tps6586x->client->irq);
++
++ return 0;
++}
++
++static int __maybe_unused tps6586x_i2c_resume(struct device *dev)
++{
++ struct tps6586x *tps6586x = dev_get_drvdata(dev);
++
++ if (tps6586x->client->irq)
++ enable_irq(tps6586x->client->irq);
++
++ return 0;
++}
++
++static SIMPLE_DEV_PM_OPS(tps6586x_pm_ops, tps6586x_i2c_suspend,
++ tps6586x_i2c_resume);
++
+ static const struct i2c_device_id tps6586x_id_table[] = {
+ { "tps6586x", 0 },
+ { },
+@@ -604,6 +627,7 @@ static struct i2c_driver tps6586x_driver
+ .driver = {
+ .name = "tps6586x",
+ .of_match_table = of_match_ptr(tps6586x_of_match),
++ .pm = &tps6586x_pm_ops,
+ },
+ .probe = tps6586x_i2c_probe,
+ .remove = tps6586x_i2c_remove,
--- /dev/null
+From 5a9372f751b5350e0ce3d2ee91832f1feae2c2e5 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Thu, 10 Jan 2019 17:24:31 +0100
+Subject: mips: fix n32 compat_ipc_parse_version
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 5a9372f751b5350e0ce3d2ee91832f1feae2c2e5 upstream.
+
+While reading through the sysvipc implementation, I noticed that the n32
+semctl/shmctl/msgctl system calls behave differently based on whether
+o32 support is enabled or not: Without o32, the IPC_64 flag passed by
+user space is rejected but calls without that flag get IPC_64 behavior.
+
+As far as I can tell, this was inadvertently changed by a cleanup patch
+but never noticed by anyone, possibly nobody has tried using sysvipc
+on n32 after linux-3.19.
+
+Change it back to the old behavior now.
+
+Fixes: 78aaf956ba3a ("MIPS: Compat: Fix build error if CONFIG_MIPS32_COMPAT but no compat ABI.")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Paul Burton <paul.burton@mips.com>
+Cc: linux-mips@vger.kernel.org
+Cc: stable@vger.kernel.org # 3.19+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/mips/Kconfig
++++ b/arch/mips/Kconfig
+@@ -2972,6 +2972,7 @@ config MIPS32_O32
+ config MIPS32_N32
+ bool "Kernel support for n32 binaries"
+ depends on 64BIT
++ select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
+ select COMPAT
+ select MIPS32_COMPAT
+ select SYSVIPC_COMPAT if SYSVIPC
--- /dev/null
+From a01421e4484327fe44f8e126793ed5a48a221e24 Mon Sep 17 00:00:00 2001
+From: Vlad Tsyrklevich <vlad@tsyrklevich.net>
+Date: Fri, 11 Jan 2019 14:34:38 +0100
+Subject: omap2fb: Fix stack memory disclosure
+
+From: Vlad Tsyrklevich <vlad@tsyrklevich.net>
+
+commit a01421e4484327fe44f8e126793ed5a48a221e24 upstream.
+
+Using [1] for static analysis I found that the OMAPFB_QUERY_PLANE,
+OMAPFB_GET_COLOR_KEY, OMAPFB_GET_DISPLAY_INFO, and OMAPFB_GET_VRAM_INFO
+cases could all leak uninitialized stack memory--either due to
+uninitialized padding or 'reserved' fields.
+
+Fix them by clearing the shared union used to store copied out data.
+
+[1] https://github.com/vlad902/kernel-uninitialized-memory-checker
+
+Signed-off-by: Vlad Tsyrklevich <vlad@tsyrklevich.net>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Fixes: b39a982ddecf ("OMAP: DSS2: omapfb driver")
+Cc: security@kernel.org
+[b.zolnierkie: prefix patch subject with "omap2fb: "]
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
++++ b/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c
+@@ -609,6 +609,8 @@ int omapfb_ioctl(struct fb_info *fbi, un
+
+ int r = 0;
+
++ memset(&p, 0, sizeof(p));
++
+ switch (cmd) {
+ case OMAPFB_SYNC_GFX:
+ DBG("ioctl SYNC_GFX\n");
btrfs-wait-on-ordered-extents-on-abort-cleanup.patch
yama-check-for-pid-death-before-checking-ancestry.patch
scsi-sd-fix-cache_type_store.patch
+mips-fix-n32-compat_ipc_parse_version.patch
+mfd-tps6586x-handle-interrupts-on-suspend.patch
+disable-msi-also-when-pcie-octeon.pcie_disable-on.patch
+omap2fb-fix-stack-memory-disclosure.patch
+media-vivid-fix-error-handling-of-kthread_run.patch
+media-vivid-set-min-width-height-to-a-value-0.patch
+lsm-check-for-null-cred-security-on-free.patch
+media-vb2-vb2_mmap-move-lock-up.patch
+sunrpc-handle-enomem-in-rpcb_getport_async.patch
--- /dev/null
+From 81c88b18de1f11f70c97f28ced8d642c00bb3955 Mon Sep 17 00:00:00 2001
+From: "J. Bruce Fields" <bfields@redhat.com>
+Date: Thu, 20 Dec 2018 10:35:11 -0500
+Subject: sunrpc: handle ENOMEM in rpcb_getport_async
+
+From: J. Bruce Fields <bfields@redhat.com>
+
+commit 81c88b18de1f11f70c97f28ced8d642c00bb3955 upstream.
+
+If we ignore the error we'll hit a null dereference a little later.
+
+Reported-by: syzbot+4b98281f2401ab849f4b@syzkaller.appspotmail.com
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/sunrpc/rpcb_clnt.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/net/sunrpc/rpcb_clnt.c
++++ b/net/sunrpc/rpcb_clnt.c
+@@ -772,6 +772,12 @@ void rpcb_getport_async(struct rpc_task
+ case RPCBVERS_3:
+ map->r_netid = xprt->address_strings[RPC_DISPLAY_NETID];
+ map->r_addr = rpc_sockaddr2uaddr(sap, GFP_ATOMIC);
++ if (!map->r_addr) {
++ status = -ENOMEM;
++ dprintk("RPC: %5u %s: no memory available\n",
++ task->tk_pid, __func__);
++ goto bailout_free_args;
++ }
+ map->r_owner = "";
+ break;
+ case RPCBVERS_2:
+@@ -794,6 +800,8 @@ void rpcb_getport_async(struct rpc_task
+ rpc_put_task(child);
+ return;
+
++bailout_free_args:
++ kfree(map);
+ bailout_release_client:
+ rpc_release_client(rpcb_clnt);
+ bailout_nofree:
projects / thirdparty / kernel / stable-queue.git / commitdiff
