- Linux-stable-mirror - lists.linaro.org

[iw_cxgb4 linux-4.14.y] iw_cxgb4: only allow 1 flush on user qps

by Steve Wise

commit 308aa2b8f7b7db3332a7d41099fd37851fb793b2 upstream Once the qp has been flushed, it cannot be flushed again. The user qp flush logic wasn't enforcing it however. The bug can cause touch-after-free crashes like: Unable to handle kernel paging request for data at address 0x000001ec Faulting instruction address: 0xc008000016069100 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c008000016069100] flush_qp+0x80/0x480 [iw_cxgb4] LR [c00800001606cd6c] c4iw_modify_qp+0x71c/0x11d0 [iw_cxgb4] Call Trace: [c00800001606cd6c] c4iw_modify_qp+0x71c/0x11d0 [iw_cxgb4] [c00800001606e868] c4iw_ib_modify_qp+0x118/0x200 [iw_cxgb4] [c0080000119eae80] ib_security_modify_qp+0xd0/0x3d0 [ib_core] [c0080000119c4e24] ib_modify_qp+0xc4/0x2c0 [ib_core] [c008000011df0284] iwcm_modify_qp_err+0x44/0x70 [iw_cm] [c008000011df0fec] destroy_cm_id+0xcc/0x370 [iw_cm] [c008000011ed4358] rdma_destroy_id+0x3c8/0x520 [rdma_cm] [c0080000134b0540] ucma_close+0x90/0x1b0 [rdma_ucm] [c000000000444da4] __fput+0xe4/0x2f0 So fix flush_qp() to only flush the wq once. Cc: stable(a)vger.kernel.org Signed-off-by: Steve Wise <swise(a)opengridcomputing.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> --- drivers/infiniband/hw/cxgb4/qp.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/infiniband/hw/cxgb4/qp.c b/drivers/infiniband/hw/cxgb4/qp.c index a8a8f65a1e51..24952af51a54 100644 --- a/drivers/infiniband/hw/cxgb4/qp.c +++ b/drivers/infiniband/hw/cxgb4/qp.c @@ -1395,6 +1395,12 @@ static void flush_qp(struct c4iw_qp *qhp) schp = to_c4iw_cq(qhp->ibqp.send_cq); if (qhp->ibqp.uobject) { + + /* for user qps, qhp->wq.flushed is protected by qhp->mutex */ + if (qhp->wq.flushed) + return; + + qhp->wq.flushed = 1; t4_set_wq_in_error(&qhp->wq); t4_set_cq_in_error(&rchp->cq); spin_lock_irqsave(&rchp->comp_handler_lock, flag); -- 1.8.3.1

7 years, 3 months

2
2
0 0

v3.18.123 build: 0 failures 1 warnings (v3.18.123)

by Build bot for Mark Brown

Tree/Branch: v3.18.123 Git describe: v3.18.123 Commit: 921b2fed6a Linux 3.18.123 Build Time: 49 min 27 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 1 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 7 warnings 0 mismatches : x86_64-allmodconfig 2 warnings 0 mismatches : x86_64-defconfig ------------------------------------------------------------------------------- Warnings Summary: 1 9 ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allmodconfig : PASS, 0 errors, 7 warnings, 0 section mismatches Warnings: ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ------------------------------------------------------------------------------- x86_64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm64-defconfig

7 years, 3 months

1
0
0 0

[PULL 2/2] virtio/s390: fix race in ccw_io_helper()

by Cornelia Huck

From: Halil Pasic <pasic(a)linux.ibm.com> While ccw_io_helper() seems like intended to be exclusive in a sense that it is supposed to facilitate I/O for at most one thread at any given time, there is actually nothing ensuring that threads won't pile up at vcdev->wait_q. If they do, all threads get woken up and see the status that belongs to some other request than their own. This can lead to bugs. For an example see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432 This race normally does not cause any problems. The operations provided by struct virtio_config_ops are usually invoked in a well defined sequence, normally don't fail, and are normally used quite infrequent too. Yet, if some of the these operations are directly triggered via sysfs attributes, like in the case described by the referenced bug, userspace is given an opportunity to force races by increasing the frequency of the given operations. Let us fix the problem by ensuring, that for each device, we finish processing the previous request before starting with a new one. Signed-off-by: Halil Pasic <pasic(a)linux.ibm.com> Reported-by: Colin Ian King <colin.king(a)canonical.com> Cc: stable(a)vger.kernel.org Message-Id: <20180925121309.58524-3-pasic(a)linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck(a)redhat.com> --- drivers/s390/virtio/virtio_ccw.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index a5e8530a3391..b67dc4974f23 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -56,6 +56,7 @@ struct virtio_ccw_device { unsigned int revision; /* Transport revision */ wait_queue_head_t wait_q; spinlock_t lock; + struct mutex io_lock; /* Serializes I/O requests */ struct list_head virtqueues; unsigned long indicators; unsigned long indicators2; @@ -296,6 +297,7 @@ static int ccw_io_helper(struct virtio_ccw_device *vcdev, unsigned long flags; int flag = intparm & VIRTIO_CCW_INTPARM_MASK; + mutex_lock(&vcdev->io_lock); do { spin_lock_irqsave(get_ccwdev_lock(vcdev->cdev), flags); ret = ccw_device_start(vcdev->cdev, ccw, intparm, 0, 0); @@ -308,7 +310,9 @@ static int ccw_io_helper(struct virtio_ccw_device *vcdev, cpu_relax(); } while (ret == -EBUSY); wait_event(vcdev->wait_q, doing_io(vcdev, flag) == 0); - return ret ? ret : vcdev->err; + ret = ret ? ret : vcdev->err; + mutex_unlock(&vcdev->io_lock); + return ret; } static void virtio_ccw_drop_indicator(struct virtio_ccw_device *vcdev, @@ -1253,6 +1257,7 @@ static int virtio_ccw_online(struct ccw_device *cdev) init_waitqueue_head(&vcdev->wait_q); INIT_LIST_HEAD(&vcdev->virtqueues); spin_lock_init(&vcdev->lock); + mutex_init(&vcdev->io_lock); spin_lock_irqsave(get_ccwdev_lock(cdev), flags); dev_set_drvdata(&cdev->dev, vcdev); -- 2.14.4

7 years, 3 months

1
0
0 0

[PULL 1/2] virtio/s390: avoid race on vcdev->config

by Cornelia Huck

From: Halil Pasic <pasic(a)linux.ibm.com> Currently we have a race on vcdev->config in virtio_ccw_get_config() and in virtio_ccw_set_config(). This normally does not cause problems, as these are usually infrequent operations. However, for some devices writing to/reading from the config space can be triggered through sysfs attributes. For these, userspace can force the race by increasing the frequency. Signed-off-by: Halil Pasic <pasic(a)linux.ibm.com> Cc: stable(a)vger.kernel.org Message-Id: <20180925121309.58524-2-pasic(a)linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck(a)redhat.com> --- drivers/s390/virtio/virtio_ccw.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index 8f5c1d7f751a..a5e8530a3391 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -828,6 +828,7 @@ static void virtio_ccw_get_config(struct virtio_device *vdev, int ret; struct ccw1 *ccw; void *config_area; + unsigned long flags; ccw = kzalloc(sizeof(*ccw), GFP_DMA | GFP_KERNEL); if (!ccw) @@ -846,11 +847,13 @@ static void virtio_ccw_get_config(struct virtio_device *vdev, if (ret) goto out_free; + spin_lock_irqsave(&vcdev->lock, flags); memcpy(vcdev->config, config_area, offset + len); - if (buf) - memcpy(buf, &vcdev->config[offset], len); if (vcdev->config_ready < offset + len) vcdev->config_ready = offset + len; + spin_unlock_irqrestore(&vcdev->lock, flags); + if (buf) + memcpy(buf, config_area + offset, len); out_free: kfree(config_area); @@ -864,6 +867,7 @@ static void virtio_ccw_set_config(struct virtio_device *vdev, struct virtio_ccw_device *vcdev = to_vc_device(vdev); struct ccw1 *ccw; void *config_area; + unsigned long flags; ccw = kzalloc(sizeof(*ccw), GFP_DMA | GFP_KERNEL); if (!ccw) @@ -876,9 +880,11 @@ static void virtio_ccw_set_config(struct virtio_device *vdev, /* Make sure we don't overwrite fields. */ if (vcdev->config_ready < offset) virtio_ccw_get_config(vdev, 0, NULL, offset); + spin_lock_irqsave(&vcdev->lock, flags); memcpy(&vcdev->config[offset], buf, len); /* Write the config area to the host. */ memcpy(config_area, vcdev->config, sizeof(vcdev->config)); + spin_unlock_irqrestore(&vcdev->lock, flags); ccw->cmd_code = CCW_CMD_WRITE_CONF; ccw->flags = 0; ccw->count = offset + len; -- 2.14.4

7 years, 3 months

1
0
0 0

[PATCH] DRM: VBLANK: provide valid timestamp for EVENT_FLIP

by Eugeniy Paltsev

If driver/HW doesn't support vblank functionality (for example UDL driver, ARCPGU driver, ...) we always have vblank->time == 0. In result we always provide zero timestamp for DRM_EVENT_FLIP_COMPLETE. This breaks userspace apps (for example weston) which relies on timestamp value. Setup time to provide valid timestamp for DRM_EVENT_FLIP_COMPLETE event. Cc: stable(a)vger.kernel.org Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> --- drivers/gpu/drm/drm_vblank.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 28cdcf76b6f9..0d19aca48782 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -911,6 +911,15 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc, if (dev->num_crtcs > 0) { seq = drm_vblank_count_and_time(dev, pipe, &now); + + /* + * If driver/HW doesn't support vblank functionality we + * always have vblank->time == 0. Setup time to provide valid + * timestamp for DRM_EVENT_FLIP_COMPLETE event. + */ + if (!now && e->event.base.type == DRM_EVENT_FLIP_COMPLETE) + now = ktime_get(); + } else { seq = 0; -- 2.14.4

7 years, 3 months

2
1
0 0

[PATCH] fbdev/omapfb: fix omapfb_memory_read infoleak

by Tomi Valkeinen

OMAPFB_MEMORY_READ ioctl reads pixels from the LCD's memory and copies them to a userspace buffer. The code has two issues: - The user provided width and height could be large enough to overflow the calculations - The copy_to_user() can copy uninitialized memory to the userspace, which might contain sensitive kernel information. Fix these by limiting the width & height parameters, and only copying the amount of data that we actually received from the LCD. Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Reported-by: Jann Horn <jannh(a)google.com> Cc: stable(a)vger.kernel.org Cc: security(a)kernel.org Cc: Will Deacon <will.deacon(a)arm.com> Cc: Jann Horn <jannh(a)google.com> Cc: Tony Lindgren <tony(a)atomide.com> --- drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c b/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c index ef69273074ba..a3edb20ea4c3 100644 --- a/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c +++ b/drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c @@ -496,6 +496,9 @@ static int omapfb_memory_read(struct fb_info *fbi, if (!access_ok(VERIFY_WRITE, mr->buffer, mr->buffer_size)) return -EFAULT; + if (mr->w > 4096 || mr->h > 4096) + return -EINVAL; + if (mr->w * mr->h * 3 > mr->buffer_size) return -EINVAL; @@ -509,7 +512,7 @@ static int omapfb_memory_read(struct fb_info *fbi, mr->x, mr->y, mr->w, mr->h); if (r > 0) { - if (copy_to_user(mr->buffer, buf, mr->buffer_size)) + if (copy_to_user(mr->buffer, buf, r)) r = -EFAULT; } -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

7 years, 3 months

3
2
0 0

FAILED: patch "[PATCH] ext4: close race between direct IO and ext4_break_layouts()" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From b1f382178d150f256c1cf95b9341fda6eb764459 Mon Sep 17 00:00:00 2001 From: Ross Zwisler <zwisler(a)kernel.org> Date: Tue, 11 Sep 2018 13:31:16 -0400 Subject: [PATCH] ext4: close race between direct IO and ext4_break_layouts() If the refcount of a page is lowered between the time that it is returned by dax_busy_page() and when the refcount is again checked in ext4_break_layouts() => ___wait_var_event(), the waiting function ext4_wait_dax_page() will never be called. This means that ext4_break_layouts() will still have 'retry' set to false, so we'll stop looping and never check the refcount of other pages in this inode. Instead, always continue looping as long as dax_layout_busy_page() gives us a page which it found with an elevated refcount. Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Cc: stable(a)vger.kernel.org diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 694f31364206..723058bfe43b 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4195,9 +4195,8 @@ int ext4_update_disksize_before_punch(struct inode *inode, loff_t offset, return 0; } -static void ext4_wait_dax_page(struct ext4_inode_info *ei, bool *did_unlock) +static void ext4_wait_dax_page(struct ext4_inode_info *ei) { - *did_unlock = true; up_write(&ei->i_mmap_sem); schedule(); down_write(&ei->i_mmap_sem); @@ -4207,14 +4206,12 @@ int ext4_break_layouts(struct inode *inode) { struct ext4_inode_info *ei = EXT4_I(inode); struct page *page; - bool retry; int error; if (WARN_ON_ONCE(!rwsem_is_locked(&ei->i_mmap_sem))) return -EINVAL; do { - retry = false; page = dax_layout_busy_page(inode->i_mapping); if (!page) return 0; @@ -4222,8 +4219,8 @@ int ext4_break_layouts(struct inode *inode) error = ___wait_var_event(&page->_refcount, atomic_read(&page->_refcount) == 1, TASK_INTERRUPTIBLE, 0, 0, - ext4_wait_dax_page(ei, &retry)); - } while (error == 0 && retry); + ext4_wait_dax_page(ei)); + } while (error == 0); return error; }

7 years, 3 months

2
1
0 0

[PATCH] drm/syncobj: Don't leak fences when WAIT_FOR_SUBMIT is set

by Jason Ekstrand

We attempt to get fences earlier in the hopes that everything will already have fences and no callbacks will be needed. If we do succeed in getting a fence, getting one a second time will result in a duplicate ref with no unref. This is causing memory leaks in Vulkan applications that create a lot of fences; playing for a few hours can, apparently, bring down the system. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107899 Signed-off-by: Jason Ekstrand <jason(a)jlekstrand.net> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/drm_syncobj.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index adb3cb27d31e..759278fef35a 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -97,6 +97,8 @@ static int drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj, { int ret; + WARN_ON(*fence); + *fence = drm_syncobj_fence_get(syncobj); if (*fence) return 1; @@ -743,6 +745,9 @@ static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs, if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) { for (i = 0; i < count; ++i) { + if (entries[i].fence) + continue; + drm_syncobj_fence_get_or_add_callback(syncobjs[i], &entries[i].fence, &entries[i].syncobj_cb, -- 2.17.1

7 years, 3 months

3
2
0 0

[PATCH] drm/i915/fbc: Disable fbc with VT-d also with kbl and cfl

by Mika Kuoppala

Using fbc with VT-d flickers also on kbl and cfl. Cc: Paulo Zanoni <paulo.r.zanoni(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: <stable(a)vger.kernel.org> # v4.9+ Signed-off-by: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> --- drivers/gpu/drm/i915/intel_fbc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c index 74d425c700ef..a149f08c1b79 100644 --- a/drivers/gpu/drm/i915/intel_fbc.c +++ b/drivers/gpu/drm/i915/intel_fbc.c @@ -1275,9 +1275,10 @@ static int intel_sanitize_fbc_option(struct drm_i915_private *dev_priv) static bool need_fbc_vtd_wa(struct drm_i915_private *dev_priv) { - /* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */ + /* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt,kbl,cfl */ if (intel_vtd_active() && - (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))) { + (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv) || + IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv))) { DRM_INFO("Disabling framebuffer compression (FBC) to prevent screen flicker with VT-d enabled\n"); return true; } -- 2.17.1

7 years, 3 months

3
3
0 0

[PATCH stable v4.14] PCI: aardvark: Size bridges before resources allocation

by Thomas Petazzoni

From: Zachary Zhang <zhangzg(a)marvell.com> commit 91a2968e245d6ba616db37001fa1a043078b1a65 usptream. The PCIE I/O and MEM resource allocation mechanism is that root bus goes through the following steps: 1. Check PCI bridges' range and computes I/O and Mem base/limits. 2. Sort all subordinate devices I/O and MEM resource requirements and allocate the resources and writes/updates subordinate devices' requirements to PCI bridges I/O and Mem MEM/limits registers. Currently, PCI Aardvark driver only handles the second step and lacks the first step, so there is an I/O and MEM resource allocation failure when using a PCI switch. This commit fixes that by sizing bridges before doing the resource allocation. Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Zachary Zhang <zhangzg(a)marvell.com> [Thomas: edit commit log.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Cc: <stable(a)vger.kernel.org> --- drivers/pci/host/pci-aardvark.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c index 9bfc22b5da4b..5f3048e75bec 100644 --- a/drivers/pci/host/pci-aardvark.c +++ b/drivers/pci/host/pci-aardvark.c @@ -954,6 +954,7 @@ static int advk_pcie_probe(struct platform_device *pdev) bus = bridge->bus; + pci_bus_size_bridges(bus); pci_bus_assign_resources(bus); list_for_each_entry(child, &bus->children, node) -- 2.14.4

7 years, 3 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror