From: Sasha Levin Date: Sun, 28 Jul 2019 19:12:23 +0000 (-0400) Subject: fixes for 4.14 X-Git-Tag: v5.2.5~24 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8bfeba3f0eb8ddf2899f9a07126c905f17e3c0b3;p=thirdparty%2Fkernel%2Fstable-queue.git fixes for 4.14 Signed-off-by: Sasha Levin --- diff --git a/queue-4.14/9p-pass-the-correct-prototype-to-read_cache_page.patch b/queue-4.14/9p-pass-the-correct-prototype-to-read_cache_page.patch new file mode 100644 index 00000000000..74215d720f3 --- /dev/null +++ b/queue-4.14/9p-pass-the-correct-prototype-to-read_cache_page.patch @@ -0,0 +1,51 @@ +From a1a33827a84d13d0219cd339e3ccf3630b042a64 Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Thu, 11 Jul 2019 20:55:26 -0700 +Subject: 9p: pass the correct prototype to read_cache_page + +[ Upstream commit f053cbd4366051d7eb6ba1b8d529d20f719c2963 ] + +Fix the callback 9p passes to read_cache_page to actually have the +proper type expected. Casting around function pointers can easily +hide typing bugs, and defeats control flow protection. + +Link: http://lkml.kernel.org/r/20190520055731.24538-5-hch@lst.de +Signed-off-by: Christoph Hellwig +Reviewed-by: Kees Cook +Cc: Sami Tolvanen +Cc: Nick Desaulniers +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + fs/9p/vfs_addr.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c +index e1cbdfdb7c68..197069303510 100644 +--- a/fs/9p/vfs_addr.c ++++ b/fs/9p/vfs_addr.c +@@ -50,8 +50,9 @@ + * @page: structure to page + * + */ +-static int v9fs_fid_readpage(struct p9_fid *fid, struct page *page) ++static int v9fs_fid_readpage(void *data, struct page *page) + { ++ struct p9_fid *fid = data; + struct inode *inode = page->mapping->host; + struct bio_vec bvec = {.bv_page = page, .bv_len = PAGE_SIZE}; + struct iov_iter to; +@@ -122,7 +123,8 @@ static int v9fs_vfs_readpages(struct file *filp, struct address_space *mapping, + if (ret == 0) + return ret; + +- ret = read_cache_pages(mapping, pages, (void *)v9fs_vfs_readpage, filp); ++ ret = read_cache_pages(mapping, pages, v9fs_fid_readpage, ++ filp->private_data); + p9_debug(P9_DEBUG_VFS, " = %d\n", ret); + return ret; + } +-- +2.20.1 + diff --git a/queue-4.14/block-bio-integrity-fix-a-memory-leak-bug.patch b/queue-4.14/block-bio-integrity-fix-a-memory-leak-bug.patch new file mode 100644 index 00000000000..0ed84de6472 --- /dev/null +++ b/queue-4.14/block-bio-integrity-fix-a-memory-leak-bug.patch @@ -0,0 +1,50 @@ +From c25fc3f5fcd57b12e985399728ef0e16321b9ccc Mon Sep 17 00:00:00 2001 +From: Wenwen Wang +Date: Thu, 11 Jul 2019 14:22:02 -0500 +Subject: block/bio-integrity: fix a memory leak bug + +[ Upstream commit e7bf90e5afe3aa1d1282c1635a49e17a32c4ecec ] + +In bio_integrity_prep(), a kernel buffer is allocated through kmalloc() to +hold integrity metadata. Later on, the buffer will be attached to the bio +structure through bio_integrity_add_page(), which returns the number of +bytes of integrity metadata attached. Due to unexpected situations, +bio_integrity_add_page() may return 0. As a result, bio_integrity_prep() +needs to be terminated with 'false' returned to indicate this error. +However, the allocated kernel buffer is not freed on this execution path, +leading to a memory leak. + +To fix this issue, free the allocated buffer before returning from +bio_integrity_prep(). + +Reviewed-by: Ming Lei +Acked-by: Martin K. Petersen +Signed-off-by: Wenwen Wang +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + block/bio-integrity.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +diff --git a/block/bio-integrity.c b/block/bio-integrity.c +index 5df32907ff3b..7f8010662437 100644 +--- a/block/bio-integrity.c ++++ b/block/bio-integrity.c +@@ -313,8 +313,12 @@ bool bio_integrity_prep(struct bio *bio) + ret = bio_integrity_add_page(bio, virt_to_page(buf), + bytes, offset); + +- if (ret == 0) +- return false; ++ if (ret == 0) { ++ printk(KERN_ERR "could not attach integrity payload\n"); ++ kfree(buf); ++ status = BLK_STS_RESOURCE; ++ goto err_end_io; ++ } + + if (ret < bytes) + break; +-- +2.20.1 + diff --git a/queue-4.14/drm-bridge-sii902x-pixel-clock-unit-is-10khz-instead.patch b/queue-4.14/drm-bridge-sii902x-pixel-clock-unit-is-10khz-instead.patch new file mode 100644 index 00000000000..c0161371696 --- /dev/null +++ b/queue-4.14/drm-bridge-sii902x-pixel-clock-unit-is-10khz-instead.patch @@ -0,0 +1,42 @@ +From 4e3fdcddaf13028f8cd6a95549e13fb44aa1d391 Mon Sep 17 00:00:00 2001 +From: Jyri Sarha +Date: Mon, 27 May 2019 16:47:54 +0300 +Subject: drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz + +[ Upstream commit 8dbfc5b65023b67397aca28e8adb25c819f6398c ] + +The pixel clock unit in the first two registers (0x00 and 0x01) of +sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by +10 fixes the issue. + +Signed-off-by: Jyri Sarha +Reviewed-by: Andrzej Hajda +Reviewed-by: Laurent Pinchart +Signed-off-by: Andrzej Hajda +Link: https://patchwork.freedesktop.org/patch/msgid/1a2a8eae0b9d6333e7a5841026bf7fd65c9ccd09.1558964241.git.jsarha@ti.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/bridge/sii902x.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c +index 60373d7eb220..109ab4c3df50 100644 +--- a/drivers/gpu/drm/bridge/sii902x.c ++++ b/drivers/gpu/drm/bridge/sii902x.c +@@ -261,10 +261,11 @@ static void sii902x_bridge_mode_set(struct drm_bridge *bridge, + struct regmap *regmap = sii902x->regmap; + u8 buf[HDMI_INFOFRAME_SIZE(AVI)]; + struct hdmi_avi_infoframe frame; ++ u16 pixel_clock_10kHz = adj->clock / 10; + int ret; + +- buf[0] = adj->clock; +- buf[1] = adj->clock >> 8; ++ buf[0] = pixel_clock_10kHz & 0xff; ++ buf[1] = pixel_clock_10kHz >> 8; + buf[2] = adj->vrefresh; + buf[3] = 0x00; + buf[4] = adj->hdisplay; +-- +2.20.1 + diff --git a/queue-4.14/drm-bridge-tc358767-read-display_props-in-get_modes.patch b/queue-4.14/drm-bridge-tc358767-read-display_props-in-get_modes.patch new file mode 100644 index 00000000000..21b8476c890 --- /dev/null +++ b/queue-4.14/drm-bridge-tc358767-read-display_props-in-get_modes.patch @@ -0,0 +1,44 @@ +From b02a89a3d4046e8b35f12ec4d5cfa8e569cf14d2 Mon Sep 17 00:00:00 2001 +From: Tomi Valkeinen +Date: Tue, 28 May 2019 11:27:44 +0300 +Subject: drm/bridge: tc358767: read display_props in get_modes() + +[ Upstream commit 3231573065ad4f4ecc5c9147b24f29f846dc0c2f ] + +We need to know the link bandwidth to filter out modes we cannot +support, so we need to have read the display props before doing the +filtering. + +To ensure we have up to date display props, call tc_get_display_props() +in the beginning of tc_connector_get_modes(). + +Signed-off-by: Tomi Valkeinen +Reviewed-by: Andrzej Hajda +Signed-off-by: Andrzej Hajda +Link: https://patchwork.freedesktop.org/patch/msgid/20190528082747.3631-22-tomi.valkeinen@ti.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/bridge/tc358767.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c +index 6eebd8ad0c52..9705ca197b90 100644 +--- a/drivers/gpu/drm/bridge/tc358767.c ++++ b/drivers/gpu/drm/bridge/tc358767.c +@@ -1147,6 +1147,13 @@ static int tc_connector_get_modes(struct drm_connector *connector) + struct tc_data *tc = connector_to_tc(connector); + struct edid *edid; + unsigned int count; ++ int ret; ++ ++ ret = tc_get_display_props(tc); ++ if (ret < 0) { ++ dev_err(tc->dev, "failed to read display props: %d\n", ret); ++ return 0; ++ } + + if (tc->panel && tc->panel->funcs && tc->panel->funcs->get_modes) { + count = tc->panel->funcs->get_modes(tc->panel); +-- +2.20.1 + diff --git a/queue-4.14/drm-crc-debugfs-also-sprinkle-irqrestore-over-early-.patch b/queue-4.14/drm-crc-debugfs-also-sprinkle-irqrestore-over-early-.patch new file mode 100644 index 00000000000..06e98c08207 --- /dev/null +++ b/queue-4.14/drm-crc-debugfs-also-sprinkle-irqrestore-over-early-.patch @@ -0,0 +1,54 @@ +From bde47afe25c3bd879974031d773f07b920d0d89a Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Thu, 6 Jun 2019 23:15:44 +0200 +Subject: drm/crc-debugfs: Also sprinkle irqrestore over early exits +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit d99004d7201aa653658ff2390d6e516567c96ebc ] + +I. was. blind. + +Caught with vkms, which has some really slow crc computation function. + +Fixes: 1882018a70e0 ("drm/crc-debugfs: User irqsafe spinlock in drm_crtc_add_crc_entry") +Cc: Rodrigo Siqueira +Cc: Tomeu Vizoso +Cc: Emil Velikov +Cc: Benjamin Gaignard +Cc: Ville Syrjälä +Reviewed-by: Emil Velikov +Reviewed-by: Benjamin Gaignard +Signed-off-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20190606211544.5389-1-daniel.vetter@ffwll.ch +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/drm_debugfs_crc.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c +index f689c75474e5..2901b7944068 100644 +--- a/drivers/gpu/drm/drm_debugfs_crc.c ++++ b/drivers/gpu/drm/drm_debugfs_crc.c +@@ -366,7 +366,7 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool has_frame, + + /* Caller may not have noticed yet that userspace has stopped reading */ + if (!crc->entries) { +- spin_unlock(&crc->lock); ++ spin_unlock_irqrestore(&crc->lock, flags); + return -EINVAL; + } + +@@ -377,7 +377,7 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool has_frame, + bool was_overflow = crc->overflow; + + crc->overflow = true; +- spin_unlock(&crc->lock); ++ spin_unlock_irqrestore(&crc->lock, flags); + + if (!was_overflow) + DRM_ERROR("Overflow of CRC buffer, userspace reads too slow.\n"); +-- +2.20.1 + diff --git a/queue-4.14/drm-crc-debugfs-user-irqsafe-spinlock-in-drm_crtc_ad.patch b/queue-4.14/drm-crc-debugfs-user-irqsafe-spinlock-in-drm_crtc_ad.patch new file mode 100644 index 00000000000..92a7f84f46e --- /dev/null +++ b/queue-4.14/drm-crc-debugfs-user-irqsafe-spinlock-in-drm_crtc_ad.patch @@ -0,0 +1,55 @@ +From 1f93ff3ff7ab3359130becb16f635e3ed89f2d27 Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Wed, 5 Jun 2019 21:45:56 +0200 +Subject: drm/crc-debugfs: User irqsafe spinlock in drm_crtc_add_crc_entry +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit 1882018a70e06376234133e69ede9dd743b4dbd9 ] + +We can be called from any context, we need to be prepared. + +Noticed this while hacking on vkms, which calls this function from a +normal worker. Which really upsets lockdep. + +Cc: Rodrigo Siqueira +Cc: Tomeu Vizoso +Cc: Emil Velikov +Cc: Benjamin Gaignard +Reviewed-by: Benjamin Gaignard +Reviewed-by: Ville Syrjälä +Signed-off-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20190605194556.16744-1-daniel.vetter@ffwll.ch +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/drm_debugfs_crc.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c +index f9e26dda56d6..021813b20e97 100644 +--- a/drivers/gpu/drm/drm_debugfs_crc.c ++++ b/drivers/gpu/drm/drm_debugfs_crc.c +@@ -359,8 +359,9 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool has_frame, + struct drm_crtc_crc *crc = &crtc->crc; + struct drm_crtc_crc_entry *entry; + int head, tail; ++ unsigned long flags; + +- spin_lock(&crc->lock); ++ spin_lock_irqsave(&crc->lock, flags); + + /* Caller may not have noticed yet that userspace has stopped reading */ + if (!crc->entries) { +@@ -385,7 +386,7 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool has_frame, + head = (head + 1) & (DRM_CRC_ENTRIES_NR - 1); + crc->head = head; + +- spin_unlock(&crc->lock); ++ spin_unlock_irqrestore(&crc->lock, flags); + + wake_up_interruptible(&crc->wq); + +-- +2.20.1 + diff --git a/queue-4.14/drm-crc-only-report-a-single-overflow-when-a-crc-fd-.patch b/queue-4.14/drm-crc-only-report-a-single-overflow-when-a-crc-fd-.patch new file mode 100644 index 00000000000..fe265ecd694 --- /dev/null +++ b/queue-4.14/drm-crc-only-report-a-single-overflow-when-a-crc-fd-.patch @@ -0,0 +1,75 @@ +From 21d9efe928e6d38228ac2cb3bdfd1bd72b822ea2 Mon Sep 17 00:00:00 2001 +From: Maarten Lankhorst +Date: Wed, 18 Apr 2018 14:51:21 +0200 +Subject: drm/crc: Only report a single overflow when a CRC fd is opened +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit a012024571d98e2e4bf29a9168fb7ddc44b7ab86 ] + +This reduces the amount of spam when you debug a CRC reading +program. + +Signed-off-by: Maarten Lankhorst +[mlankhorst: Change bool overflow to was_overflow (Ville)] +Reviewed-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20180418125121.72081-1-maarten.lankhorst@linux.intel.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/drm_debugfs_crc.c | 9 ++++++++- + include/drm/drm_debugfs_crc.h | 3 ++- + 2 files changed, 10 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c +index 021813b20e97..f689c75474e5 100644 +--- a/drivers/gpu/drm/drm_debugfs_crc.c ++++ b/drivers/gpu/drm/drm_debugfs_crc.c +@@ -139,6 +139,7 @@ static int crtc_crc_data_count(struct drm_crtc_crc *crc) + static void crtc_crc_cleanup(struct drm_crtc_crc *crc) + { + kfree(crc->entries); ++ crc->overflow = false; + crc->entries = NULL; + crc->head = 0; + crc->tail = 0; +@@ -373,8 +374,14 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool has_frame, + tail = crc->tail; + + if (CIRC_SPACE(head, tail, DRM_CRC_ENTRIES_NR) < 1) { ++ bool was_overflow = crc->overflow; ++ ++ crc->overflow = true; + spin_unlock(&crc->lock); +- DRM_ERROR("Overflow of CRC buffer, userspace reads too slow.\n"); ++ ++ if (!was_overflow) ++ DRM_ERROR("Overflow of CRC buffer, userspace reads too slow.\n"); ++ + return -ENOBUFS; + } + +diff --git a/include/drm/drm_debugfs_crc.h b/include/drm/drm_debugfs_crc.h +index 7d63b1d4adb9..b225eeb30d05 100644 +--- a/include/drm/drm_debugfs_crc.h ++++ b/include/drm/drm_debugfs_crc.h +@@ -43,6 +43,7 @@ struct drm_crtc_crc_entry { + * @lock: protects the fields in this struct + * @source: name of the currently configured source of CRCs + * @opened: whether userspace has opened the data file for reading ++ * @overflow: whether an overflow occured. + * @entries: array of entries, with size of %DRM_CRC_ENTRIES_NR + * @head: head of circular queue + * @tail: tail of circular queue +@@ -52,7 +53,7 @@ struct drm_crtc_crc_entry { + struct drm_crtc_crc { + spinlock_t lock; + const char *source; +- bool opened; ++ bool opened, overflow; + struct drm_crtc_crc_entry *entries; + int head, tail; + size_t values_cnt; +-- +2.20.1 + diff --git a/queue-4.14/drm-edid-fix-a-missing-check-bug-in-drm_load_edid_fi.patch b/queue-4.14/drm-edid-fix-a-missing-check-bug-in-drm_load_edid_fi.patch new file mode 100644 index 00000000000..75777de0657 --- /dev/null +++ b/queue-4.14/drm-edid-fix-a-missing-check-bug-in-drm_load_edid_fi.patch @@ -0,0 +1,40 @@ +From d9fdd03033d2afab93bc5db8ae04bbd7c6a463f2 Mon Sep 17 00:00:00 2001 +From: Gen Zhang +Date: Fri, 24 May 2019 10:32:22 +0800 +Subject: drm/edid: Fix a missing-check bug in drm_load_edid_firmware() + +[ Upstream commit 9f1f1a2dab38d4ce87a13565cf4dc1b73bef3a5f ] + +In drm_load_edid_firmware(), fwstr is allocated by kstrdup(). And fwstr +is dereferenced in the following codes. However, memory allocation +functions such as kstrdup() may fail and returns NULL. Dereferencing +this null pointer may cause the kernel go wrong. Thus we should check +this kstrdup() operation. +Further, if kstrdup() returns NULL, we should return ERR_PTR(-ENOMEM) to +the caller site. + +Signed-off-by: Gen Zhang +Reviewed-by: Jani Nikula +Signed-off-by: Jani Nikula +Link: https://patchwork.freedesktop.org/patch/msgid/20190524023222.GA5302@zhanggen-UX430UQ +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/drm_edid_load.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c +index 1c0495acf341..06656acea420 100644 +--- a/drivers/gpu/drm/drm_edid_load.c ++++ b/drivers/gpu/drm/drm_edid_load.c +@@ -274,6 +274,8 @@ struct edid *drm_load_edid_firmware(struct drm_connector *connector) + * the last one found one as a fallback. + */ + fwstr = kstrdup(edid_firmware, GFP_KERNEL); ++ if (!fwstr) ++ return ERR_PTR(-ENOMEM); + edidstr = fwstr; + + while ((edidname = strsep(&edidstr, ","))) { +-- +2.20.1 + diff --git a/queue-4.14/drm-msm-depopulate-platform-on-probe-failure.patch b/queue-4.14/drm-msm-depopulate-platform-on-probe-failure.patch new file mode 100644 index 00000000000..d130629cf35 --- /dev/null +++ b/queue-4.14/drm-msm-depopulate-platform-on-probe-failure.patch @@ -0,0 +1,60 @@ +From 04b62c2654069a792911b08c8326c5db09565c42 Mon Sep 17 00:00:00 2001 +From: Sean Paul +Date: Mon, 17 Jun 2019 16:12:51 -0400 +Subject: drm/msm: Depopulate platform on probe failure + +[ Upstream commit 4368a1539c6b41ac3cddc06f5a5117952998804c ] + +add_display_components() calls of_platform_populate, and we depopluate +on pdev remove, but not when probe fails. So if we get a probe deferral +in one of the components, we won't depopulate the platform. This causes +the core to keep references to devices which should be destroyed, which +causes issues when those same devices try to re-initialize on the next +probe attempt. + +I think this is the reason we had issues with the gmu's device-managed +resources on deferral (worked around in commit 94e3a17f33a5). + +Reviewed-by: Rob Clark +Signed-off-by: Sean Paul +Link: https://patchwork.freedesktop.org/patch/msgid/20190617201301.133275-3-sean@poorly.run +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/msm/msm_drv.c | 14 +++++++++++--- + 1 file changed, 11 insertions(+), 3 deletions(-) + +diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c +index 606df7bea97b..b970427e53a7 100644 +--- a/drivers/gpu/drm/msm/msm_drv.c ++++ b/drivers/gpu/drm/msm/msm_drv.c +@@ -1097,16 +1097,24 @@ static int msm_pdev_probe(struct platform_device *pdev) + + ret = add_gpu_components(&pdev->dev, &match); + if (ret) +- return ret; ++ goto fail; + + /* on all devices that I am aware of, iommu's which can map + * any address the cpu can see are used: + */ + ret = dma_set_mask_and_coherent(&pdev->dev, ~0); + if (ret) +- return ret; ++ goto fail; ++ ++ ret = component_master_add_with_match(&pdev->dev, &msm_drm_ops, match); ++ if (ret) ++ goto fail; ++ ++ return 0; + +- return component_master_add_with_match(&pdev->dev, &msm_drm_ops, match); ++fail: ++ of_platform_depopulate(&pdev->dev); ++ return ret; + } + + static int msm_pdev_remove(struct platform_device *pdev) +-- +2.20.1 + diff --git a/queue-4.14/drm-panel-simple-fix-panel_simple_dsi_probe.patch b/queue-4.14/drm-panel-simple-fix-panel_simple_dsi_probe.patch new file mode 100644 index 00000000000..87cd92184ee --- /dev/null +++ b/queue-4.14/drm-panel-simple-fix-panel_simple_dsi_probe.patch @@ -0,0 +1,41 @@ +From 896e93d73eaa9cef4840b2c0fd48b6b789a257d4 Mon Sep 17 00:00:00 2001 +From: Peter Ujfalusi +Date: Tue, 26 Feb 2019 10:11:53 +0200 +Subject: drm/panel: simple: Fix panel_simple_dsi_probe + +[ Upstream commit 7ad9db66fafb0f0ad53fd2a66217105da5ddeffe ] + +In case mipi_dsi_attach() fails remove the registered panel to avoid added +panel without corresponding device. + +Signed-off-by: Peter Ujfalusi +Signed-off-by: Thierry Reding +Link: https://patchwork.freedesktop.org/patch/msgid/20190226081153.31334-1-peter.ujfalusi@ti.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/panel/panel-simple.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c +index fc56d033febe..7a0fd4e4e78d 100644 +--- a/drivers/gpu/drm/panel/panel-simple.c ++++ b/drivers/gpu/drm/panel/panel-simple.c +@@ -2371,7 +2371,14 @@ static int panel_simple_dsi_probe(struct mipi_dsi_device *dsi) + dsi->format = desc->format; + dsi->lanes = desc->lanes; + +- return mipi_dsi_attach(dsi); ++ err = mipi_dsi_attach(dsi); ++ if (err) { ++ struct panel_simple *panel = dev_get_drvdata(&dsi->dev); ++ ++ drm_panel_remove(&panel->base); ++ } ++ ++ return err; + } + + static int panel_simple_dsi_remove(struct mipi_dsi_device *dsi) +-- +2.20.1 + diff --git a/queue-4.14/drm-rockchip-properly-adjust-to-a-true-clock-in-adju.patch b/queue-4.14/drm-rockchip-properly-adjust-to-a-true-clock-in-adju.patch new file mode 100644 index 00000000000..88e42712ae7 --- /dev/null +++ b/queue-4.14/drm-rockchip-properly-adjust-to-a-true-clock-in-adju.patch @@ -0,0 +1,46 @@ +From d040b7a3d2d8e7a8af8c9f2d60fc710d609a9106 Mon Sep 17 00:00:00 2001 +From: Douglas Anderson +Date: Fri, 14 Jun 2019 15:47:29 -0700 +Subject: drm/rockchip: Properly adjust to a true clock in adjusted_mode + +[ Upstream commit 99b9683f2142b20bad78e61f7f829e8714e45685 ] + +When fixing up the clock in vop_crtc_mode_fixup() we're not doing it +quite correctly. Specifically if we've got the true clock 266666667 Hz, +we'll perform this calculation: + 266666667 / 1000 => 266666 + +Later when we try to set the clock we'll do clk_set_rate(266666 * +1000). The common clock framework won't actually pick the proper clock +in this case since it always wants clocks <= the specified one. + +Let's solve this by using DIV_ROUND_UP. + +Fixes: b59b8de31497 ("drm/rockchip: return a true clock rate to adjusted_mode") +Signed-off-by: Douglas Anderson +Signed-off-by: Sean Paul +Reviewed-by: Yakir Yang +Signed-off-by: Heiko Stuebner +Link: https://patchwork.freedesktop.org/patch/msgid/20190614224730.98622-1-dianders@chromium.org +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +index f1fa8d5c9b52..7010424b2f89 100644 +--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c ++++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +@@ -861,7 +861,8 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc, + struct vop *vop = to_vop(crtc); + + adjusted_mode->clock = +- clk_round_rate(vop->dclk, mode->clock * 1000) / 1000; ++ DIV_ROUND_UP(clk_round_rate(vop->dclk, mode->clock * 1000), ++ 1000); + + return true; + } +-- +2.20.1 + diff --git a/queue-4.14/drm-virtio-add-memory-barriers-for-capset-cache.patch b/queue-4.14/drm-virtio-add-memory-barriers-for-capset-cache.patch new file mode 100644 index 00000000000..24c70df34b1 --- /dev/null +++ b/queue-4.14/drm-virtio-add-memory-barriers-for-capset-cache.patch @@ -0,0 +1,50 @@ +From 1aed92904a399fbfc3fd9b869e5298ea912ee6f2 Mon Sep 17 00:00:00 2001 +From: David Riley +Date: Mon, 10 Jun 2019 14:18:10 -0700 +Subject: drm/virtio: Add memory barriers for capset cache. + +[ Upstream commit 9ff3a5c88e1f1ab17a31402b96d45abe14aab9d7 ] + +After data is copied to the cache entry, atomic_set is used indicate +that the data is the entry is valid without appropriate memory barriers. +Similarly the read side was missing the corresponding memory barriers. + +Signed-off-by: David Riley +Link: http://patchwork.freedesktop.org/patch/msgid/20190610211810.253227-5-davidriley@chromium.org +Signed-off-by: Gerd Hoffmann +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +++ + drivers/gpu/drm/virtio/virtgpu_vq.c | 2 ++ + 2 files changed, 5 insertions(+) + +diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c +index ed9c443bb8a1..40cc2f6707cf 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c ++++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c +@@ -523,6 +523,9 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev, + ret = wait_event_timeout(vgdev->resp_wq, + atomic_read(&cache_ent->is_valid), 5 * HZ); + ++ /* is_valid check must proceed before copy of the cache entry. */ ++ smp_rmb(); ++ + ptr = cache_ent->caps_cache; + + copy_exit: +diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c +index 26a2da1f712d..21c2de81f3e3 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_vq.c ++++ b/drivers/gpu/drm/virtio/virtgpu_vq.c +@@ -585,6 +585,8 @@ static void virtio_gpu_cmd_capset_cb(struct virtio_gpu_device *vgdev, + cache_ent->id == le32_to_cpu(cmd->capset_id)) { + memcpy(cache_ent->caps_cache, resp->capset_data, + cache_ent->size); ++ /* Copy must occur before is_valid is signalled. */ ++ smp_wmb(); + atomic_set(&cache_ent->is_valid, 1); + break; + } +-- +2.20.1 + diff --git a/queue-4.14/f2fs-avoid-out-of-range-memory-access.patch b/queue-4.14/f2fs-avoid-out-of-range-memory-access.patch new file mode 100644 index 00000000000..17af2bdf15c --- /dev/null +++ b/queue-4.14/f2fs-avoid-out-of-range-memory-access.patch @@ -0,0 +1,39 @@ +From 02178fade27b5f0e900ffa97684d7f953caf06ef Mon Sep 17 00:00:00 2001 +From: Ocean Chen +Date: Mon, 8 Jul 2019 12:34:56 +0800 +Subject: f2fs: avoid out-of-range memory access + +[ Upstream commit 56f3ce675103e3fb9e631cfb4131fc768bc23e9a ] + +blkoff_off might over 512 due to fs corrupt or security +vulnerability. That should be checked before being using. + +Use ENTRIES_IN_SUM to protect invalid value in cur_data_blkoff. + +Signed-off-by: Ocean Chen +Reviewed-by: Chao Yu +Signed-off-by: Jaegeuk Kim +Signed-off-by: Sasha Levin +--- + fs/f2fs/segment.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c +index 70bd15cadb44..18d51c36a5e3 100644 +--- a/fs/f2fs/segment.c ++++ b/fs/f2fs/segment.c +@@ -2612,6 +2612,11 @@ static int read_compacted_summaries(struct f2fs_sb_info *sbi) + seg_i = CURSEG_I(sbi, i); + segno = le32_to_cpu(ckpt->cur_data_segno[i]); + blk_off = le16_to_cpu(ckpt->cur_data_blkoff[i]); ++ if (blk_off > ENTRIES_IN_SUM) { ++ f2fs_bug_on(sbi, 1); ++ f2fs_put_page(page, 1); ++ return -EFAULT; ++ } + seg_i->next_segno = segno; + reset_curseg(sbi, i, 0); + seg_i->alloc_type = ckpt->alloc_type[i]; +-- +2.20.1 + diff --git a/queue-4.14/hvsock-fix-epollout-hang-from-race-condition.patch b/queue-4.14/hvsock-fix-epollout-hang-from-race-condition.patch new file mode 100644 index 00000000000..ddd0c23c4c6 --- /dev/null +++ b/queue-4.14/hvsock-fix-epollout-hang-from-race-condition.patch @@ -0,0 +1,148 @@ +From 42668be410cece7b0f831ff35946facd98e82045 Mon Sep 17 00:00:00 2001 +From: Sunil Muthuswamy +Date: Mon, 17 Jun 2019 19:26:25 +0000 +Subject: hvsock: fix epollout hang from race condition + +[ Upstream commit cb359b60416701c8bed82fec79de25a144beb893 ] + +Currently, hvsock can enter into a state where epoll_wait on EPOLLOUT will +not return even when the hvsock socket is writable, under some race +condition. This can happen under the following sequence: +- fd = socket(hvsocket) +- fd_out = dup(fd) +- fd_in = dup(fd) +- start a writer thread that writes data to fd_out with a combination of + epoll_wait(fd_out, EPOLLOUT) and +- start a reader thread that reads data from fd_in with a combination of + epoll_wait(fd_in, EPOLLIN) +- On the host, there are two threads that are reading/writing data to the + hvsocket + +stack: +hvs_stream_has_space +hvs_notify_poll_out +vsock_poll +sock_poll +ep_poll + +Race condition: +check for epollout from ep_poll(): + assume no writable space in the socket + hvs_stream_has_space() returns 0 +check for epollin from ep_poll(): + assume socket has some free space < HVS_PKT_LEN(HVS_SEND_BUF_SIZE) + hvs_stream_has_space() will clear the channel pending send size + host will not notify the guest because the pending send size has + been cleared and so the hvsocket will never mark the + socket writable + +Now, the EPOLLOUT will never return even if the socket write buffer is +empty. + +The fix is to set the pending size to the default size and never change it. +This way the host will always notify the guest whenever the writable space +is bigger than the pending size. The host is already optimized to *only* +notify the guest when the pending size threshold boundary is crossed and +not everytime. + +This change also reduces the cpu usage somewhat since hv_stream_has_space() +is in the hotpath of send: +vsock_stream_sendmsg()->hv_stream_has_space() +Earlier hv_stream_has_space was setting/clearing the pending size on every +call. + +Signed-off-by: Sunil Muthuswamy +Reviewed-by: Dexuan Cui +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/vmw_vsock/hyperv_transport.c | 44 ++++++++------------------------ + 1 file changed, 11 insertions(+), 33 deletions(-) + +diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c +index 2c63f7b169b5..3bee93bc5d11 100644 +--- a/net/vmw_vsock/hyperv_transport.c ++++ b/net/vmw_vsock/hyperv_transport.c +@@ -217,18 +217,6 @@ static void hvs_set_channel_pending_send_size(struct vmbus_channel *chan) + set_channel_pending_send_size(chan, + HVS_PKT_LEN(HVS_SEND_BUF_SIZE)); + +- /* See hvs_stream_has_space(): we must make sure the host has seen +- * the new pending send size, before we can re-check the writable +- * bytes. +- */ +- virt_mb(); +-} +- +-static void hvs_clear_channel_pending_send_size(struct vmbus_channel *chan) +-{ +- set_channel_pending_send_size(chan, 0); +- +- /* Ditto */ + virt_mb(); + } + +@@ -298,9 +286,6 @@ static void hvs_channel_cb(void *ctx) + if (hvs_channel_readable(chan)) + sk->sk_data_ready(sk); + +- /* See hvs_stream_has_space(): when we reach here, the writable bytes +- * may be already less than HVS_PKT_LEN(HVS_SEND_BUF_SIZE). +- */ + if (hv_get_bytes_to_write(&chan->outbound) > 0) + sk->sk_write_space(sk); + } +@@ -328,8 +313,9 @@ static void hvs_open_connection(struct vmbus_channel *chan) + + struct sockaddr_vm addr; + struct sock *sk, *new = NULL; +- struct vsock_sock *vnew; +- struct hvsock *hvs, *hvs_new; ++ struct vsock_sock *vnew = NULL; ++ struct hvsock *hvs = NULL; ++ struct hvsock *hvs_new = NULL; + int ret; + + if_type = &chan->offermsg.offer.if_type; +@@ -389,6 +375,13 @@ static void hvs_open_connection(struct vmbus_channel *chan) + set_per_channel_state(chan, conn_from_host ? new : sk); + vmbus_set_chn_rescind_callback(chan, hvs_close_connection); + ++ /* Set the pending send size to max packet size to always get ++ * notifications from the host when there is enough writable space. ++ * The host is optimized to send notifications only when the pending ++ * size boundary is crossed, and not always. ++ */ ++ hvs_set_channel_pending_send_size(chan); ++ + if (conn_from_host) { + new->sk_state = SS_CONNECTED; + sk->sk_ack_backlog++; +@@ -652,23 +645,8 @@ static s64 hvs_stream_has_data(struct vsock_sock *vsk) + static s64 hvs_stream_has_space(struct vsock_sock *vsk) + { + struct hvsock *hvs = vsk->trans; +- struct vmbus_channel *chan = hvs->chan; +- s64 ret; +- +- ret = hvs_channel_writable_bytes(chan); +- if (ret > 0) { +- hvs_clear_channel_pending_send_size(chan); +- } else { +- /* See hvs_channel_cb() */ +- hvs_set_channel_pending_send_size(chan); +- +- /* Re-check the writable bytes to avoid race */ +- ret = hvs_channel_writable_bytes(chan); +- if (ret > 0) +- hvs_clear_channel_pending_send_size(chan); +- } + +- return ret; ++ return hvs_channel_writable_bytes(hvs->chan); + } + + static u64 hvs_stream_rcvhiwat(struct vsock_sock *vsk) +-- +2.20.1 + diff --git a/queue-4.14/iio-iio-utils-fix-possible-incorrect-mask-calculatio.patch b/queue-4.14/iio-iio-utils-fix-possible-incorrect-mask-calculatio.patch new file mode 100644 index 00000000000..437a64221ae --- /dev/null +++ b/queue-4.14/iio-iio-utils-fix-possible-incorrect-mask-calculatio.patch @@ -0,0 +1,53 @@ +From 18ec3837d1c522b3d9dab9a7e779d926d4da9d50 Mon Sep 17 00:00:00 2001 +From: Bastien Nocera +Date: Thu, 27 Jun 2019 09:20:45 +0200 +Subject: iio: iio-utils: Fix possible incorrect mask calculation + +[ Upstream commit 208a68c8393d6041a90862992222f3d7943d44d6 ] + +On some machines, iio-sensor-proxy was returning all 0's for IIO sensor +values. It turns out that the bits_used for this sensor is 32, which makes +the mask calculation: + +*mask = (1 << 32) - 1; + +If the compiler interprets the 1 literals as 32-bit ints, it generates +undefined behavior depending on compiler version and optimization level. +On my system, it optimizes out the shift, so the mask value becomes + +*mask = (1) - 1; + +With a mask value of 0, iio-sensor-proxy will always return 0 for every axis. + +Avoid incorrect 0 values caused by compiler optimization. + +See original fix by Brett Dutro in +iio-sensor-proxy: +https://github.com/hadess/iio-sensor-proxy/commit/9615ceac7c134d838660e209726cd86aa2064fd3 + +Signed-off-by: Bastien Nocera +Signed-off-by: Jonathan Cameron +Signed-off-by: Sasha Levin +--- + tools/iio/iio_utils.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/tools/iio/iio_utils.c b/tools/iio/iio_utils.c +index 7a6d61c6c012..55272fef3b50 100644 +--- a/tools/iio/iio_utils.c ++++ b/tools/iio/iio_utils.c +@@ -159,9 +159,9 @@ int iioutils_get_type(unsigned *is_signed, unsigned *bytes, unsigned *bits_used, + *be = (endianchar == 'b'); + *bytes = padint / 8; + if (*bits_used == 64) +- *mask = ~0; ++ *mask = ~(0ULL); + else +- *mask = (1ULL << *bits_used) - 1; ++ *mask = (1ULL << *bits_used) - 1ULL; + + *is_signed = (signchar == 's'); + if (fclose(sysfsfp)) { +-- +2.20.1 + diff --git a/queue-4.14/kallsyms-exclude-kasan-local-symbols-on-s390.patch b/queue-4.14/kallsyms-exclude-kasan-local-symbols-on-s390.patch new file mode 100644 index 00000000000..6d9a75666c9 --- /dev/null +++ b/queue-4.14/kallsyms-exclude-kasan-local-symbols-on-s390.patch @@ -0,0 +1,68 @@ +From 03227510f96396094e15032adb2f61e0a51e4c80 Mon Sep 17 00:00:00 2001 +From: Vasily Gorbik +Date: Fri, 28 Jun 2019 19:22:47 +0200 +Subject: kallsyms: exclude kasan local symbols on s390 + +[ Upstream commit 33177f01ca3fe550146bb9001bec2fd806b2f40c ] + +gcc asan instrumentation emits the following sequence to store frame pc +when the kernel is built with CONFIG_RELOCATABLE: +debug/vsprintf.s: + .section .data.rel.ro.local,"aw" + .align 8 +.LC3: + .quad .LASANPC4826@GOTOFF +.text + .align 8 + .type number, @function +number: +.LASANPC4826: + +and in case reloc is issued for LASANPC label it also gets into .symtab +with the same address as actual function symbol: +$ nm -n vmlinux | grep 0000000001397150 +0000000001397150 t .LASANPC4826 +0000000001397150 t number + +In the end kernel backtraces are almost unreadable: +[ 143.748476] Call Trace: +[ 143.748484] ([<000000002da3e62c>] .LASANPC2671+0x114/0x190) +[ 143.748492] [<000000002eca1a58>] .LASANPC2612+0x110/0x160 +[ 143.748502] [<000000002de9d830>] print_address_description+0x80/0x3b0 +[ 143.748511] [<000000002de9dd64>] __kasan_report+0x15c/0x1c8 +[ 143.748521] [<000000002ecb56d4>] strrchr+0x34/0x60 +[ 143.748534] [<000003ff800a9a40>] kasan_strings+0xb0/0x148 [test_kasan] +[ 143.748547] [<000003ff800a9bba>] kmalloc_tests_init+0xe2/0x528 [test_kasan] +[ 143.748555] [<000000002da2117c>] .LASANPC4069+0x354/0x748 +[ 143.748563] [<000000002dbfbb16>] do_init_module+0x136/0x3b0 +[ 143.748571] [<000000002dbff3f4>] .LASANPC3191+0x2164/0x25d0 +[ 143.748580] [<000000002dbffc4c>] .LASANPC3196+0x184/0x1b8 +[ 143.748587] [<000000002ecdf2ec>] system_call+0xd8/0x2d8 + +Since LASANPC labels are not even unique and get into .symtab only due +to relocs filter them out in kallsyms. + +Signed-off-by: Vasily Gorbik +Signed-off-by: Masahiro Yamada +Signed-off-by: Sasha Levin +--- + scripts/kallsyms.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c +index 1dd24c5b9b47..b471022c8162 100644 +--- a/scripts/kallsyms.c ++++ b/scripts/kallsyms.c +@@ -160,6 +160,9 @@ static int read_symbol(FILE *in, struct sym_entry *s) + /* exclude debugging symbols */ + else if (stype == 'N' || stype == 'n') + return -1; ++ /* exclude s390 kasan local symbols */ ++ else if (!strncmp(sym, ".LASANPC", 8)) ++ return -1; + + /* include the type field in the symbol name, so that it gets + * compressed together */ +-- +2.20.1 + diff --git a/queue-4.14/kbuild-add-werror-unknown-warning-option-to-clang_fl.patch b/queue-4.14/kbuild-add-werror-unknown-warning-option-to-clang_fl.patch new file mode 100644 index 00000000000..adab91497a7 --- /dev/null +++ b/queue-4.14/kbuild-add-werror-unknown-warning-option-to-clang_fl.patch @@ -0,0 +1,63 @@ +From 479cd60b373da14473d66ddee3d1ad3a54e41305 Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Tue, 11 Jun 2019 11:43:31 -0700 +Subject: kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGS + +[ Upstream commit 589834b3a0097a4908f4112eac0ca2feb486fa32 ] + +In commit ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI +drift"), the arm64 Makefile added -Wno-psabi to KBUILD_CFLAGS, which is +a GCC only option so clang rightfully complains: + +warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option] + +https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option + +However, by default, this is merely a warning so the build happily goes +on with a slew of these warnings in the process. + +Commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to +support clang") worked around this behavior in cc-option by adding +-Werror so that unknown flags cause an error. However, this all happens +silently and when an unknown flag is added to the build unconditionally +like -Wno-psabi, cc-option will always fail because there is always an +unknown flag in the list of flags. This manifested as link time failures +in the arm64 libstub because -fno-stack-protector didn't get added to +KBUILD_CFLAGS. + +To avoid these weird cryptic failures in the future, make clang behave +like gcc and immediately error when it encounters an unknown flag by +adding -Werror=unknown-warning-option to CLANG_FLAGS. This can be added +unconditionally for clang because it is supported by at least 3.0.0, +according to godbolt [1] and 4.0.0, according to its documentation [2], +which is far earlier than we typically support. + +[1]: https://godbolt.org/z/7F7rm3 +[2]: https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wunknown-warning-option + +Link: https://github.com/ClangBuiltLinux/linux/issues/511 +Link: https://github.com/ClangBuiltLinux/linux/issues/517 +Suggested-by: Peter Smith +Signed-off-by: Nathan Chancellor +Tested-by: Nick Desaulniers +Signed-off-by: Masahiro Yamada +Signed-off-by: Sasha Levin +--- + Makefile | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/Makefile b/Makefile +index 97c744513af0..bbc9b6acb177 100644 +--- a/Makefile ++++ b/Makefile +@@ -488,6 +488,7 @@ ifneq ($(GCC_TOOLCHAIN),) + CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN) + endif + CLANG_FLAGS += -no-integrated-as ++CLANG_FLAGS += -Werror=unknown-warning-option + KBUILD_CFLAGS += $(CLANG_FLAGS) + KBUILD_AFLAGS += $(CLANG_FLAGS) + export CLANG_FLAGS +-- +2.20.1 + diff --git a/queue-4.14/locking-lockdep-fix-lock-used-or-unused-stats-error.patch b/queue-4.14/locking-lockdep-fix-lock-used-or-unused-stats-error.patch new file mode 100644 index 00000000000..f173151aa14 --- /dev/null +++ b/queue-4.14/locking-lockdep-fix-lock-used-or-unused-stats-error.patch @@ -0,0 +1,77 @@ +From 81f0e7faa1061055da876500c7e1d12daa3a198a Mon Sep 17 00:00:00 2001 +From: Yuyang Du +Date: Tue, 9 Jul 2019 18:15:22 +0800 +Subject: locking/lockdep: Fix lock used or unused stats error + +[ Upstream commit 68d41d8c94a31dfb8233ab90b9baf41a2ed2da68 ] + +The stats variable nr_unused_locks is incremented every time a new lock +class is register and decremented when the lock is first used in +__lock_acquire(). And after all, it is shown and checked in lockdep_stats. + +However, under configurations that either CONFIG_TRACE_IRQFLAGS or +CONFIG_PROVE_LOCKING is not defined: + +The commit: + + 091806515124b20 ("locking/lockdep: Consolidate lock usage bit initialization") + +missed marking the LOCK_USED flag at IRQ usage initialization because +as mark_usage() is not called. And the commit: + + 886532aee3cd42d ("locking/lockdep: Move mark_lock() inside CONFIG_TRACE_IRQFLAGS && CONFIG_PROVE_LOCKING") + +further made mark_lock() not defined such that the LOCK_USED cannot be +marked at all when the lock is first acquired. + +As a result, we fix this by not showing and checking the stats under such +configurations for lockdep_stats. + +Reported-by: Qian Cai +Signed-off-by: Yuyang Du +Signed-off-by: Peter Zijlstra (Intel) +Cc: Andrew Morton +Cc: Linus Torvalds +Cc: Paul E. McKenney +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: Will Deacon +Cc: arnd@arndb.de +Cc: frederic@kernel.org +Link: https://lkml.kernel.org/r/20190709101522.9117-1-duyuyang@gmail.com +Signed-off-by: Ingo Molnar +Signed-off-by: Sasha Levin +--- + kernel/locking/lockdep_proc.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/kernel/locking/lockdep_proc.c b/kernel/locking/lockdep_proc.c +index ad69bbc9bd28..71631bef0e84 100644 +--- a/kernel/locking/lockdep_proc.c ++++ b/kernel/locking/lockdep_proc.c +@@ -234,6 +234,7 @@ static int lockdep_stats_show(struct seq_file *m, void *v) + nr_hardirq_read_safe = 0, nr_hardirq_read_unsafe = 0, + sum_forward_deps = 0; + ++#ifdef CONFIG_PROVE_LOCKING + list_for_each_entry(class, &all_lock_classes, lock_entry) { + + if (class->usage_mask == 0) +@@ -265,12 +266,12 @@ static int lockdep_stats_show(struct seq_file *m, void *v) + if (class->usage_mask & LOCKF_ENABLED_HARDIRQ_READ) + nr_hardirq_read_unsafe++; + +-#ifdef CONFIG_PROVE_LOCKING + sum_forward_deps += lockdep_count_forward_deps(class); +-#endif + } + #ifdef CONFIG_DEBUG_LOCKDEP + DEBUG_LOCKS_WARN_ON(debug_atomic_read(nr_unused_locks) != nr_unused); ++#endif ++ + #endif + seq_printf(m, " lock-classes: %11lu [max: %lu]\n", + nr_lock_classes, MAX_LOCKDEP_KEYS); +-- +2.20.1 + diff --git a/queue-4.14/locking-lockdep-hide-unused-class-variable.patch b/queue-4.14/locking-lockdep-hide-unused-class-variable.patch new file mode 100644 index 00000000000..ea4b0839fa0 --- /dev/null +++ b/queue-4.14/locking-lockdep-hide-unused-class-variable.patch @@ -0,0 +1,58 @@ +From a242c5d5695687cdb70c3f50196a19de0d9f7d5d Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Mon, 15 Jul 2019 11:27:49 +0200 +Subject: locking/lockdep: Hide unused 'class' variable + +[ Upstream commit 68037aa78208f34bda4e5cd76c357f718b838cbb ] + +The usage is now hidden in an #ifdef, so we need to move +the variable itself in there as well to avoid this warning: + + kernel/locking/lockdep_proc.c:203:21: error: unused variable 'class' [-Werror,-Wunused-variable] + +Signed-off-by: Arnd Bergmann +Signed-off-by: Peter Zijlstra (Intel) +Cc: Andrew Morton +Cc: Bart Van Assche +Cc: Linus Torvalds +Cc: Paul E. McKenney +Cc: Peter Zijlstra +Cc: Qian Cai +Cc: Thomas Gleixner +Cc: Waiman Long +Cc: Will Deacon +Cc: Will Deacon +Cc: Yuyang Du +Cc: frederic@kernel.org +Fixes: 68d41d8c94a3 ("locking/lockdep: Fix lock used or unused stats error") +Link: https://lkml.kernel.org/r/20190715092809.736834-1-arnd@arndb.de +Signed-off-by: Ingo Molnar +Signed-off-by: Sasha Levin +--- + kernel/locking/lockdep_proc.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/kernel/locking/lockdep_proc.c b/kernel/locking/lockdep_proc.c +index 71631bef0e84..8b2ef15e3552 100644 +--- a/kernel/locking/lockdep_proc.c ++++ b/kernel/locking/lockdep_proc.c +@@ -224,7 +224,6 @@ static void lockdep_stats_debug_show(struct seq_file *m) + + static int lockdep_stats_show(struct seq_file *m, void *v) + { +- struct lock_class *class; + unsigned long nr_unused = 0, nr_uncategorized = 0, + nr_irq_safe = 0, nr_irq_unsafe = 0, + nr_softirq_safe = 0, nr_softirq_unsafe = 0, +@@ -235,6 +234,8 @@ static int lockdep_stats_show(struct seq_file *m, void *v) + sum_forward_deps = 0; + + #ifdef CONFIG_PROVE_LOCKING ++ struct lock_class *class; ++ + list_for_each_entry(class, &all_lock_classes, lock_entry) { + + if (class->usage_mask == 0) +-- +2.20.1 + diff --git a/queue-4.14/mailbox-handle-failed-named-mailbox-channel-request.patch b/queue-4.14/mailbox-handle-failed-named-mailbox-channel-request.patch new file mode 100644 index 00000000000..9085ce53827 --- /dev/null +++ b/queue-4.14/mailbox-handle-failed-named-mailbox-channel-request.patch @@ -0,0 +1,44 @@ +From eb37c5213be152bdcb968ceceb94d2573ce73ba3 Mon Sep 17 00:00:00 2001 +From: morten petersen +Date: Mon, 8 Jul 2019 11:41:54 +0000 +Subject: mailbox: handle failed named mailbox channel request + +[ Upstream commit 25777e5784a7b417967460d4fcf9660d05a0c320 ] + +Previously, if mbox_request_channel_byname was used with a name +which did not exist in the "mbox-names" property of a mailbox +client, the mailbox corresponding to the last entry in the +"mbox-names" list would be incorrectly selected. +With this patch, -EINVAL is returned if the named mailbox is +not found. + +Signed-off-by: Morten Borup Petersen +Signed-off-by: Jassi Brar +Signed-off-by: Sasha Levin +--- + drivers/mailbox/mailbox.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c +index 537f4f6d009b..44b49a2676f0 100644 +--- a/drivers/mailbox/mailbox.c ++++ b/drivers/mailbox/mailbox.c +@@ -391,11 +391,13 @@ struct mbox_chan *mbox_request_channel_byname(struct mbox_client *cl, + + of_property_for_each_string(np, "mbox-names", prop, mbox_name) { + if (!strncmp(name, mbox_name, strlen(name))) +- break; ++ return mbox_request_channel(cl, index); + index++; + } + +- return mbox_request_channel(cl, index); ++ dev_err(cl->dev, "%s() could not locate channel named \"%s\"\n", ++ __func__, name); ++ return ERR_PTR(-EINVAL); + } + EXPORT_SYMBOL_GPL(mbox_request_channel_byname); + +-- +2.20.1 + diff --git a/queue-4.14/memstick-fix-error-cleanup-path-of-memstick_init.patch b/queue-4.14/memstick-fix-error-cleanup-path-of-memstick_init.patch new file mode 100644 index 00000000000..2168ae7f20e --- /dev/null +++ b/queue-4.14/memstick-fix-error-cleanup-path-of-memstick_init.patch @@ -0,0 +1,75 @@ +From c7a6f8920ad566a182eeb018f807da85a8342b64 Mon Sep 17 00:00:00 2001 +From: Wang Hai +Date: Wed, 15 May 2019 22:37:25 +0800 +Subject: memstick: Fix error cleanup path of memstick_init + +[ Upstream commit 65f1a0d39c289bb6fc85635528cd36c4b07f560e ] + +If bus_register fails. On its error handling path, it has cleaned up +what it has done. There is no need to call bus_unregister again. +Otherwise, if bus_unregister is called, issues such as null-ptr-deref +will arise. + +Syzkaller report this: + +kobject_add_internal failed for memstick (error: -12 parent: bus) +BUG: KASAN: null-ptr-deref in sysfs_remove_file_ns+0x1b/0x40 fs/sysfs/file.c:467 +Read of size 8 at addr 0000000000000078 by task syz-executor.0/4460 + +Call Trace: + __dump_stack lib/dump_stack.c:77 [inline] + dump_stack+0xa9/0x10e lib/dump_stack.c:113 + __kasan_report+0x171/0x18d mm/kasan/report.c:321 + kasan_report+0xe/0x20 mm/kasan/common.c:614 + sysfs_remove_file_ns+0x1b/0x40 fs/sysfs/file.c:467 + sysfs_remove_file include/linux/sysfs.h:519 [inline] + bus_remove_file+0x6c/0x90 drivers/base/bus.c:145 + remove_probe_files drivers/base/bus.c:599 [inline] + bus_unregister+0x6e/0x100 drivers/base/bus.c:916 ? 0xffffffffc1590000 + memstick_init+0x7a/0x1000 [memstick] + do_one_initcall+0xb9/0x3b5 init/main.c:914 + do_init_module+0xe0/0x330 kernel/module.c:3468 + load_module+0x38eb/0x4270 kernel/module.c:3819 + __do_sys_finit_module+0x162/0x190 kernel/module.c:3909 + do_syscall_64+0x72/0x2a0 arch/x86/entry/common.c:298 + entry_SYSCALL_64_after_hwframe+0x49/0xbe + +Fixes: baf8532a147d ("memstick: initial commit for Sony MemoryStick support") +Reported-by: Hulk Robot +Signed-off-by: Wang Hai +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/memstick/core/memstick.c | 13 +++++++++---- + 1 file changed, 9 insertions(+), 4 deletions(-) + +diff --git a/drivers/memstick/core/memstick.c b/drivers/memstick/core/memstick.c +index 1246d69ba187..b1564cacd19e 100644 +--- a/drivers/memstick/core/memstick.c ++++ b/drivers/memstick/core/memstick.c +@@ -629,13 +629,18 @@ static int __init memstick_init(void) + return -ENOMEM; + + rc = bus_register(&memstick_bus_type); +- if (!rc) +- rc = class_register(&memstick_host_class); ++ if (rc) ++ goto error_destroy_workqueue; + +- if (!rc) +- return 0; ++ rc = class_register(&memstick_host_class); ++ if (rc) ++ goto error_bus_unregister; ++ ++ return 0; + ++error_bus_unregister: + bus_unregister(&memstick_bus_type); ++error_destroy_workqueue: + destroy_workqueue(workqueue); + + return rc; +-- +2.20.1 + diff --git a/queue-4.14/mfd-arizona-fix-undefined-behavior.patch b/queue-4.14/mfd-arizona-fix-undefined-behavior.patch new file mode 100644 index 00000000000..419ace17a21 --- /dev/null +++ b/queue-4.14/mfd-arizona-fix-undefined-behavior.patch @@ -0,0 +1,52 @@ +From 9c21aeaf10dfdc813390a9a966ed69b164a3950e Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Mon, 20 May 2019 10:06:25 +0100 +Subject: mfd: arizona: Fix undefined behavior + +[ Upstream commit 5da6cbcd2f395981aa9bfc571ace99f1c786c985 ] + +When the driver is used with a subdevice that is disabled in the +kernel configuration, clang gets a little confused about the +control flow and fails to notice that n_subdevs is only +uninitialized when subdevs is NULL, and we check for that, +leading to a false-positive warning: + +drivers/mfd/arizona-core.c:1423:19: error: variable 'n_subdevs' is uninitialized when used here + [-Werror,-Wuninitialized] + subdevs, n_subdevs, NULL, 0, NULL); + ^~~~~~~~~ +drivers/mfd/arizona-core.c:999:15: note: initialize the variable 'n_subdevs' to silence this warning + int n_subdevs, ret, i; + ^ + = 0 + +Ideally, we would rearrange the code to avoid all those early +initializations and have an explicit exit in each disabled case, +but it's much easier to chicken out and add one more initialization +here to shut up the warning. + +Signed-off-by: Arnd Bergmann +Reviewed-by: Nathan Chancellor +Signed-off-by: Charles Keepax +Signed-off-by: Lee Jones +Signed-off-by: Sasha Levin +--- + drivers/mfd/arizona-core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c +index 8d46e3ad9529..d8e3184bd27c 100644 +--- a/drivers/mfd/arizona-core.c ++++ b/drivers/mfd/arizona-core.c +@@ -1029,7 +1029,7 @@ int arizona_dev_init(struct arizona *arizona) + unsigned int reg, val, mask; + int (*apply_patch)(struct arizona *) = NULL; + const struct mfd_cell *subdevs = NULL; +- int n_subdevs, ret, i; ++ int n_subdevs = 0, ret, i; + + dev_set_drvdata(arizona->dev, arizona); + mutex_init(&arizona->clk_lock); +-- +2.20.1 + diff --git a/queue-4.14/mfd-core-set-fwnode-for-created-devices.patch b/queue-4.14/mfd-core-set-fwnode-for-created-devices.patch new file mode 100644 index 00000000000..580a6c8ce3b --- /dev/null +++ b/queue-4.14/mfd-core-set-fwnode-for-created-devices.patch @@ -0,0 +1,34 @@ +From 145044bab32be3b434fc2c6c355779b35c7a0cf1 Mon Sep 17 00:00:00 2001 +From: Robert Hancock +Date: Tue, 4 Jun 2019 16:35:43 -0600 +Subject: mfd: core: Set fwnode for created devices + +[ Upstream commit c176c6d7e932662668bcaec2d763657096589d85 ] + +The logic for setting the of_node on devices created by mfd did not set +the fwnode pointer to match, which caused fwnode-based APIs to +malfunction on these devices since the fwnode pointer was null. Fix +this. + +Signed-off-by: Robert Hancock +Signed-off-by: Lee Jones +Signed-off-by: Sasha Levin +--- + drivers/mfd/mfd-core.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c +index c57e407020f1..5c8ed2150c8b 100644 +--- a/drivers/mfd/mfd-core.c ++++ b/drivers/mfd/mfd-core.c +@@ -179,6 +179,7 @@ static int mfd_add_device(struct device *parent, int id, + for_each_child_of_node(parent->of_node, np) { + if (of_device_is_compatible(np, cell->of_compatible)) { + pdev->dev.of_node = np; ++ pdev->dev.fwnode = &np->fwnode; + break; + } + } +-- +2.20.1 + diff --git a/queue-4.14/mfd-hi655x-pmic-fix-missing-return-value-check-for-d.patch b/queue-4.14/mfd-hi655x-pmic-fix-missing-return-value-check-for-d.patch new file mode 100644 index 00000000000..fb6412ed51f --- /dev/null +++ b/queue-4.14/mfd-hi655x-pmic-fix-missing-return-value-check-for-d.patch @@ -0,0 +1,34 @@ +From 086303fb1bd9966373cd7311dabf9e6eab07159c Mon Sep 17 00:00:00 2001 +From: Axel Lin +Date: Wed, 26 Jun 2019 21:30:07 +0800 +Subject: mfd: hi655x-pmic: Fix missing return value check for + devm_regmap_init_mmio_clk + +[ Upstream commit 7efd105c27fd2323789b41b64763a0e33ed79c08 ] + +Since devm_regmap_init_mmio_clk can fail, add return value checking. + +Signed-off-by: Axel Lin +Acked-by: Chen Feng +Signed-off-by: Lee Jones +Signed-off-by: Sasha Levin +--- + drivers/mfd/hi655x-pmic.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c +index 96c07fa1802a..6693f74aa6ab 100644 +--- a/drivers/mfd/hi655x-pmic.c ++++ b/drivers/mfd/hi655x-pmic.c +@@ -112,6 +112,8 @@ static int hi655x_pmic_probe(struct platform_device *pdev) + + pmic->regmap = devm_regmap_init_mmio_clk(dev, NULL, base, + &hi655x_regmap_config); ++ if (IS_ERR(pmic->regmap)) ++ return PTR_ERR(pmic->regmap); + + regmap_read(pmic->regmap, HI655X_BUS_ADDR(HI655X_VER_REG), &pmic->ver); + if ((pmic->ver < PMU_VER_START) || (pmic->ver > PMU_VER_END)) { +-- +2.20.1 + diff --git a/queue-4.14/mm-gup.c-mark-undo_dev_pagemap-as-__maybe_unused.patch b/queue-4.14/mm-gup.c-mark-undo_dev_pagemap-as-__maybe_unused.patch new file mode 100644 index 00000000000..4c5ce4abdf4 --- /dev/null +++ b/queue-4.14/mm-gup.c-mark-undo_dev_pagemap-as-__maybe_unused.patch @@ -0,0 +1,44 @@ +From dbc3fded417f2381894bcb0bfb24afb9b5e2c7c3 Mon Sep 17 00:00:00 2001 +From: Guenter Roeck +Date: Thu, 11 Jul 2019 20:57:46 -0700 +Subject: mm/gup.c: mark undo_dev_pagemap as __maybe_unused + +[ Upstream commit 790c73690c2bbecb3f6f8becbdb11ddc9bcff8cc ] + +Several mips builds generate the following build warning. + + mm/gup.c:1788:13: warning: 'undo_dev_pagemap' defined but not used + +The function is declared unconditionally but only called from behind +various ifdefs. Mark it __maybe_unused. + +Link: http://lkml.kernel.org/r/1562072523-22311-1-git-send-email-linux@roeck-us.net +Signed-off-by: Guenter Roeck +Reviewed-by: Andrew Morton +Cc: Stephen Rothwell +Cc: Robin Murphy +Cc: Kirill A. Shutemov +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + mm/gup.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/mm/gup.c b/mm/gup.c +index babcbd6d99c3..cee599d1692c 100644 +--- a/mm/gup.c ++++ b/mm/gup.c +@@ -1364,7 +1364,8 @@ static inline pte_t gup_get_pte(pte_t *ptep) + } + #endif + +-static void undo_dev_pagemap(int *nr, int nr_start, struct page **pages) ++static void __maybe_unused undo_dev_pagemap(int *nr, int nr_start, ++ struct page **pages) + { + while ((*nr) - nr_start) { + struct page *page = pages[--(*nr)]; +-- +2.20.1 + diff --git a/queue-4.14/mm-gup.c-remove-some-bug_ons-from-get_gate_page.patch b/queue-4.14/mm-gup.c-remove-some-bug_ons-from-get_gate_page.patch new file mode 100644 index 00000000000..50b43148b06 --- /dev/null +++ b/queue-4.14/mm-gup.c-remove-some-bug_ons-from-get_gate_page.patch @@ -0,0 +1,53 @@ +From bd1732cbab70d4734f69395ebfd3c7e4c2d054f9 Mon Sep 17 00:00:00 2001 +From: Andy Lutomirski +Date: Thu, 11 Jul 2019 20:57:43 -0700 +Subject: mm/gup.c: remove some BUG_ONs from get_gate_page() + +[ Upstream commit b5d1c39f34d1c9bca0c4b9ae2e339fbbe264a9c7 ] + +If we end up without a PGD or PUD entry backing the gate area, don't BUG +-- just fail gracefully. + +It's not entirely implausible that this could happen some day on x86. It +doesn't right now even with an execute-only emulated vsyscall page because +the fixmap shares the PUD, but the core mm code shouldn't rely on that +particular detail to avoid OOPSing. + +Link: http://lkml.kernel.org/r/a1d9f4efb75b9d464e59fd6af00104b21c58f6f7.1561610798.git.luto@kernel.org +Signed-off-by: Andy Lutomirski +Reviewed-by: Kees Cook +Reviewed-by: Andrew Morton +Cc: Florian Weimer +Cc: Jann Horn +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + mm/gup.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +diff --git a/mm/gup.c b/mm/gup.c +index cee599d1692c..12b9626b1a9e 100644 +--- a/mm/gup.c ++++ b/mm/gup.c +@@ -442,11 +442,14 @@ static int get_gate_page(struct mm_struct *mm, unsigned long address, + pgd = pgd_offset_k(address); + else + pgd = pgd_offset_gate(mm, address); +- BUG_ON(pgd_none(*pgd)); ++ if (pgd_none(*pgd)) ++ return -EFAULT; + p4d = p4d_offset(pgd, address); +- BUG_ON(p4d_none(*p4d)); ++ if (p4d_none(*p4d)) ++ return -EFAULT; + pud = pud_offset(p4d, address); +- BUG_ON(pud_none(*pud)); ++ if (pud_none(*pud)) ++ return -EFAULT; + pmd = pmd_offset(pud, address); + if (!pmd_present(*pmd)) + return -EFAULT; +-- +2.20.1 + diff --git a/queue-4.14/mm-kmemleak.c-fix-check-for-softirq-context.patch b/queue-4.14/mm-kmemleak.c-fix-check-for-softirq-context.patch new file mode 100644 index 00000000000..929a6ec457b --- /dev/null +++ b/queue-4.14/mm-kmemleak.c-fix-check-for-softirq-context.patch @@ -0,0 +1,96 @@ +From b1e8db7faab839d87c880b371bad58910f4c7ccb Mon Sep 17 00:00:00 2001 +From: Dmitry Vyukov +Date: Thu, 11 Jul 2019 20:53:39 -0700 +Subject: mm/kmemleak.c: fix check for softirq context + +[ Upstream commit 6ef9056952532c3b746de46aa10d45b4d7797bd8 ] + +in_softirq() is a wrong predicate to check if we are in a softirq +context. It also returns true if we have BH disabled, so objects are +falsely stamped with "softirq" comm. The correct predicate is +in_serving_softirq(). + +If user does cat from /sys/kernel/debug/kmemleak previously they would +see this, which is clearly wrong, this is system call context (see the +comm): + +unreferenced object 0xffff88805bd661c0 (size 64): + comm "softirq", pid 0, jiffies 4294942959 (age 12.400s) + hex dump (first 32 bytes): + 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 ................ + 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ + backtrace: + [<0000000007dcb30c>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] + [<0000000007dcb30c>] slab_post_alloc_hook mm/slab.h:439 [inline] + [<0000000007dcb30c>] slab_alloc mm/slab.c:3326 [inline] + [<0000000007dcb30c>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 + [<00000000969722b7>] kmalloc include/linux/slab.h:547 [inline] + [<00000000969722b7>] kzalloc include/linux/slab.h:742 [inline] + [<00000000969722b7>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline] + [<00000000969722b7>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085 + [<00000000a4134b5f>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475 + [<00000000d20248ad>] do_ip_setsockopt.isra.0+0x19fe/0x1c00 net/ipv4/ip_sockglue.c:957 + [<000000003d367be7>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246 + [<000000003c7c76af>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616 + [<000000000c1aeb23>] sock_common_setsockopt+0x3e/0x50 net/core/sock.c:3130 + [<000000000157b92b>] __sys_setsockopt+0x9e/0x120 net/socket.c:2078 + [<00000000a9f3d058>] __do_sys_setsockopt net/socket.c:2089 [inline] + [<00000000a9f3d058>] __se_sys_setsockopt net/socket.c:2086 [inline] + [<00000000a9f3d058>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086 + [<000000001b8da885>] do_syscall_64+0x7c/0x1a0 arch/x86/entry/common.c:301 + [<00000000ba770c62>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +now they will see this: + +unreferenced object 0xffff88805413c800 (size 64): + comm "syz-executor.4", pid 8960, jiffies 4294994003 (age 14.350s) + hex dump (first 32 bytes): + 00 7a 8a 57 80 88 ff ff e0 00 00 01 00 00 00 00 .z.W............ + 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ + backtrace: + [<00000000c5d3be64>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] + [<00000000c5d3be64>] slab_post_alloc_hook mm/slab.h:439 [inline] + [<00000000c5d3be64>] slab_alloc mm/slab.c:3326 [inline] + [<00000000c5d3be64>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 + [<0000000023865be2>] kmalloc include/linux/slab.h:547 [inline] + [<0000000023865be2>] kzalloc include/linux/slab.h:742 [inline] + [<0000000023865be2>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline] + [<0000000023865be2>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085 + [<000000003029a9d4>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475 + [<00000000ccd0a87c>] do_ip_setsockopt.isra.0+0x19fe/0x1c00 net/ipv4/ip_sockglue.c:957 + [<00000000a85a3785>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246 + [<00000000ec13c18d>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616 + [<0000000052d748e3>] sock_common_setsockopt+0x3e/0x50 net/core/sock.c:3130 + [<00000000512f1014>] __sys_setsockopt+0x9e/0x120 net/socket.c:2078 + [<00000000181758bc>] __do_sys_setsockopt net/socket.c:2089 [inline] + [<00000000181758bc>] __se_sys_setsockopt net/socket.c:2086 [inline] + [<00000000181758bc>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086 + [<00000000d4b73623>] do_syscall_64+0x7c/0x1a0 arch/x86/entry/common.c:301 + [<00000000c1098bec>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +Link: http://lkml.kernel.org/r/20190517171507.96046-1-dvyukov@gmail.com +Signed-off-by: Dmitry Vyukov +Acked-by: Catalin Marinas +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + mm/kmemleak.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/mm/kmemleak.c b/mm/kmemleak.c +index 71ba1c7f8892..d779181bed4d 100644 +--- a/mm/kmemleak.c ++++ b/mm/kmemleak.c +@@ -577,7 +577,7 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size, + if (in_irq()) { + object->pid = 0; + strncpy(object->comm, "hardirq", sizeof(object->comm)); +- } else if (in_softirq()) { ++ } else if (in_serving_softirq()) { + object->pid = 0; + strncpy(object->comm, "softirq", sizeof(object->comm)); + } else { +-- +2.20.1 + diff --git a/queue-4.14/mm-mmu_notifier-use-hlist_add_head_rcu.patch b/queue-4.14/mm-mmu_notifier-use-hlist_add_head_rcu.patch new file mode 100644 index 00000000000..b26ddfc81e2 --- /dev/null +++ b/queue-4.14/mm-mmu_notifier-use-hlist_add_head_rcu.patch @@ -0,0 +1,69 @@ +From 266f33a551e091d4377bac999bf580ad0ed36b15 Mon Sep 17 00:00:00 2001 +From: Jean-Philippe Brucker +Date: Thu, 11 Jul 2019 20:58:50 -0700 +Subject: mm/mmu_notifier: use hlist_add_head_rcu() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit 543bdb2d825fe2400d6e951f1786d92139a16931 ] + +Make mmu_notifier_register() safer by issuing a memory barrier before +registering a new notifier. This fixes a theoretical bug on weakly +ordered CPUs. For example, take this simplified use of notifiers by a +driver: + + my_struct->mn.ops = &my_ops; /* (1) */ + mmu_notifier_register(&my_struct->mn, mm) + ... + hlist_add_head(&mn->hlist, &mm->mmu_notifiers); /* (2) */ + ... + +Once mmu_notifier_register() releases the mm locks, another thread can +invalidate a range: + + mmu_notifier_invalidate_range() + ... + hlist_for_each_entry_rcu(mn, &mm->mmu_notifiers, hlist) { + if (mn->ops->invalidate_range) + +The read side relies on the data dependency between mn and ops to ensure +that the pointer is properly initialized. But the write side doesn't have +any dependency between (1) and (2), so they could be reordered and the +readers could dereference an invalid mn->ops. mmu_notifier_register() +does take all the mm locks before adding to the hlist, but those have +acquire semantics which isn't sufficient. + +By calling hlist_add_head_rcu() instead of hlist_add_head() we update the +hlist using a store-release, ensuring that readers see prior +initialization of my_struct. This situation is better illustated by +litmus test MP+onceassign+derefonce. + +Link: http://lkml.kernel.org/r/20190502133532.24981-1-jean-philippe.brucker@arm.com +Fixes: cddb8a5c14aa ("mmu-notifiers: core") +Signed-off-by: Jean-Philippe Brucker +Cc: Jérôme Glisse +Cc: Michal Hocko +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + mm/mmu_notifier.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c +index 314285284e6e..70d0efb06374 100644 +--- a/mm/mmu_notifier.c ++++ b/mm/mmu_notifier.c +@@ -267,7 +267,7 @@ static int do_mmu_notifier_register(struct mmu_notifier *mn, + * thanks to mm_take_all_locks(). + */ + spin_lock(&mm->mmu_notifier_mm->lock); +- hlist_add_head(&mn->hlist, &mm->mmu_notifier_mm->list); ++ hlist_add_head_rcu(&mn->hlist, &mm->mmu_notifier_mm->list); + spin_unlock(&mm->mmu_notifier_mm->lock); + + mm_drop_all_locks(mm); +-- +2.20.1 + diff --git a/queue-4.14/nfsd-fix-overflow-causing-non-working-mounts-on-1-tb.patch b/queue-4.14/nfsd-fix-overflow-causing-non-working-mounts-on-1-tb.patch new file mode 100644 index 00000000000..a17c66af582 --- /dev/null +++ b/queue-4.14/nfsd-fix-overflow-causing-non-working-mounts-on-1-tb.patch @@ -0,0 +1,70 @@ +From 7bf225fbb037936058abdc4b84ecf3b0c2ecf931 Mon Sep 17 00:00:00 2001 +From: Paul Menzel +Date: Wed, 3 Jul 2019 13:28:15 +0200 +Subject: nfsd: Fix overflow causing non-working mounts on 1 TB machines +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit 3b2d4dcf71c4a91b420f835e52ddea8192300a3b ] + +Since commit 10a68cdf10 (nfsd: fix performance-limiting session +calculation) (Linux 5.1-rc1 and 4.19.31), shares from NFS servers with +1 TB of memory cannot be mounted anymore. The mount just hangs on the +client. + +The gist of commit 10a68cdf10 is the change below. + + -avail = clamp_t(int, avail, slotsize, avail/3); + +avail = clamp_t(int, avail, slotsize, total_avail/3); + +Here are the macros. + + #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <) + #define clamp_t(type, val, lo, hi) min_t(type, max_t(type, val, lo), hi) + +`total_avail` is 8,434,659,328 on the 1 TB machine. `clamp_t()` casts +the values to `int`, which for 32-bit integers can only hold values +−2,147,483,648 (−2^31) through 2,147,483,647 (2^31 − 1). + +`avail` (in the function signature) is just 65536, so that no overflow +was happening. Before the commit the assignment would result in 21845, +and `num = 4`. + +When using `total_avail`, it is causing the assignment to be +18446744072226137429 (printed as %lu), and `num` is then 4164608182. + +My next guess is, that `nfsd_drc_mem_used` is then exceeded, and the +server thinks there is no memory available any more for this client. + +Updating the arguments of `clamp_t()` and `min_t()` to `unsigned long` +fixes the issue. + +Now, `avail = 65536` (before commit 10a68cdf10 `avail = 21845`), but +`num = 4` remains the same. + +Fixes: c54f24e338ed (nfsd: fix performance-limiting session calculation) +Cc: stable@vger.kernel.org +Signed-off-by: Paul Menzel +Signed-off-by: J. Bruce Fields +Signed-off-by: Sasha Levin +--- + fs/nfsd/nfs4state.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c +index 0bf88876c889..87ee9cbf7dcb 100644 +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -1511,7 +1511,7 @@ static u32 nfsd4_get_drc_mem(struct nfsd4_channel_attrs *ca) + * Never use more than a third of the remaining memory, + * unless it's the only way to give this client a slot: + */ +- avail = clamp_t(int, avail, slotsize, total_avail/3); ++ avail = clamp_t(unsigned long, avail, slotsize, total_avail/3); + num = min_t(int, num, avail / slotsize); + nfsd_drc_mem_used += num * slotsize; + spin_unlock(&nfsd_drc_lock); +-- +2.20.1 + diff --git a/queue-4.14/nfsd-fix-performance-limiting-session-calculation.patch b/queue-4.14/nfsd-fix-performance-limiting-session-calculation.patch new file mode 100644 index 00000000000..696b910569f --- /dev/null +++ b/queue-4.14/nfsd-fix-performance-limiting-session-calculation.patch @@ -0,0 +1,55 @@ +From c841345cbbc2011af327e53777658c639c9cf1f5 Mon Sep 17 00:00:00 2001 +From: "J. Bruce Fields" +Date: Thu, 21 Feb 2019 10:47:00 -0500 +Subject: nfsd: fix performance-limiting session calculation + +[ Upstream commit c54f24e338ed2a35218f117a4a1afb5f9e2b4e64 ] + +We're unintentionally limiting the number of slots per nfsv4.1 session +to 10. Often more than 10 simultaneous RPCs are needed for the best +performance. + +This calculation was meant to prevent any one client from using up more +than a third of the limit we set for total memory use across all clients +and sessions. Instead, it's limiting the client to a third of the +maximum for a single session. + +Fix this. + +Reported-by: Chris Tracy +Cc: stable@vger.kernel.org +Fixes: de766e570413 "nfsd: give out fewer session slots as limit approaches" +Signed-off-by: J. Bruce Fields +Signed-off-by: Sasha Levin +--- + fs/nfsd/nfs4state.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c +index dd48353357d7..0bf88876c889 100644 +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -1502,16 +1502,16 @@ static u32 nfsd4_get_drc_mem(struct nfsd4_channel_attrs *ca) + { + u32 slotsize = slot_bytes(ca); + u32 num = ca->maxreqs; +- int avail; ++ unsigned long avail, total_avail; + + spin_lock(&nfsd_drc_lock); +- avail = min((unsigned long)NFSD_MAX_MEM_PER_SESSION, +- nfsd_drc_max_mem - nfsd_drc_mem_used); ++ total_avail = nfsd_drc_max_mem - nfsd_drc_mem_used; ++ avail = min((unsigned long)NFSD_MAX_MEM_PER_SESSION, total_avail); + /* + * Never use more than a third of the remaining memory, + * unless it's the only way to give this client a slot: + */ +- avail = clamp_t(int, avail, slotsize, avail/3); ++ avail = clamp_t(int, avail, slotsize, total_avail/3); + num = min_t(int, num, avail / slotsize); + nfsd_drc_mem_used += num * slotsize; + spin_unlock(&nfsd_drc_lock); +-- +2.20.1 + diff --git a/queue-4.14/nfsd-give-out-fewer-session-slots-as-limit-approache.patch b/queue-4.14/nfsd-give-out-fewer-session-slots-as-limit-approache.patch new file mode 100644 index 00000000000..3a61d79f851 --- /dev/null +++ b/queue-4.14/nfsd-give-out-fewer-session-slots-as-limit-approache.patch @@ -0,0 +1,38 @@ +From 8b5508b7b165b4af7d85595dbd8e1414a1a82e35 Mon Sep 17 00:00:00 2001 +From: "J. Bruce Fields" +Date: Tue, 19 Sep 2017 19:25:41 -0400 +Subject: nfsd: give out fewer session slots as limit approaches + +[ Upstream commit de766e570413bd0484af0b580299b495ada625c3 ] + +Instead of granting client's full requests until we hit our DRC size +limit and then failing CREATE_SESSIONs (and hence mounts) completely, +start granting clients smaller slot tables as we approach the limit. + +The factor chosen here is pretty much arbitrary. + +Signed-off-by: J. Bruce Fields +Signed-off-by: Sasha Levin +--- + fs/nfsd/nfs4state.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c +index 94128643ec1a..dd48353357d7 100644 +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -1507,6 +1507,11 @@ static u32 nfsd4_get_drc_mem(struct nfsd4_channel_attrs *ca) + spin_lock(&nfsd_drc_lock); + avail = min((unsigned long)NFSD_MAX_MEM_PER_SESSION, + nfsd_drc_max_mem - nfsd_drc_mem_used); ++ /* ++ * Never use more than a third of the remaining memory, ++ * unless it's the only way to give this client a slot: ++ */ ++ avail = clamp_t(int, avail, slotsize, avail/3); + num = min_t(int, num, avail / slotsize); + nfsd_drc_mem_used += num * slotsize; + spin_unlock(&nfsd_drc_lock); +-- +2.20.1 + diff --git a/queue-4.14/nfsd-increase-drc-cache-limit.patch b/queue-4.14/nfsd-increase-drc-cache-limit.patch new file mode 100644 index 00000000000..53a2d7a7d94 --- /dev/null +++ b/queue-4.14/nfsd-increase-drc-cache-limit.patch @@ -0,0 +1,38 @@ +From e4fbc9394da32b8cb992bd5653d0b246a0d5e7f9 Mon Sep 17 00:00:00 2001 +From: "J. Bruce Fields" +Date: Tue, 19 Sep 2017 20:51:31 -0400 +Subject: nfsd: increase DRC cache limit + +[ Upstream commit 44d8660d3bb0a1c8363ebcb906af2343ea8e15f6 ] + +An NFSv4.1+ client negotiates the size of its duplicate reply cache size +in the initial CREATE_SESSION request. The server preallocates the +memory for the duplicate reply cache to ensure that we'll never fail to +record the response to a nonidempotent operation. + +To prevent a few CREATE_SESSIONs from consuming all of memory we set an +upper limit based on nr_free_buffer_pages(). 1/2^10 has been too +limiting in practice; 1/2^7 is still less than one percent. + +Signed-off-by: J. Bruce Fields +Signed-off-by: Sasha Levin +--- + fs/nfsd/nfssvc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c +index e02bd2783124..4a9e0fb634b6 100644 +--- a/fs/nfsd/nfssvc.c ++++ b/fs/nfsd/nfssvc.c +@@ -447,7 +447,7 @@ void nfsd_reset_versions(void) + */ + static void set_max_drc(void) + { +- #define NFSD_DRC_SIZE_SHIFT 10 ++ #define NFSD_DRC_SIZE_SHIFT 7 + nfsd_drc_max_mem = (nr_free_buffer_pages() + >> NFSD_DRC_SIZE_SHIFT) * PAGE_SIZE; + nfsd_drc_mem_used = 0; +-- +2.20.1 + diff --git a/queue-4.14/nfsv4-fix-open-create-exclusive-when-the-server-rebo.patch b/queue-4.14/nfsv4-fix-open-create-exclusive-when-the-server-rebo.patch new file mode 100644 index 00000000000..119254b98e5 --- /dev/null +++ b/queue-4.14/nfsv4-fix-open-create-exclusive-when-the-server-rebo.patch @@ -0,0 +1,141 @@ +From 007b1dbc69fefa1abb1468765246abeb9f9c2d42 Mon Sep 17 00:00:00 2001 +From: Trond Myklebust +Date: Mon, 6 Nov 2017 15:28:03 -0500 +Subject: NFSv4: Fix open create exclusive when the server reboots + +[ Upstream commit 8fd1ab747d2b1ec7ec663ad0b41a32eaa35117a8 ] + +If the server that does not implement NFSv4.1 persistent session +semantics reboots while we are performing an exclusive create, +then the return value of NFS4ERR_DELAY when we replay the open +during the grace period causes us to lose the verifier. +When the grace period expires, and we present a new verifier, +the server will then correctly reply NFS4ERR_EXIST. + +This commit ensures that we always present the same verifier when +replaying the OPEN. + +Reported-by: Tigran Mkrtchyan +Signed-off-by: Trond Myklebust +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + fs/nfs/nfs4proc.c | 41 ++++++++++++++++++++++++++--------------- + 1 file changed, 26 insertions(+), 15 deletions(-) + +diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c +index a225f98c9903..209a21ed5f97 100644 +--- a/fs/nfs/nfs4proc.c ++++ b/fs/nfs/nfs4proc.c +@@ -1099,6 +1099,12 @@ struct nfs4_opendata { + int rpc_status; + }; + ++struct nfs4_open_createattrs { ++ struct nfs4_label *label; ++ struct iattr *sattr; ++ const __u32 verf[2]; ++}; ++ + static bool nfs4_clear_cap_atomic_open_v1(struct nfs_server *server, + int err, struct nfs4_exception *exception) + { +@@ -1168,8 +1174,7 @@ static void nfs4_init_opendata_res(struct nfs4_opendata *p) + + static struct nfs4_opendata *nfs4_opendata_alloc(struct dentry *dentry, + struct nfs4_state_owner *sp, fmode_t fmode, int flags, +- const struct iattr *attrs, +- struct nfs4_label *label, ++ const struct nfs4_open_createattrs *c, + enum open_claim_type4 claim, + gfp_t gfp_mask) + { +@@ -1177,6 +1182,7 @@ static struct nfs4_opendata *nfs4_opendata_alloc(struct dentry *dentry, + struct inode *dir = d_inode(parent); + struct nfs_server *server = NFS_SERVER(dir); + struct nfs_seqid *(*alloc_seqid)(struct nfs_seqid_counter *, gfp_t); ++ struct nfs4_label *label = (c != NULL) ? c->label : NULL; + struct nfs4_opendata *p; + + p = kzalloc(sizeof(*p), gfp_mask); +@@ -1242,15 +1248,11 @@ static struct nfs4_opendata *nfs4_opendata_alloc(struct dentry *dentry, + case NFS4_OPEN_CLAIM_DELEG_PREV_FH: + p->o_arg.fh = NFS_FH(d_inode(dentry)); + } +- if (attrs != NULL && attrs->ia_valid != 0) { +- __u32 verf[2]; +- ++ if (c != NULL && c->sattr != NULL && c->sattr->ia_valid != 0) { + p->o_arg.u.attrs = &p->attrs; +- memcpy(&p->attrs, attrs, sizeof(p->attrs)); ++ memcpy(&p->attrs, c->sattr, sizeof(p->attrs)); + +- verf[0] = jiffies; +- verf[1] = current->pid; +- memcpy(p->o_arg.u.verifier.data, verf, ++ memcpy(p->o_arg.u.verifier.data, c->verf, + sizeof(p->o_arg.u.verifier.data)); + } + p->c_arg.fh = &p->o_res.fh; +@@ -1816,7 +1818,7 @@ static struct nfs4_opendata *nfs4_open_recoverdata_alloc(struct nfs_open_context + struct nfs4_opendata *opendata; + + opendata = nfs4_opendata_alloc(ctx->dentry, state->owner, 0, 0, +- NULL, NULL, claim, GFP_NOFS); ++ NULL, claim, GFP_NOFS); + if (opendata == NULL) + return ERR_PTR(-ENOMEM); + opendata->state = state; +@@ -2757,8 +2759,7 @@ static int _nfs4_open_and_get_state(struct nfs4_opendata *opendata, + static int _nfs4_do_open(struct inode *dir, + struct nfs_open_context *ctx, + int flags, +- struct iattr *sattr, +- struct nfs4_label *label, ++ const struct nfs4_open_createattrs *c, + int *opened) + { + struct nfs4_state_owner *sp; +@@ -2770,6 +2771,8 @@ static int _nfs4_do_open(struct inode *dir, + struct nfs4_threshold **ctx_th = &ctx->mdsthreshold; + fmode_t fmode = ctx->mode & (FMODE_READ|FMODE_WRITE|FMODE_EXEC); + enum open_claim_type4 claim = NFS4_OPEN_CLAIM_NULL; ++ struct iattr *sattr = c->sattr; ++ struct nfs4_label *label = c->label; + struct nfs4_label *olabel = NULL; + int status; + +@@ -2788,8 +2791,8 @@ static int _nfs4_do_open(struct inode *dir, + status = -ENOMEM; + if (d_really_is_positive(dentry)) + claim = NFS4_OPEN_CLAIM_FH; +- opendata = nfs4_opendata_alloc(dentry, sp, fmode, flags, sattr, +- label, claim, GFP_KERNEL); ++ opendata = nfs4_opendata_alloc(dentry, sp, fmode, flags, ++ c, claim, GFP_KERNEL); + if (opendata == NULL) + goto err_put_state_owner; + +@@ -2870,10 +2873,18 @@ static struct nfs4_state *nfs4_do_open(struct inode *dir, + struct nfs_server *server = NFS_SERVER(dir); + struct nfs4_exception exception = { }; + struct nfs4_state *res; ++ struct nfs4_open_createattrs c = { ++ .label = label, ++ .sattr = sattr, ++ .verf = { ++ [0] = (__u32)jiffies, ++ [1] = (__u32)current->pid, ++ }, ++ }; + int status; + + do { +- status = _nfs4_do_open(dir, ctx, flags, sattr, label, opened); ++ status = _nfs4_do_open(dir, ctx, flags, &c, opened); + res = ctx->state; + trace_nfs4_open_file(ctx, flags, status); + if (status == 0) +-- +2.20.1 + diff --git a/queue-4.14/pci-dwc-pci-dra7xx-fix-compilation-when-config_gpiol.patch b/queue-4.14/pci-dwc-pci-dra7xx-fix-compilation-when-config_gpiol.patch new file mode 100644 index 00000000000..81bf8a78576 --- /dev/null +++ b/queue-4.14/pci-dwc-pci-dra7xx-fix-compilation-when-config_gpiol.patch @@ -0,0 +1,54 @@ +From 1effaa85007603382e83b8e61430bfac968ce9a2 Mon Sep 17 00:00:00 2001 +From: YueHaibing +Date: Fri, 14 Jun 2019 23:40:44 +0800 +Subject: PCI: dwc: pci-dra7xx: Fix compilation when !CONFIG_GPIOLIB +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit 381ed79c8655a40268ee7391f716edd90c5c3a97 ] + +If CONFIG_GPIOLIB is not selected the compilation results in the +following build errors: + +drivers/pci/controller/dwc/pci-dra7xx.c: + In function dra7xx_pcie_probe: +drivers/pci/controller/dwc/pci-dra7xx.c:777:10: + error: implicit declaration of function devm_gpiod_get_optional; + did you mean devm_regulator_get_optional? [-Werror=implicit-function-declaration] + + reset = devm_gpiod_get_optional(dev, NULL, GPIOD_OUT_HIGH); + +drivers/pci/controller/dwc/pci-dra7xx.c:778:45: error: ‘GPIOD_OUT_HIGH’ +undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? + reset = devm_gpiod_get_optional(dev, NULL, GPIOD_OUT_HIGH); + ^~~~~~~~~~~~~~ + GPIOF_INIT_HIGH + +Fix them by including the appropriate header file. + +Reported-by: Hulk Robot +Signed-off-by: YueHaibing +[lorenzo.pieralisi@arm.com: commit log] +Signed-off-by: Lorenzo Pieralisi +Acked-by: Kishon Vijay Abraham I +Signed-off-by: Sasha Levin +--- + drivers/pci/dwc/pci-dra7xx.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c +index 06eae132aff7..63052c5e5f82 100644 +--- a/drivers/pci/dwc/pci-dra7xx.c ++++ b/drivers/pci/dwc/pci-dra7xx.c +@@ -29,6 +29,7 @@ + #include + #include + #include ++#include + + #include "pcie-designware.h" + +-- +2.20.1 + diff --git a/queue-4.14/pci-return-error-if-cannot-probe-vf.patch b/queue-4.14/pci-return-error-if-cannot-probe-vf.patch new file mode 100644 index 00000000000..171d8fdc04f --- /dev/null +++ b/queue-4.14/pci-return-error-if-cannot-probe-vf.patch @@ -0,0 +1,63 @@ +From 69da15ce7f634cf25edb4e64bf82a516106f7232 Mon Sep 17 00:00:00 2001 +From: Alex Williamson +Date: Wed, 1 May 2019 11:00:16 -0600 +Subject: PCI: Return error if cannot probe VF + +[ Upstream commit 76002d8b48c4b08c9bd414517dd295e132ad910b ] + +Commit 0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control +VF driver binding") allows the user to specify that drivers for VFs of +a PF should not be probed, but it actually causes pci_device_probe() to +return success back to the driver core in this case. Therefore by all +sysfs appearances the device is bound to a driver, the driver link from +the device exists as does the device link back from the driver, yet the +driver's probe function is never called on the device. We also fail to +do any sort of cleanup when we're prohibited from probing the device, +the IRQ setup remains in place and we even hold a device reference. + +Instead, abort with errno before any setup or references are taken when +pci_device_can_probe() prevents us from trying to probe the device. + +Link: https://lore.kernel.org/lkml/155672991496.20698.4279330795743262888.stgit@gimli.home +Fixes: 0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control VF driver binding") +Signed-off-by: Alex Williamson +Signed-off-by: Bjorn Helgaas +Signed-off-by: Sasha Levin +--- + drivers/pci/pci-driver.c | 13 +++++++------ + 1 file changed, 7 insertions(+), 6 deletions(-) + +diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c +index ea69b4dbab66..e5a8bf2c9b37 100644 +--- a/drivers/pci/pci-driver.c ++++ b/drivers/pci/pci-driver.c +@@ -415,6 +415,9 @@ static int pci_device_probe(struct device *dev) + struct pci_dev *pci_dev = to_pci_dev(dev); + struct pci_driver *drv = to_pci_driver(dev->driver); + ++ if (!pci_device_can_probe(pci_dev)) ++ return -ENODEV; ++ + pci_assign_irq(pci_dev); + + error = pcibios_alloc_irq(pci_dev); +@@ -422,12 +425,10 @@ static int pci_device_probe(struct device *dev) + return error; + + pci_dev_get(pci_dev); +- if (pci_device_can_probe(pci_dev)) { +- error = __pci_device_probe(drv, pci_dev); +- if (error) { +- pcibios_free_irq(pci_dev); +- pci_dev_put(pci_dev); +- } ++ error = __pci_device_probe(drv, pci_dev); ++ if (error) { ++ pcibios_free_irq(pci_dev); ++ pci_dev_put(pci_dev); + } + + return error; +-- +2.20.1 + diff --git a/queue-4.14/pci-sysfs-ignore-lockdep-for-remove-attribute.patch b/queue-4.14/pci-sysfs-ignore-lockdep-for-remove-attribute.patch new file mode 100644 index 00000000000..97a2851e33d --- /dev/null +++ b/queue-4.14/pci-sysfs-ignore-lockdep-for-remove-attribute.patch @@ -0,0 +1,61 @@ +From d3d8853ad994bbdd060b4763742121eca507b9ee Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Mon, 27 May 2019 00:51:51 +0200 +Subject: PCI: sysfs: Ignore lockdep for remove attribute + +[ Upstream commit dc6b698a86fe40a50525433eb8e92a267847f6f9 ] + +With CONFIG_PROVE_LOCKING=y, using sysfs to remove a bridge with a device +below it causes a lockdep warning, e.g., + + # echo 1 > /sys/class/pci_bus/0000:00/device/0000:00:00.0/remove + ============================================ + WARNING: possible recursive locking detected + ... + pci_bus 0000:01: busn_res: [bus 01] is released + +The remove recursively removes the subtree below the bridge. Each call +uses a different lock so there's no deadlock, but the locks were all +created with the same lockdep key so the lockdep checker can't tell them +apart. + +Mark the "remove" sysfs attribute with __ATTR_IGNORE_LOCKDEP() as it is +safe to ignore the lockdep check between different "remove" kernfs +instances. + +There's discussion about a similar issue in USB at [1], which resulted in +356c05d58af0 ("sysfs: get rid of some lockdep false positives") and +e9b526fe7048 ("i2c: suppress lockdep warning on delete_device"), which do +basically the same thing for USB "remove" and i2c "delete_device" files. + +[1] https://lore.kernel.org/r/Pine.LNX.4.44L0.1204251436140.1206-100000@iolanthe.rowland.org +Link: https://lore.kernel.org/r/20190526225151.3865-1-marek.vasut@gmail.com +Signed-off-by: Marek Vasut +[bhelgaas: trim commit log, details at above links] +Signed-off-by: Bjorn Helgaas +Cc: Geert Uytterhoeven +Cc: Phil Edworthy +Cc: Simon Horman +Cc: Tejun Heo +Cc: Wolfram Sang +Signed-off-by: Sasha Levin +--- + drivers/pci/pci-sysfs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c +index c3f0473d1afa..ee7dccab771d 100644 +--- a/drivers/pci/pci-sysfs.c ++++ b/drivers/pci/pci-sysfs.c +@@ -496,7 +496,7 @@ static ssize_t remove_store(struct device *dev, struct device_attribute *attr, + pci_stop_and_remove_bus_device_locked(to_pci_dev(dev)); + return count; + } +-static struct device_attribute dev_remove_attr = __ATTR(remove, ++static struct device_attribute dev_remove_attr = __ATTR_IGNORE_LOCKDEP(remove, + (S_IWUSR|S_IWGRP), + NULL, remove_store); + +-- +2.20.1 + diff --git a/queue-4.14/pci-xilinx-nwl-fix-multi-msi-data-programming.patch b/queue-4.14/pci-xilinx-nwl-fix-multi-msi-data-programming.patch new file mode 100644 index 00000000000..1920f6705c9 --- /dev/null +++ b/queue-4.14/pci-xilinx-nwl-fix-multi-msi-data-programming.patch @@ -0,0 +1,97 @@ +From 5e007409607efe63701aa82679b8eccdbfc1bbfd Mon Sep 17 00:00:00 2001 +From: Bharat Kumar Gogada +Date: Wed, 12 Jun 2019 15:47:59 +0530 +Subject: PCI: xilinx-nwl: Fix Multi MSI data programming + +[ Upstream commit 181fa434d0514e40ebf6e9721f2b72700287b6e2 ] + +According to the PCI Local Bus specification Revision 3.0, +section 6.8.1.3 (Message Control for MSI), endpoints that +are Multiple Message Capable as defined by bits [3:1] in +the Message Control for MSI can request a number of vectors +that is power of two aligned. + +As specified in section 6.8.1.6 "Message data for MSI", the Multiple +Message Enable field (bits [6:4] of the Message Control register) +defines the number of low order message data bits the function is +permitted to modify to generate its system software allocated +vectors. + +The MSI controller in the Xilinx NWL PCIe controller supports a number +of MSI vectors specified through a bitmap and the hwirq number for an +MSI, that is the value written in the MSI data TLP is determined by +the bitmap allocation. + +For instance, in a situation where two endpoints sitting on +the PCI bus request the following MSI configuration, with +the current PCI Xilinx bitmap allocation code (that does not +align MSI vector allocation on a power of two boundary): + +Endpoint #1: Requesting 1 MSI vector - allocated bitmap bits 0 +Endpoint #2: Requesting 2 MSI vectors - allocated bitmap bits [1,2] + +The bitmap value(s) corresponds to the hwirq number that is programmed +into the Message Data for MSI field in the endpoint MSI capability +and is detected by the root complex to fire the corresponding +MSI irqs. The value written in Message Data for MSI field corresponds +to the first bit allocated in the bitmap for Multi MSI vectors. + +The current Xilinx NWL MSI allocation code allows a bitmap allocation +that is not a power of two boundaries, so endpoint #2, is allowed to +toggle Message Data bit[0] to differentiate between its two vectors +(meaning that the MSI data will be respectively 0x0 and 0x1 for the two +vectors allocated to endpoint #2). + +This clearly aliases with the Endpoint #1 vector allocation, resulting +in a broken Multi MSI implementation. + +Update the code to allocate MSI bitmap ranges with a power of two +alignment, fixing the bug. + +Fixes: ab597d35ef11 ("PCI: xilinx-nwl: Add support for Xilinx NWL PCIe Host Controller") +Suggested-by: Marc Zyngier +Signed-off-by: Bharat Kumar Gogada +[lorenzo.pieralisi@arm.com: updated commit log] +Signed-off-by: Lorenzo Pieralisi +Acked-by: Marc Zyngier +Signed-off-by: Sasha Levin +--- + drivers/pci/host/pcie-xilinx-nwl.c | 11 +++++------ + 1 file changed, 5 insertions(+), 6 deletions(-) + +diff --git a/drivers/pci/host/pcie-xilinx-nwl.c b/drivers/pci/host/pcie-xilinx-nwl.c +index dd527ea558d7..981a5195686f 100644 +--- a/drivers/pci/host/pcie-xilinx-nwl.c ++++ b/drivers/pci/host/pcie-xilinx-nwl.c +@@ -485,15 +485,13 @@ static int nwl_irq_domain_alloc(struct irq_domain *domain, unsigned int virq, + int i; + + mutex_lock(&msi->lock); +- bit = bitmap_find_next_zero_area(msi->bitmap, INT_PCI_MSI_NR, 0, +- nr_irqs, 0); +- if (bit >= INT_PCI_MSI_NR) { ++ bit = bitmap_find_free_region(msi->bitmap, INT_PCI_MSI_NR, ++ get_count_order(nr_irqs)); ++ if (bit < 0) { + mutex_unlock(&msi->lock); + return -ENOSPC; + } + +- bitmap_set(msi->bitmap, bit, nr_irqs); +- + for (i = 0; i < nr_irqs; i++) { + irq_domain_set_info(domain, virq + i, bit + i, &nwl_irq_chip, + domain->host_data, handle_simple_irq, +@@ -511,7 +509,8 @@ static void nwl_irq_domain_free(struct irq_domain *domain, unsigned int virq, + struct nwl_msi *msi = &pcie->msi; + + mutex_lock(&msi->lock); +- bitmap_clear(msi->bitmap, data->hwirq, nr_irqs); ++ bitmap_release_region(msi->bitmap, data->hwirq, ++ get_count_order(nr_irqs)); + mutex_unlock(&msi->lock); + } + +-- +2.20.1 + diff --git a/queue-4.14/perf-annotate-fix-dereferencing-freed-memory-found-b.patch b/queue-4.14/perf-annotate-fix-dereferencing-freed-memory-found-b.patch new file mode 100644 index 00000000000..6b144453472 --- /dev/null +++ b/queue-4.14/perf-annotate-fix-dereferencing-freed-memory-found-b.patch @@ -0,0 +1,103 @@ +From 3c304b85f7e05c8eab73cd8b7c9de35dff715254 Mon Sep 17 00:00:00 2001 +From: Leo Yan +Date: Tue, 2 Jul 2019 18:34:13 +0800 +Subject: perf annotate: Fix dereferencing freed memory found by the smatch + tool + +[ Upstream commit 600c787dbf6521d8d07ee717ab7606d5070103ea ] + +Based on the following report from Smatch, fix the potential +dereferencing freed memory check. + + tools/perf/util/annotate.c:1125 + disasm_line__parse() error: dereferencing freed memory 'namep' + + tools/perf/util/annotate.c + 1100 static int disasm_line__parse(char *line, const char **namep, char **rawp) + 1101 { + 1102 char tmp, *name = ltrim(line); + + [...] + + 1114 *namep = strdup(name); + 1115 + 1116 if (*namep == NULL) + 1117 goto out_free_name; + + [...] + + 1124 out_free_name: + 1125 free((void *)namep); + ^^^^^ + 1126 *namep = NULL; + ^^^^^^ + 1127 return -1; + 1128 } + +If strdup() fails to allocate memory space for *namep, we don't need to +free memory with pointer 'namep', which is resident in data structure +disasm_line::ins::name; and *namep is NULL pointer for this failure, so +it's pointless to assign NULL to *namep again. + +Committer note: + +Freeing namep, which is the address of the first entry of the 'struct +ins' that is the first member of struct disasm_line would in fact free +that disasm_line instance, if it was allocated via malloc/calloc, which, +later, would a dereference of freed memory. + +Signed-off-by: Leo Yan +Acked-by: Jiri Olsa +Cc: Adrian Hunter +Cc: Alexander Shishkin +Cc: Alexey Budankov +Cc: Alexios Zavras +Cc: Andi Kleen +Cc: Changbin Du +Cc: David S. Miller +Cc: Davidlohr Bueso +Cc: Eric Saint-Etienne +Cc: Jin Yao +Cc: Konstantin Khlebnikov +Cc: Mathieu Poirier +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: Rasmus Villemoes +Cc: Song Liu +Cc: Suzuki Poulouse +Cc: Thomas Gleixner +Cc: Thomas Richter +Cc: linux-arm-kernel@lists.infradead.org +Link: http://lkml.kernel.org/r/20190702103420.27540-5-leo.yan@linaro.org +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Sasha Levin +--- + tools/perf/util/annotate.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c +index 398d4cc2f0e4..2a8d2a6723f6 100644 +--- a/tools/perf/util/annotate.c ++++ b/tools/perf/util/annotate.c +@@ -868,16 +868,14 @@ static int disasm_line__parse(char *line, const char **namep, char **rawp) + *namep = strdup(name); + + if (*namep == NULL) +- goto out_free_name; ++ goto out; + + (*rawp)[0] = tmp; + *rawp = ltrim(*rawp); + + return 0; + +-out_free_name: +- free((void *)namep); +- *namep = NULL; ++out: + return -1; + } + +-- +2.20.1 + diff --git a/queue-4.14/perf-events-amd-uncore-fix-amd_uncore_llc-id-to-use-.patch b/queue-4.14/perf-events-amd-uncore-fix-amd_uncore_llc-id-to-use-.patch new file mode 100644 index 00000000000..f4082c528c1 --- /dev/null +++ b/queue-4.14/perf-events-amd-uncore-fix-amd_uncore_llc-id-to-use-.patch @@ -0,0 +1,67 @@ +From d1d765aed2e8c1674c6851297ee928c6abe4bb63 Mon Sep 17 00:00:00 2001 +From: Suravee Suthikulpanit +Date: Fri, 27 Apr 2018 16:34:35 -0500 +Subject: perf/events/amd/uncore: Fix amd_uncore_llc ID to use pre-defined + cpu_llc_id + +[ Upstream commit 812af433038f984fd951224e8239b09188e36a13 ] + +Current logic iterates over CPUID Fn8000001d leafs (Cache Properties) +to detect the last level cache, and derive the last-level cache ID. +However, this information is already available in the cpu_llc_id. +Therefore, make use of it instead. + +Signed-off-by: Suravee Suthikulpanit +Signed-off-by: Borislav Petkov +Signed-off-by: Thomas Gleixner +Cc: "Peter Zijlstra (Intel)" +Cc: Janakarajan Natarajan +Link: http://lkml.kernel.org/r/1524864877-111962-3-git-send-email-suravee.suthikulpanit@amd.com +Signed-off-by: Sasha Levin +--- + arch/x86/events/amd/uncore.c | 21 ++------------------- + 1 file changed, 2 insertions(+), 19 deletions(-) + +diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c +index 3a9ab16d9c2b..baa7e36073f9 100644 +--- a/arch/x86/events/amd/uncore.c ++++ b/arch/x86/events/amd/uncore.c +@@ -19,6 +19,7 @@ + #include + #include + #include ++#include + + #define NUM_COUNTERS_NB 4 + #define NUM_COUNTERS_L2 4 +@@ -414,26 +415,8 @@ static int amd_uncore_cpu_starting(unsigned int cpu) + } + + if (amd_uncore_llc) { +- unsigned int apicid = cpu_data(cpu).apicid; +- unsigned int nshared, subleaf, prev_eax = 0; +- + uncore = *per_cpu_ptr(amd_uncore_llc, cpu); +- /* +- * Iterate over Cache Topology Definition leaves until no +- * more cache descriptions are available. +- */ +- for (subleaf = 0; subleaf < 5; subleaf++) { +- cpuid_count(0x8000001d, subleaf, &eax, &ebx, &ecx, &edx); +- +- /* EAX[0:4] gives type of cache */ +- if (!(eax & 0x1f)) +- break; +- +- prev_eax = eax; +- } +- nshared = ((prev_eax >> 14) & 0xfff) + 1; +- +- uncore->id = apicid - (apicid % nshared); ++ uncore->id = per_cpu(cpu_llc_id, cpu); + + uncore = amd_uncore_find_online_sibling(uncore, amd_uncore_llc); + *per_cpu_ptr(amd_uncore_llc, cpu) = uncore; +-- +2.20.1 + diff --git a/queue-4.14/perf-session-fix-potential-null-pointer-dereference-.patch b/queue-4.14/perf-session-fix-potential-null-pointer-dereference-.patch new file mode 100644 index 00000000000..fe8190680fc --- /dev/null +++ b/queue-4.14/perf-session-fix-potential-null-pointer-dereference-.patch @@ -0,0 +1,80 @@ +From f2b7a8823c290e945801a7ec98a0858e76dbb757 Mon Sep 17 00:00:00 2001 +From: Leo Yan +Date: Tue, 2 Jul 2019 18:34:17 +0800 +Subject: perf session: Fix potential NULL pointer dereference found by the + smatch tool + +[ Upstream commit f3c8d90757724982e5f07cd77d315eb64ca145ac ] + +Based on the following report from Smatch, fix the potential +NULL pointer dereference check. + + tools/perf/util/session.c:1252 + dump_read() error: we previously assumed 'evsel' could be null + (see line 1249) + + tools/perf/util/session.c + 1240 static void dump_read(struct perf_evsel *evsel, union perf_event *event) + 1241 { + 1242 struct read_event *read_event = &event->read; + 1243 u64 read_format; + 1244 + 1245 if (!dump_trace) + 1246 return; + 1247 + 1248 printf(": %d %d %s %" PRIu64 "\n", event->read.pid, event->read.tid, + 1249 evsel ? perf_evsel__name(evsel) : "FAIL", + 1250 event->read.value); + 1251 + 1252 read_format = evsel->attr.read_format; + ^^^^^^^ + +'evsel' could be NULL pointer, for this case this patch directly bails +out without dumping read_event. + +Signed-off-by: Leo Yan +Acked-by: Jiri Olsa +Cc: Adrian Hunter +Cc: Alexander Shishkin +Cc: Alexey Budankov +Cc: Alexios Zavras +Cc: Andi Kleen +Cc: Changbin Du +Cc: David S. Miller +Cc: Davidlohr Bueso +Cc: Eric Saint-Etienne +Cc: Jin Yao +Cc: Konstantin Khlebnikov +Cc: Mathieu Poirier +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: Rasmus Villemoes +Cc: Song Liu +Cc: Suzuki Poulouse +Cc: Thomas Gleixner +Cc: Thomas Richter +Cc: linux-arm-kernel@lists.infradead.org +Link: http://lkml.kernel.org/r/20190702103420.27540-9-leo.yan@linaro.org +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Sasha Levin +--- + tools/perf/util/session.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c +index da55081aefc6..c49e8ea1a42c 100644 +--- a/tools/perf/util/session.c ++++ b/tools/perf/util/session.c +@@ -1145,6 +1145,9 @@ static void dump_read(struct perf_evsel *evsel, union perf_event *event) + evsel ? perf_evsel__name(evsel) : "FAIL", + event->read.value); + ++ if (!evsel) ++ return; ++ + read_format = evsel->attr.read_format; + + if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED) +-- +2.20.1 + diff --git a/queue-4.14/perf-test-mmap-thread-lookup-initialize-variable-to-.patch b/queue-4.14/perf-test-mmap-thread-lookup-initialize-variable-to-.patch new file mode 100644 index 00000000000..93862a9fa69 --- /dev/null +++ b/queue-4.14/perf-test-mmap-thread-lookup-initialize-variable-to-.patch @@ -0,0 +1,54 @@ +From 47bbd0edcf82a190c5d950bacf943559ec24926f Mon Sep 17 00:00:00 2001 +From: Numfor Mbiziwo-Tiapo +Date: Tue, 2 Jul 2019 10:37:15 -0700 +Subject: perf test mmap-thread-lookup: Initialize variable to suppress memory + sanitizer warning + +[ Upstream commit 4e4cf62b37da5ff45c904a3acf242ab29ed5881d ] + +Running the 'perf test' command after building perf with a memory +sanitizer causes a warning that says: + + WARNING: MemorySanitizer: use-of-uninitialized-value... in mmap-thread-lookup.c + +Initializing the go variable to 0 silences this harmless warning. + +Committer warning: + +This was harmless, just a simple test writing whatever was at that +sizeof(int) memory area just to signal another thread blocked reading +that file created with pipe(). Initialize it tho so that we don't get +this warning. + +Signed-off-by: Numfor Mbiziwo-Tiapo +Cc: Alexander Shishkin +Cc: Ian Rogers +Cc: Jiri Olsa +Cc: Mark Drayton +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: Song Liu +Cc: Stephane Eranian +Link: http://lkml.kernel.org/r/20190702173716.181223-1-nums@google.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Sasha Levin +--- + tools/perf/tests/mmap-thread-lookup.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/tools/perf/tests/mmap-thread-lookup.c b/tools/perf/tests/mmap-thread-lookup.c +index 3c3f3e029e33..2ecb86876f10 100644 +--- a/tools/perf/tests/mmap-thread-lookup.c ++++ b/tools/perf/tests/mmap-thread-lookup.c +@@ -52,7 +52,7 @@ static void *thread_fn(void *arg) + { + struct thread_data *td = arg; + ssize_t ret; +- int go; ++ int go = 0; + + if (thread_init(td)) + return NULL; +-- +2.20.1 + diff --git a/queue-4.14/phy-renesas-rcar-gen2-fix-memory-leak-at-error-paths.patch b/queue-4.14/phy-renesas-rcar-gen2-fix-memory-leak-at-error-paths.patch new file mode 100644 index 00000000000..414dbc77a34 --- /dev/null +++ b/queue-4.14/phy-renesas-rcar-gen2-fix-memory-leak-at-error-paths.patch @@ -0,0 +1,44 @@ +From 4f50c08bf8573ac6fb5cd518b880882f11247ea8 Mon Sep 17 00:00:00 2001 +From: Yoshihiro Shimoda +Date: Tue, 28 May 2019 14:04:02 +0900 +Subject: phy: renesas: rcar-gen2: Fix memory leak at error paths + +[ Upstream commit d4a36e82924d3305a17ac987a510f3902df5a4b2 ] + +This patch fixes memory leak at error paths of the probe function. +In for_each_child_of_node, if the loop returns, the driver should +call of_put_node() before returns. + +Reported-by: Julia Lawall +Fixes: 1233f59f745b237 ("phy: Renesas R-Car Gen2 PHY driver") +Signed-off-by: Yoshihiro Shimoda +Reviewed-by: Geert Uytterhoeven +Signed-off-by: Kishon Vijay Abraham I +Signed-off-by: Sasha Levin +--- + drivers/phy/renesas/phy-rcar-gen2.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c +index 97d4dd6ea924..aa02b19b7e0e 100644 +--- a/drivers/phy/renesas/phy-rcar-gen2.c ++++ b/drivers/phy/renesas/phy-rcar-gen2.c +@@ -288,6 +288,7 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev) + error = of_property_read_u32(np, "reg", &channel_num); + if (error || channel_num > 2) { + dev_err(dev, "Invalid \"reg\" property\n"); ++ of_node_put(np); + return error; + } + channel->select_mask = select_mask[channel_num]; +@@ -303,6 +304,7 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev) + &rcar_gen2_phy_ops); + if (IS_ERR(phy->phy)) { + dev_err(dev, "Failed to create PHY\n"); ++ of_node_put(np); + return PTR_ERR(phy->phy); + } + phy_set_drvdata(phy->phy, phy); +-- +2.20.1 + diff --git a/queue-4.14/pinctrl-rockchip-fix-leaked-of_node-references.patch b/queue-4.14/pinctrl-rockchip-fix-leaked-of_node-references.patch new file mode 100644 index 00000000000..2e680bb6dee --- /dev/null +++ b/queue-4.14/pinctrl-rockchip-fix-leaked-of_node-references.patch @@ -0,0 +1,42 @@ +From 765d8a053115940e4714474ee48acb477f1c3b35 Mon Sep 17 00:00:00 2001 +From: Wen Yang +Date: Mon, 15 Apr 2019 14:24:02 +0800 +Subject: pinctrl: rockchip: fix leaked of_node references + +[ Upstream commit 3c89c70634bb0b6f48512de873e7a45c7e1fbaa5 ] + +The call to of_parse_phandle returns a node pointer with refcount +incremented thus it must be explicitly decremented after the last +usage. + +Detected by coccinelle with the following warnings: +./drivers/pinctrl/pinctrl-rockchip.c:3221:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3196, but without a corresponding object release within this function. +./drivers/pinctrl/pinctrl-rockchip.c:3223:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3196, but without a corresponding object release within this function. + +Signed-off-by: Wen Yang +Cc: Linus Walleij +Cc: Heiko Stuebner +Cc: linux-gpio@vger.kernel.org +Cc: linux-rockchip@lists.infradead.org +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Linus Walleij +Signed-off-by: Sasha Levin +--- + drivers/pinctrl/pinctrl-rockchip.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c +index a9bc1e01f982..5d6cf024ee9c 100644 +--- a/drivers/pinctrl/pinctrl-rockchip.c ++++ b/drivers/pinctrl/pinctrl-rockchip.c +@@ -2941,6 +2941,7 @@ static int rockchip_get_bank_data(struct rockchip_pin_bank *bank, + base, + &rockchip_regmap_config); + } ++ of_node_put(node); + } + + bank->irq = irq_of_parse_and_map(bank->of_node, 0); +-- +2.20.1 + diff --git a/queue-4.14/powerpc-4xx-uic-clear-pending-interrupt-after-irq-ty.patch b/queue-4.14/powerpc-4xx-uic-clear-pending-interrupt-after-irq-ty.patch new file mode 100644 index 00000000000..e3642f8d659 --- /dev/null +++ b/queue-4.14/powerpc-4xx-uic-clear-pending-interrupt-after-irq-ty.patch @@ -0,0 +1,38 @@ +From 5e14f5d1b6fc03b7814f654684d7a5966b69ca83 Mon Sep 17 00:00:00 2001 +From: Christian Lamparter +Date: Sat, 15 Jun 2019 17:23:13 +0200 +Subject: powerpc/4xx/uic: clear pending interrupt after irq type/pol change + +[ Upstream commit 3ab3a0689e74e6aa5b41360bc18861040ddef5b1 ] + +When testing out gpio-keys with a button, a spurious +interrupt (and therefore a key press or release event) +gets triggered as soon as the driver enables the irq +line for the first time. + +This patch clears any potential bogus generated interrupt +that was caused by the switching of the associated irq's +type and polarity. + +Signed-off-by: Christian Lamparter +Signed-off-by: Michael Ellerman +Signed-off-by: Sasha Levin +--- + arch/powerpc/platforms/4xx/uic.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/arch/powerpc/platforms/4xx/uic.c b/arch/powerpc/platforms/4xx/uic.c +index 8b4dd0da0839..9e27cfe27026 100644 +--- a/arch/powerpc/platforms/4xx/uic.c ++++ b/arch/powerpc/platforms/4xx/uic.c +@@ -158,6 +158,7 @@ static int uic_set_irq_type(struct irq_data *d, unsigned int flow_type) + + mtdcr(uic->dcrbase + UIC_PR, pr); + mtdcr(uic->dcrbase + UIC_TR, tr); ++ mtdcr(uic->dcrbase + UIC_SR, ~mask); + + raw_spin_unlock_irqrestore(&uic->lock, flags); + +-- +2.20.1 + diff --git a/queue-4.14/powerpc-boot-add-get-put-_unaligned_be32-to-xz_confi.patch b/queue-4.14/powerpc-boot-add-get-put-_unaligned_be32-to-xz_confi.patch new file mode 100644 index 00000000000..e99fe31132b --- /dev/null +++ b/queue-4.14/powerpc-boot-add-get-put-_unaligned_be32-to-xz_confi.patch @@ -0,0 +1,102 @@ +From 133f87d20d8b6c21e8a33983e923e5c4aa530ceb Mon Sep 17 00:00:00 2001 +From: Masahiro Yamada +Date: Fri, 5 Jul 2019 19:01:43 +0900 +Subject: powerpc/boot: add {get, put}_unaligned_be32 to xz_config.h + +[ Upstream commit 9e005b761e7ad153dcf40a6cba1d681fe0830ac6 ] + +The next commit will make the way of passing CONFIG options more robust. +Unfortunately, it would uncover another hidden issue; without this +commit, skiroot_defconfig would be broken like this: + +| WRAP arch/powerpc/boot/zImage.pseries +| arch/powerpc/boot/wrapper.a(decompress.o): In function `bcj_powerpc.isra.10': +| decompress.c:(.text+0x720): undefined reference to `get_unaligned_be32' +| decompress.c:(.text+0x7a8): undefined reference to `put_unaligned_be32' +| make[1]: *** [arch/powerpc/boot/Makefile;383: arch/powerpc/boot/zImage.pseries] Error 1 +| make: *** [arch/powerpc/Makefile;295: zImage] Error 2 + +skiroot_defconfig is the only defconfig that enables CONFIG_KERNEL_XZ +for ppc, which has never been correctly built before. + +I figured out the root cause in lib/decompress_unxz.c: + +| #ifdef CONFIG_PPC +| # define XZ_DEC_POWERPC +| #endif + +CONFIG_PPC is undefined here in the ppc bootwrapper because autoconf.h +is not included except by arch/powerpc/boot/serial.c + +XZ_DEC_POWERPC is not defined, therefore, bcj_powerpc() is not compiled +for the bootwrapper. + +With the next commit passing CONFIG_PPC correctly, we would realize that +{get,put}_unaligned_be32 was missing. + +Unlike the other decompressors, the ppc bootwrapper duplicates all the +necessary helpers in arch/powerpc/boot/. + +The other architectures define __KERNEL__ and pull in helpers for +building the decompressors. + +If ppc bootwrapper had defined __KERNEL__, lib/xz/xz_private.h would +have included : + +| #ifdef __KERNEL__ +| # include +| # include +| # include + +However, doing so would cause tons of definition conflicts since the +bootwrapper has duplicated everything. + +I just added copies of {get,put}_unaligned_be32, following the +bootwrapper coding convention. + +Signed-off-by: Masahiro Yamada +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20190705100144.28785-1-yamada.masahiro@socionext.com +Signed-off-by: Sasha Levin +--- + arch/powerpc/boot/xz_config.h | 20 ++++++++++++++++++++ + 1 file changed, 20 insertions(+) + +diff --git a/arch/powerpc/boot/xz_config.h b/arch/powerpc/boot/xz_config.h +index e22e5b3770dd..ebfadd39e192 100644 +--- a/arch/powerpc/boot/xz_config.h ++++ b/arch/powerpc/boot/xz_config.h +@@ -20,10 +20,30 @@ static inline uint32_t swab32p(void *p) + + #ifdef __LITTLE_ENDIAN__ + #define get_le32(p) (*((uint32_t *) (p))) ++#define cpu_to_be32(x) swab32(x) ++static inline u32 be32_to_cpup(const u32 *p) ++{ ++ return swab32p((u32 *)p); ++} + #else + #define get_le32(p) swab32p(p) ++#define cpu_to_be32(x) (x) ++static inline u32 be32_to_cpup(const u32 *p) ++{ ++ return *p; ++} + #endif + ++static inline uint32_t get_unaligned_be32(const void *p) ++{ ++ return be32_to_cpup(p); ++} ++ ++static inline void put_unaligned_be32(u32 val, void *p) ++{ ++ *((u32 *)p) = cpu_to_be32(val); ++} ++ + #define memeq(a, b, size) (memcmp(a, b, size) == 0) + #define memzero(buf, size) memset(buf, 0, size) + +-- +2.20.1 + diff --git a/queue-4.14/powerpc-eeh-handle-hugepages-in-ioremap-space.patch b/queue-4.14/powerpc-eeh-handle-hugepages-in-ioremap-space.patch new file mode 100644 index 00000000000..32a3b551c1e --- /dev/null +++ b/queue-4.14/powerpc-eeh-handle-hugepages-in-ioremap-space.patch @@ -0,0 +1,68 @@ +From d3fa330ffb1c92455d7ab9b1ebe13142ce1834f9 Mon Sep 17 00:00:00 2001 +From: Oliver O'Halloran +Date: Thu, 11 Jul 2019 01:05:17 +1000 +Subject: powerpc/eeh: Handle hugepages in ioremap space + +[ Upstream commit 33439620680be5225c1b8806579a291e0d761ca0 ] + +In commit 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap +space") support for using hugepages in the vmalloc and ioremap areas was +enabled for radix. Unfortunately this broke EEH MMIO error checking. + +Detection works by inserting a hook which checks the results of the +ioreadXX() set of functions. When a read returns a 0xFFs response we +need to check for an error which we do by mapping the (virtual) MMIO +address back to a physical address, then mapping physical address to a +PCI device via an interval tree. + +When translating virt -> phys we currently assume the ioremap space is +only populated by PAGE_SIZE mappings. If a hugepage mapping is found we +emit a WARN_ON(), but otherwise handles the check as though a normal +page was found. In pathalogical cases such as copying a buffer +containing a lot of 0xFFs from BAR memory this can result in the system +not booting because it's too busy printing WARN_ON()s. + +There's no real reason to assume huge pages can't be present and we're +prefectly capable of handling them, so do that. + +Fixes: 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap space") +Reported-by: Sachin Sant +Signed-off-by: Oliver O'Halloran +Tested-by: Sachin Sant +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20190710150517.27114-1-oohall@gmail.com +Signed-off-by: Sasha Levin +--- + arch/powerpc/kernel/eeh.c | 15 ++++++++++++--- + 1 file changed, 12 insertions(+), 3 deletions(-) + +diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c +index 45322b37669a..d2ba7936d0d3 100644 +--- a/arch/powerpc/kernel/eeh.c ++++ b/arch/powerpc/kernel/eeh.c +@@ -361,10 +361,19 @@ static inline unsigned long eeh_token_to_phys(unsigned long token) + ptep = find_init_mm_pte(token, &hugepage_shift); + if (!ptep) + return token; +- WARN_ON(hugepage_shift); +- pa = pte_pfn(*ptep) << PAGE_SHIFT; + +- return pa | (token & (PAGE_SIZE-1)); ++ pa = pte_pfn(*ptep); ++ ++ /* On radix we can do hugepage mappings for io, so handle that */ ++ if (hugepage_shift) { ++ pa <<= hugepage_shift; ++ pa |= token & ((1ul << hugepage_shift) - 1); ++ } else { ++ pa <<= PAGE_SHIFT; ++ pa |= token & (PAGE_SIZE - 1); ++ } ++ ++ return pa; + } + + /* +-- +2.20.1 + diff --git a/queue-4.14/powerpc-pci-of-fix-of-flags-parsing-for-64bit-bars.patch b/queue-4.14/powerpc-pci-of-fix-of-flags-parsing-for-64bit-bars.patch new file mode 100644 index 00000000000..a57fa4a3626 --- /dev/null +++ b/queue-4.14/powerpc-pci-of-fix-of-flags-parsing-for-64bit-bars.patch @@ -0,0 +1,65 @@ +From 6c5c498ba3ff040f66638dd938a68e85e22f29c5 Mon Sep 17 00:00:00 2001 +From: Alexey Kardashevskiy +Date: Wed, 5 Jun 2019 13:38:14 +1000 +Subject: powerpc/pci/of: Fix OF flags parsing for 64bit BARs + +[ Upstream commit df5be5be8735ef2ae80d5ae1f2453cd81a035c4b ] + +When the firmware does PCI BAR resource allocation, it passes the assigned +addresses and flags (prefetch/64bit/...) via the "reg" property of +a PCI device device tree node so the kernel does not need to do +resource allocation. + +The flags are stored in resource::flags - the lower byte stores +PCI_BASE_ADDRESS_SPACE/etc bits and the other bytes are IORESOURCE_IO/etc. +Some flags from PCI_BASE_ADDRESS_xxx and IORESOURCE_xxx are duplicated, +such as PCI_BASE_ADDRESS_MEM_PREFETCH/PCI_BASE_ADDRESS_MEM_TYPE_64/etc. +When parsing the "reg" property, we copy the prefetch flag but we skip +on PCI_BASE_ADDRESS_MEM_TYPE_64 which leaves the flags out of sync. + +The missing IORESOURCE_MEM_64 flag comes into play under 2 conditions: +1. we remove PCI_PROBE_ONLY for pseries (by hacking pSeries_setup_arch() +or by passing "/chosen/linux,pci-probe-only"); +2. we request resource alignment (by passing pci=resource_alignment= +via the kernel cmd line to request PAGE_SIZE alignment or defining +ppc_md.pcibios_default_alignment which returns anything but 0). Note that +the alignment requests are ignored if PCI_PROBE_ONLY is enabled. + +With 1) and 2), the generic PCI code in the kernel unconditionally +decides to: +- reassign the BARs in pci_specified_resource_alignment() (works fine) +- write new BARs to the device - this fails for 64bit BARs as the generic +code looks at IORESOURCE_MEM_64 (not set) and writes only lower 32bits +of the BAR and leaves the upper 32bit unmodified which breaks BAR mapping +in the hypervisor. + +This fixes the issue by copying the flag. This is useful if we want to +enforce certain BAR alignment per platform as handling subpage sized BARs +is proven to cause problems with hotplug (SLOF already aligns BARs to 64k). + +Signed-off-by: Alexey Kardashevskiy +Reviewed-by: Sam Bobroff +Reviewed-by: Oliver O'Halloran +Reviewed-by: Shawn Anastasio +Signed-off-by: Michael Ellerman +Signed-off-by: Sasha Levin +--- + arch/powerpc/kernel/pci_of_scan.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c +index 0d790f8432d2..6ca1b3a1e196 100644 +--- a/arch/powerpc/kernel/pci_of_scan.c ++++ b/arch/powerpc/kernel/pci_of_scan.c +@@ -45,6 +45,8 @@ static unsigned int pci_parse_of_flags(u32 addr0, int bridge) + if (addr0 & 0x02000000) { + flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY; + flags |= (addr0 >> 22) & PCI_BASE_ADDRESS_MEM_TYPE_64; ++ if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) ++ flags |= IORESOURCE_MEM_64; + flags |= (addr0 >> 28) & PCI_BASE_ADDRESS_MEM_TYPE_1M; + if (addr0 & 0x40000000) + flags |= IORESOURCE_PREFETCH +-- +2.20.1 + diff --git a/queue-4.14/powerpc-pseries-mobility-prevent-cpu-hotplug-during-.patch b/queue-4.14/powerpc-pseries-mobility-prevent-cpu-hotplug-during-.patch new file mode 100644 index 00000000000..8a0aa84d8fd --- /dev/null +++ b/queue-4.14/powerpc-pseries-mobility-prevent-cpu-hotplug-during-.patch @@ -0,0 +1,57 @@ +From 9a1f5235c05fb2debdfa4bb6206143ed46bdd899 Mon Sep 17 00:00:00 2001 +From: Nathan Lynch +Date: Tue, 11 Jun 2019 23:45:05 -0500 +Subject: powerpc/pseries/mobility: prevent cpu hotplug during DT update + +[ Upstream commit e59a175faa8df9d674247946f2a5a9c29c835725 ] + +CPU online/offline code paths are sensitive to parts of the device +tree (various cpu node properties, cache nodes) that can be changed as +a result of a migration. + +Prevent CPU hotplug while the device tree potentially is inconsistent. + +Fixes: 410bccf97881 ("powerpc/pseries: Partition migration in the kernel") +Signed-off-by: Nathan Lynch +Reviewed-by: Gautham R. Shenoy +Signed-off-by: Michael Ellerman +Signed-off-by: Sasha Levin +--- + arch/powerpc/platforms/pseries/mobility.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c +index fbea7db043fa..4addc552eb33 100644 +--- a/arch/powerpc/platforms/pseries/mobility.c ++++ b/arch/powerpc/platforms/pseries/mobility.c +@@ -9,6 +9,7 @@ + * 2 as published by the Free Software Foundation. + */ + ++#include + #include + #include + #include +@@ -343,11 +344,19 @@ void post_mobility_fixup(void) + if (rc) + printk(KERN_ERR "Post-mobility activate-fw failed: %d\n", rc); + ++ /* ++ * We don't want CPUs to go online/offline while the device ++ * tree is being updated. ++ */ ++ cpus_read_lock(); ++ + rc = pseries_devicetree_update(MIGRATION_SCOPE); + if (rc) + printk(KERN_ERR "Post-mobility device tree update " + "failed: %d\n", rc); + ++ cpus_read_unlock(); ++ + /* Possibly switch to a new RFI flush type */ + pseries_setup_rfi_flush(); + +-- +2.20.1 + diff --git a/queue-4.14/powerpc-xmon-fix-disabling-tracing-while-in-xmon.patch b/queue-4.14/powerpc-xmon-fix-disabling-tracing-while-in-xmon.patch new file mode 100644 index 00000000000..3d80755f723 --- /dev/null +++ b/queue-4.14/powerpc-xmon-fix-disabling-tracing-while-in-xmon.patch @@ -0,0 +1,46 @@ +From 5c61c61a4c744898c1d11684055c01e44c67562f Mon Sep 17 00:00:00 2001 +From: "Naveen N. Rao" +Date: Thu, 27 Jun 2019 15:29:40 +0530 +Subject: powerpc/xmon: Fix disabling tracing while in xmon + +[ Upstream commit aaf06665f7ea3ee9f9754e16c1a507a89f1de5b1 ] + +Commit ed49f7fd6438d ("powerpc/xmon: Disable tracing when entering +xmon") added code to disable recording trace entries while in xmon. The +commit introduced a variable 'tracing_enabled' to record if tracing was +enabled on xmon entry, and used this to conditionally enable tracing +during exit from xmon. + +However, we are not checking the value of 'fromipi' variable in +xmon_core() when setting 'tracing_enabled'. Due to this, when secondary +cpus enter xmon, they will see tracing as being disabled already and +tracing won't be re-enabled on exit. Fix the same. + +Fixes: ed49f7fd6438d ("powerpc/xmon: Disable tracing when entering xmon") +Signed-off-by: Naveen N. Rao +Signed-off-by: Michael Ellerman +Signed-off-by: Sasha Levin +--- + arch/powerpc/xmon/xmon.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c +index f752f771f29d..6b9038a3e79f 100644 +--- a/arch/powerpc/xmon/xmon.c ++++ b/arch/powerpc/xmon/xmon.c +@@ -465,8 +465,10 @@ static int xmon_core(struct pt_regs *regs, int fromipi) + local_irq_save(flags); + hard_irq_disable(); + +- tracing_enabled = tracing_is_on(); +- tracing_off(); ++ if (!fromipi) { ++ tracing_enabled = tracing_is_on(); ++ tracing_off(); ++ } + + bp = in_breakpoint_table(regs->nip, &offset); + if (bp != NULL) { +-- +2.20.1 + diff --git a/queue-4.14/rdma-i40iw-set-queue-pair-state-when-being-queried.patch b/queue-4.14/rdma-i40iw-set-queue-pair-state-when-being-queried.patch new file mode 100644 index 00000000000..826fa44db91 --- /dev/null +++ b/queue-4.14/rdma-i40iw-set-queue-pair-state-when-being-queried.patch @@ -0,0 +1,36 @@ +From 654a883303ddb09231fad398d18d4677835bbc79 Mon Sep 17 00:00:00 2001 +From: "Liu, Changcheng" +Date: Fri, 28 Jun 2019 14:16:13 +0800 +Subject: RDMA/i40iw: Set queue pair state when being queried + +[ Upstream commit 2e67e775845373905d2c2aecb9062c2c4352a535 ] + +The API for ib_query_qp requires the driver to set qp_state and +cur_qp_state on return, add the missing sets. + +Fixes: d37498417947 ("i40iw: add files for iwarp interface") +Signed-off-by: Changcheng Liu +Acked-by: Shiraz Saleem +Reviewed-by: Jason Gunthorpe +Signed-off-by: Jason Gunthorpe +Signed-off-by: Sasha Levin +--- + drivers/infiniband/hw/i40iw/i40iw_verbs.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/infiniband/hw/i40iw/i40iw_verbs.c b/drivers/infiniband/hw/i40iw/i40iw_verbs.c +index c1021b4afb41..57bfe4808247 100644 +--- a/drivers/infiniband/hw/i40iw/i40iw_verbs.c ++++ b/drivers/infiniband/hw/i40iw/i40iw_verbs.c +@@ -821,6 +821,8 @@ static int i40iw_query_qp(struct ib_qp *ibqp, + struct i40iw_qp *iwqp = to_iwqp(ibqp); + struct i40iw_sc_qp *qp = &iwqp->sc_qp; + ++ attr->qp_state = iwqp->ibqp_state; ++ attr->cur_qp_state = attr->qp_state; + attr->qp_access_flags = 0; + attr->cap.max_send_wr = qp->qp_uk.sq_size; + attr->cap.max_recv_wr = qp->qp_uk.rq_size; +-- +2.20.1 + diff --git a/queue-4.14/rdma-rxe-fill-in-wc-byte_len-with-ib_wc_recv_rdma_wi.patch b/queue-4.14/rdma-rxe-fill-in-wc-byte_len-with-ib_wc_recv_rdma_wi.patch new file mode 100644 index 00000000000..83820bcd491 --- /dev/null +++ b/queue-4.14/rdma-rxe-fill-in-wc-byte_len-with-ib_wc_recv_rdma_wi.patch @@ -0,0 +1,61 @@ +From 8831d218088e8b604abdd14c9499e389fc0159f1 Mon Sep 17 00:00:00 2001 +From: Konstantin Taranov +Date: Thu, 27 Jun 2019 16:06:43 +0200 +Subject: RDMA/rxe: Fill in wc byte_len with IB_WC_RECV_RDMA_WITH_IMM + +[ Upstream commit bdce1290493caa3f8119f24b5dacc3fb7ca27389 ] + +Calculate the correct byte_len on the receiving side when a work +completion is generated with IB_WC_RECV_RDMA_WITH_IMM opcode. + +According to the IBA byte_len must indicate the number of written bytes, +whereas it was always equal to zero for the IB_WC_RECV_RDMA_WITH_IMM +opcode, even though data was transferred. + +Fixes: 8700e3e7c485 ("Soft RoCE driver") +Signed-off-by: Konstantin Taranov +Signed-off-by: Jason Gunthorpe +Signed-off-by: Sasha Levin +--- + drivers/infiniband/sw/rxe/rxe_resp.c | 5 ++++- + drivers/infiniband/sw/rxe/rxe_verbs.h | 1 + + 2 files changed, 5 insertions(+), 1 deletion(-) + +diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c +index 74328561bee2..9207682b7a2e 100644 +--- a/drivers/infiniband/sw/rxe/rxe_resp.c ++++ b/drivers/infiniband/sw/rxe/rxe_resp.c +@@ -435,6 +435,7 @@ static enum resp_states check_rkey(struct rxe_qp *qp, + qp->resp.va = reth_va(pkt); + qp->resp.rkey = reth_rkey(pkt); + qp->resp.resid = reth_len(pkt); ++ qp->resp.length = reth_len(pkt); + } + access = (pkt->mask & RXE_READ_MASK) ? IB_ACCESS_REMOTE_READ + : IB_ACCESS_REMOTE_WRITE; +@@ -860,7 +861,9 @@ static enum resp_states do_complete(struct rxe_qp *qp, + pkt->mask & RXE_WRITE_MASK) ? + IB_WC_RECV_RDMA_WITH_IMM : IB_WC_RECV; + wc->vendor_err = 0; +- wc->byte_len = wqe->dma.length - wqe->dma.resid; ++ wc->byte_len = (pkt->mask & RXE_IMMDT_MASK && ++ pkt->mask & RXE_WRITE_MASK) ? ++ qp->resp.length : wqe->dma.length - wqe->dma.resid; + + /* fields after byte_len are different between kernel and user + * space +diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.h b/drivers/infiniband/sw/rxe/rxe_verbs.h +index 59f6a24db064..b2b76a316eba 100644 +--- a/drivers/infiniband/sw/rxe/rxe_verbs.h ++++ b/drivers/infiniband/sw/rxe/rxe_verbs.h +@@ -214,6 +214,7 @@ struct rxe_resp_info { + struct rxe_mem *mr; + u32 resid; + u32 rkey; ++ u32 length; + u64 atomic_orig; + + /* SRQ only */ +-- +2.20.1 + diff --git a/queue-4.14/recordmcount-fix-spurious-mcount-entries-on-powerpc.patch b/queue-4.14/recordmcount-fix-spurious-mcount-entries-on-powerpc.patch new file mode 100644 index 00000000000..5bd75f999de --- /dev/null +++ b/queue-4.14/recordmcount-fix-spurious-mcount-entries-on-powerpc.patch @@ -0,0 +1,94 @@ +From 6e5756d0e0fe289a29fb98927384f8281294e00c Mon Sep 17 00:00:00 2001 +From: "Naveen N. Rao" +Date: Thu, 27 Jun 2019 00:08:01 +0530 +Subject: recordmcount: Fix spurious mcount entries on powerpc + +[ Upstream commit 80e5302e4bc85a6b685b7668c36c6487b5f90e9a ] + +An impending change to enable HAVE_C_RECORDMCOUNT on powerpc leads to +warnings such as the following: + + # modprobe kprobe_example + ftrace-powerpc: Not expected bl: opcode is 3c4c0001 + WARNING: CPU: 0 PID: 227 at kernel/trace/ftrace.c:2001 ftrace_bug+0x90/0x318 + Modules linked in: + CPU: 0 PID: 227 Comm: modprobe Not tainted 5.2.0-rc6-00678-g1c329100b942 #2 + NIP: c000000000264318 LR: c00000000025d694 CTR: c000000000f5cd30 + REGS: c000000001f2b7b0 TRAP: 0700 Not tainted (5.2.0-rc6-00678-g1c329100b942) + MSR: 900000010282b033 CR: 28228222 XER: 00000000 + CFAR: c0000000002642fc IRQMASK: 0 + + NIP [c000000000264318] ftrace_bug+0x90/0x318 + LR [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0 + Call Trace: + [c000000001f2ba40] [0000000000000004] 0x4 (unreliable) + [c000000001f2bad0] [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0 + [c000000001f2bb90] [c00000000020ff10] load_module+0x25b0/0x30c0 + [c000000001f2bd00] [c000000000210cb0] sys_finit_module+0xc0/0x130 + [c000000001f2be20] [c00000000000bda4] system_call+0x5c/0x70 + Instruction dump: + 419e0018 2f83ffff 419e00bc 2f83ffea 409e00cc 4800001c 0fe00000 3c62ff96 + 39000001 39400000 386386d0 480000c4 <0fe00000> 3ce20003 39000001 3c62ff96 + ---[ end trace 4c438d5cebf78381 ]--- + ftrace failed to modify + [] 0xc0080000012a0008 + actual: 01:00:4c:3c + Initializing ftrace call sites + ftrace record flags: 2000000 + (0) + expected tramp: c00000000006af4c + +Looking at the relocation records in __mcount_loc shows a few spurious +entries: + + RELOCATION RECORDS FOR [__mcount_loc]: + OFFSET TYPE VALUE + 0000000000000000 R_PPC64_ADDR64 .text.unlikely+0x0000000000000008 + 0000000000000008 R_PPC64_ADDR64 .text.unlikely+0x0000000000000014 + 0000000000000010 R_PPC64_ADDR64 .text.unlikely+0x0000000000000060 + 0000000000000018 R_PPC64_ADDR64 .text.unlikely+0x00000000000000b4 + 0000000000000020 R_PPC64_ADDR64 .init.text+0x0000000000000008 + 0000000000000028 R_PPC64_ADDR64 .init.text+0x0000000000000014 + +The first entry in each section is incorrect. Looking at the +relocation records, the spurious entries correspond to the +R_PPC64_ENTRY records: + + RELOCATION RECORDS FOR [.text.unlikely]: + OFFSET TYPE VALUE + 0000000000000000 R_PPC64_REL64 .TOC.-0x0000000000000008 + 0000000000000008 R_PPC64_ENTRY *ABS* + 0000000000000014 R_PPC64_REL24 _mcount + + +The problem is that we are not validating the return value from +get_mcountsym() in sift_rel_mcount(). With this entry, mcountsym is 0, +but Elf_r_sym(relp) also ends up being 0. Fix this by ensuring +mcountsym is valid before processing the entry. + +Signed-off-by: Naveen N. Rao +Acked-by: Steven Rostedt (VMware) +Tested-by: Satheesh Rajendran +Signed-off-by: Michael Ellerman +Signed-off-by: Sasha Levin +--- + scripts/recordmcount.h | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h +index b9897e2be404..04151ede8043 100644 +--- a/scripts/recordmcount.h ++++ b/scripts/recordmcount.h +@@ -326,7 +326,8 @@ static uint_t *sift_rel_mcount(uint_t *mlocp, + if (!mcountsym) + mcountsym = get_mcountsym(sym0, relp, str0); + +- if (mcountsym == Elf_r_sym(relp) && !is_fake_mcount(relp)) { ++ if (mcountsym && mcountsym == Elf_r_sym(relp) && ++ !is_fake_mcount(relp)) { + uint_t const addend = + _w(_w(relp->r_offset) - recval + mcount_adjust); + mrelp->r_offset = _w(offbase +-- +2.20.1 + diff --git a/queue-4.14/serial-8250-fix-tx-interrupt-handling-condition.patch b/queue-4.14/serial-8250-fix-tx-interrupt-handling-condition.patch new file mode 100644 index 00000000000..962b2bbb9a3 --- /dev/null +++ b/queue-4.14/serial-8250-fix-tx-interrupt-handling-condition.patch @@ -0,0 +1,46 @@ +From 0bfb048337a6688a7b9b3b1452bcc6a501a55156 Mon Sep 17 00:00:00 2001 +From: Rautkoski Kimmo EXT +Date: Fri, 24 May 2019 09:19:22 +0000 +Subject: serial: 8250: Fix TX interrupt handling condition + +[ Upstream commit db1b5bc047b3cadaedab3826bba82c3d9e023c4b ] + +Interrupt handler checked THRE bit (transmitter holding register +empty) in LSR to detect if TX fifo is empty. +In case when there is only receive interrupts the TX handling +got called because THRE bit in LSR is set when there is no +transmission (FIFO empty). TX handling caused TX stop, which in +RS-485 half-duplex mode actually resets receiver FIFO. This is not +desired during reception because of possible data loss. + +The fix is to check if THRI is set in IER in addition of the TX +fifo status. THRI in IER is set when TX is started and cleared +when TX is stopped. +This ensures that TX handling is only called when there is really +transmission on going and an interrupt for THRE and not when there +are only RX interrupts. + +Signed-off-by: Kimmo Rautkoski +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/tty/serial/8250/8250_port.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c +index ab0796d14ac1..a73d2bc4b685 100644 +--- a/drivers/tty/serial/8250/8250_port.c ++++ b/drivers/tty/serial/8250/8250_port.c +@@ -1878,7 +1878,8 @@ int serial8250_handle_irq(struct uart_port *port, unsigned int iir) + status = serial8250_rx_chars(up, status); + } + serial8250_modem_status(up); +- if ((!up->dma || up->dma->tx_err) && (status & UART_LSR_THRE)) ++ if ((!up->dma || up->dma->tx_err) && (status & UART_LSR_THRE) && ++ (up->ier & UART_IER_THRI)) + serial8250_tx_chars(up); + + spin_unlock_irqrestore(&port->lock, flags); +-- +2.20.1 + diff --git a/queue-4.14/serial-mctrl_gpio-check-if-gpio-property-exisits-bef.patch b/queue-4.14/serial-mctrl_gpio-check-if-gpio-property-exisits-bef.patch new file mode 100644 index 00000000000..85f33ea6aa4 --- /dev/null +++ b/queue-4.14/serial-mctrl_gpio-check-if-gpio-property-exisits-bef.patch @@ -0,0 +1,111 @@ +From aac9cba8c1c26dd76ffb692765b4583972fcd520 Mon Sep 17 00:00:00 2001 +From: Stefan Roese +Date: Thu, 20 Jun 2019 08:24:19 +0200 +Subject: serial: mctrl_gpio: Check if GPIO property exisits before requesting + it + +[ Upstream commit d99482673f950817b30caf3fcdfb31179b050ce1 ] + +This patch adds a check for the GPIOs property existence, before the +GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio +support is added (2nd patch in this patch series) on x86 platforms using +ACPI. + +Here Mika's comments from 2016-08-09: + +" +I noticed that with v4.8-rc1 serial console of some of our Broxton +systems does not work properly anymore. I'm able to see output but input +does not work. + +I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341 +("tty/serial/8250: use mctrl_gpio helpers"). + +The reason why it fails is that in ACPI we do not have names for GPIOs +(except when _DSD is used) so we use the "idx" to index into _CRS GPIO +resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs +calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The +UART device in Broxton has following (simplified) ACPI description: + + Device (URT4) + { + ... + Name (_CRS, ResourceTemplate () { + GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, + "\\_SB.GPO0", 0x00, ResourceConsumer) + { + 0x003A + } + GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, + "\\_SB.GPO0", 0x00, ResourceConsumer) + { + 0x003D + } + }) + +In this case it finds the first GPIO (0x003A which happens to be RX pin +for that UART), turns it into GPIO which then breaks input for the UART +device. This also breaks systems with bluetooth connected to UART (those +typically have some GPIOs in their _CRS). + +Any ideas how to fix this? + +We cannot just drop the _CRS index lookup fallback because that would +break many existing machines out there so maybe we can limit this to +only DT enabled machines. Or alternatively probe if the property first +exists before trying to acquire the GPIOs (using +device_property_present()). +" + +This patch implements the fix suggested by Mika in his statement above. + +Signed-off-by: Stefan Roese +Reviewed-by: Mika Westerberg +Reviewed-by: Andy Shevchenko +Tested-by: Yegor Yefremov +Cc: Mika Westerberg +Cc: Andy Shevchenko +Cc: Yegor Yefremov +Cc: Greg Kroah-Hartman +Cc: Giulio Benetti +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/tty/serial/serial_mctrl_gpio.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +diff --git a/drivers/tty/serial/serial_mctrl_gpio.c b/drivers/tty/serial/serial_mctrl_gpio.c +index d2da6aa7f27d..42e42e3e7a6e 100644 +--- a/drivers/tty/serial/serial_mctrl_gpio.c ++++ b/drivers/tty/serial/serial_mctrl_gpio.c +@@ -21,6 +21,7 @@ + #include + #include + #include ++#include + + #include "serial_mctrl_gpio.h" + +@@ -124,6 +125,19 @@ struct mctrl_gpios *mctrl_gpio_init_noauto(struct device *dev, unsigned int idx) + + for (i = 0; i < UART_GPIO_MAX; i++) { + enum gpiod_flags flags; ++ char *gpio_str; ++ bool present; ++ ++ /* Check if GPIO property exists and continue if not */ ++ gpio_str = kasprintf(GFP_KERNEL, "%s-gpios", ++ mctrl_gpios_desc[i].name); ++ if (!gpio_str) ++ continue; ++ ++ present = device_property_present(dev, gpio_str); ++ kfree(gpio_str); ++ if (!present) ++ continue; + + if (mctrl_gpios_desc[i].dir_out) + flags = GPIOD_OUT_LOW; +-- +2.20.1 + diff --git a/queue-4.14/serial-sh-sci-fix-tx-dma-buffer-flushing-and-workque.patch b/queue-4.14/serial-sh-sci-fix-tx-dma-buffer-flushing-and-workque.patch new file mode 100644 index 00000000000..f72cf7b32bf --- /dev/null +++ b/queue-4.14/serial-sh-sci-fix-tx-dma-buffer-flushing-and-workque.patch @@ -0,0 +1,116 @@ +From 2c67137c781914f9d50f7f7ed4661876a24dd202 Mon Sep 17 00:00:00 2001 +From: Geert Uytterhoeven +Date: Mon, 24 Jun 2019 14:35:39 +0200 +Subject: serial: sh-sci: Fix TX DMA buffer flushing and workqueue races + +[ Upstream commit 8493eab02608b0e82f67b892aa72882e510c31d0 ] + +When uart_flush_buffer() is called, the .flush_buffer() callback zeroes +the tx_dma_len field. This may race with the work queue function +handling transmit DMA requests: + + 1. If the buffer is flushed before the first DMA API call, + dmaengine_prep_slave_single() may be called with a zero length, + causing the DMA request to never complete, leading to messages + like: + + rcar-dmac e7300000.dma-controller: Channel Address Error happen + + and, with debug enabled: + + sh-sci e6e88000.serial: sci_dma_tx_work_fn: ffff800639b55000: 0...0, cookie 126 + + and DMA timeouts. + + 2. If the buffer is flushed after the first DMA API call, but before + the second, dma_sync_single_for_device() may be called with a zero + length, causing the transmit data not to be flushed to RAM, and + leading to stale data being output. + +Fix this by: + 1. Letting sci_dma_tx_work_fn() return immediately if the transmit + buffer is empty, + 2. Extending the critical section to cover all DMA preparational work, + so tx_dma_len stays consistent for all of it, + 3. Using local copies of circ_buf.head and circ_buf.tail, to make sure + they match the actual operation above. + +Reported-by: Eugeniu Rosca +Suggested-by: Yoshihiro Shimoda +Signed-off-by: Geert Uytterhoeven +Reviewed-by: Eugeniu Rosca +Tested-by: Eugeniu Rosca +Link: https://lore.kernel.org/r/20190624123540.20629-2-geert+renesas@glider.be +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/tty/serial/sh-sci.c | 22 +++++++++++++++------- + 1 file changed, 15 insertions(+), 7 deletions(-) + +diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c +index dc0b36ab999a..333de7d3fe86 100644 +--- a/drivers/tty/serial/sh-sci.c ++++ b/drivers/tty/serial/sh-sci.c +@@ -1319,6 +1319,7 @@ static void work_fn_tx(struct work_struct *work) + struct uart_port *port = &s->port; + struct circ_buf *xmit = &port->state->xmit; + dma_addr_t buf; ++ int head, tail; + + /* + * DMA is idle now. +@@ -1328,16 +1329,23 @@ static void work_fn_tx(struct work_struct *work) + * consistent xmit buffer state. + */ + spin_lock_irq(&port->lock); +- buf = s->tx_dma_addr + (xmit->tail & (UART_XMIT_SIZE - 1)); ++ head = xmit->head; ++ tail = xmit->tail; ++ buf = s->tx_dma_addr + (tail & (UART_XMIT_SIZE - 1)); + s->tx_dma_len = min_t(unsigned int, +- CIRC_CNT(xmit->head, xmit->tail, UART_XMIT_SIZE), +- CIRC_CNT_TO_END(xmit->head, xmit->tail, UART_XMIT_SIZE)); +- spin_unlock_irq(&port->lock); ++ CIRC_CNT(head, tail, UART_XMIT_SIZE), ++ CIRC_CNT_TO_END(head, tail, UART_XMIT_SIZE)); ++ if (!s->tx_dma_len) { ++ /* Transmit buffer has been flushed */ ++ spin_unlock_irq(&port->lock); ++ return; ++ } + + desc = dmaengine_prep_slave_single(chan, buf, s->tx_dma_len, + DMA_MEM_TO_DEV, + DMA_PREP_INTERRUPT | DMA_CTRL_ACK); + if (!desc) { ++ spin_unlock_irq(&port->lock); + dev_warn(port->dev, "Failed preparing Tx DMA descriptor\n"); + /* switch to PIO */ + sci_tx_dma_release(s, true); +@@ -1347,20 +1355,20 @@ static void work_fn_tx(struct work_struct *work) + dma_sync_single_for_device(chan->device->dev, buf, s->tx_dma_len, + DMA_TO_DEVICE); + +- spin_lock_irq(&port->lock); + desc->callback = sci_dma_tx_complete; + desc->callback_param = s; +- spin_unlock_irq(&port->lock); + s->cookie_tx = dmaengine_submit(desc); + if (dma_submit_error(s->cookie_tx)) { ++ spin_unlock_irq(&port->lock); + dev_warn(port->dev, "Failed submitting Tx DMA descriptor\n"); + /* switch to PIO */ + sci_tx_dma_release(s, true); + return; + } + ++ spin_unlock_irq(&port->lock); + dev_dbg(port->dev, "%s: %p: %d...%d, cookie %d\n", +- __func__, xmit->buf, xmit->tail, xmit->head, s->cookie_tx); ++ __func__, xmit->buf, tail, head, s->cookie_tx); + + dma_async_issue_pending(chan); + } +-- +2.20.1 + diff --git a/queue-4.14/serial-sh-sci-terminate-tx-dma-during-buffer-flushin.patch b/queue-4.14/serial-sh-sci-terminate-tx-dma-during-buffer-flushin.patch new file mode 100644 index 00000000000..6a3b0218096 --- /dev/null +++ b/queue-4.14/serial-sh-sci-terminate-tx-dma-during-buffer-flushin.patch @@ -0,0 +1,54 @@ +From 26a03dba44bc634c5fde51252b80402198bcf4fa Mon Sep 17 00:00:00 2001 +From: Geert Uytterhoeven +Date: Mon, 24 Jun 2019 14:35:40 +0200 +Subject: serial: sh-sci: Terminate TX DMA during buffer flushing + +[ Upstream commit 775b7ffd7d6d5db320d99b0a485c51e04dfcf9f1 ] + +While the .flush_buffer() callback clears sci_port.tx_dma_len since +commit 1cf4a7efdc71cab8 ("serial: sh-sci: Fix race condition causing +garbage during shutdown"), it does not terminate a transmit DMA +operation that may be in progress. + +Fix this by terminating any pending DMA operations, and resetting the +corresponding cookie. + +Signed-off-by: Geert Uytterhoeven +Reviewed-by: Eugeniu Rosca +Tested-by: Eugeniu Rosca + +Link: https://lore.kernel.org/r/20190624123540.20629-3-geert+renesas@glider.be +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/tty/serial/sh-sci.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c +index 66c8bbea06c4..dc0b36ab999a 100644 +--- a/drivers/tty/serial/sh-sci.c ++++ b/drivers/tty/serial/sh-sci.c +@@ -1571,11 +1571,18 @@ static void sci_free_dma(struct uart_port *port) + + static void sci_flush_buffer(struct uart_port *port) + { ++ struct sci_port *s = to_sci_port(port); ++ + /* + * In uart_flush_buffer(), the xmit circular buffer has just been +- * cleared, so we have to reset tx_dma_len accordingly. ++ * cleared, so we have to reset tx_dma_len accordingly, and stop any ++ * pending transfers + */ +- to_sci_port(port)->tx_dma_len = 0; ++ s->tx_dma_len = 0; ++ if (s->chan_tx) { ++ dmaengine_terminate_async(s->chan_tx); ++ s->cookie_tx = -EINVAL; ++ } + } + #else /* !CONFIG_SERIAL_SH_SCI_DMA */ + static inline void sci_request_dma(struct uart_port *port) +-- +2.20.1 + diff --git a/queue-4.14/series b/queue-4.14/series index 239b20a9557..bc8a39694c6 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -212,3 +212,68 @@ jbd2-introduce-jbd2_inode-dirty-range-scoping.patch ext4-use-jbd2_inode-dirty-range-scoping.patch ext4-allow-directory-holes.patch mm-vmscan-scan-anonymous-pages-on-file-refaults.patch +perf-events-amd-uncore-fix-amd_uncore_llc-id-to-use-.patch +nfsv4-fix-open-create-exclusive-when-the-server-rebo.patch +nfsd-increase-drc-cache-limit.patch +nfsd-give-out-fewer-session-slots-as-limit-approache.patch +nfsd-fix-performance-limiting-session-calculation.patch +nfsd-fix-overflow-causing-non-working-mounts-on-1-tb.patch +hvsock-fix-epollout-hang-from-race-condition.patch +drm-panel-simple-fix-panel_simple_dsi_probe.patch +usb-core-hub-disable-hub-initiated-u1-u2.patch +tty-max310x-fix-invalid-baudrate-divisors-calculator.patch +pinctrl-rockchip-fix-leaked-of_node-references.patch +tty-serial-cpm_uart-fix-init-when-smc-is-relocated.patch +drm-edid-fix-a-missing-check-bug-in-drm_load_edid_fi.patch +pci-return-error-if-cannot-probe-vf.patch +drm-bridge-tc358767-read-display_props-in-get_modes.patch +drm-bridge-sii902x-pixel-clock-unit-is-10khz-instead.patch +drm-crc-debugfs-user-irqsafe-spinlock-in-drm_crtc_ad.patch +memstick-fix-error-cleanup-path-of-memstick_init.patch +tty-serial-digicolor-fix-digicolor-usart-already-reg.patch +tty-serial-msm_serial-avoid-system-lockup-condition.patch +serial-8250-fix-tx-interrupt-handling-condition.patch +drm-virtio-add-memory-barriers-for-capset-cache.patch +phy-renesas-rcar-gen2-fix-memory-leak-at-error-paths.patch +powerpc-pseries-mobility-prevent-cpu-hotplug-during-.patch +drm-rockchip-properly-adjust-to-a-true-clock-in-adju.patch +tty-serial_core-set-port-active-bit-in-uart_port_act.patch +usb-gadget-zero-ffs_io_data.patch +powerpc-pci-of-fix-of-flags-parsing-for-64bit-bars.patch +drm-msm-depopulate-platform-on-probe-failure.patch +serial-mctrl_gpio-check-if-gpio-property-exisits-bef.patch +pci-sysfs-ignore-lockdep-for-remove-attribute.patch +kbuild-add-werror-unknown-warning-option-to-clang_fl.patch +pci-xilinx-nwl-fix-multi-msi-data-programming.patch +iio-iio-utils-fix-possible-incorrect-mask-calculatio.patch +powerpc-xmon-fix-disabling-tracing-while-in-xmon.patch +recordmcount-fix-spurious-mcount-entries-on-powerpc.patch +mfd-core-set-fwnode-for-created-devices.patch +mfd-arizona-fix-undefined-behavior.patch +mfd-hi655x-pmic-fix-missing-return-value-check-for-d.patch +um-silence-lockdep-complaint-about-mmap_sem.patch +powerpc-4xx-uic-clear-pending-interrupt-after-irq-ty.patch +rdma-i40iw-set-queue-pair-state-when-being-queried.patch +serial-sh-sci-terminate-tx-dma-during-buffer-flushin.patch +serial-sh-sci-fix-tx-dma-buffer-flushing-and-workque.patch +kallsyms-exclude-kasan-local-symbols-on-s390.patch +perf-test-mmap-thread-lookup-initialize-variable-to-.patch +perf-session-fix-potential-null-pointer-dereference-.patch +perf-annotate-fix-dereferencing-freed-memory-found-b.patch +rdma-rxe-fill-in-wc-byte_len-with-ib_wc_recv_rdma_wi.patch +pci-dwc-pci-dra7xx-fix-compilation-when-config_gpiol.patch +powerpc-boot-add-get-put-_unaligned_be32-to-xz_confi.patch +f2fs-avoid-out-of-range-memory-access.patch +mailbox-handle-failed-named-mailbox-channel-request.patch +powerpc-eeh-handle-hugepages-in-ioremap-space.patch +block-bio-integrity-fix-a-memory-leak-bug.patch +sh-prevent-warnings-when-using-iounmap.patch +mm-kmemleak.c-fix-check-for-softirq-context.patch +9p-pass-the-correct-prototype-to-read_cache_page.patch +mm-gup.c-mark-undo_dev_pagemap-as-__maybe_unused.patch +mm-gup.c-remove-some-bug_ons-from-get_gate_page.patch +mm-mmu_notifier-use-hlist_add_head_rcu.patch +locking-lockdep-fix-lock-used-or-unused-stats-error.patch +locking-lockdep-hide-unused-class-variable.patch +drm-crc-only-report-a-single-overflow-when-a-crc-fd-.patch +drm-crc-debugfs-also-sprinkle-irqrestore-over-early-.patch diff --git a/queue-4.14/sh-prevent-warnings-when-using-iounmap.patch b/queue-4.14/sh-prevent-warnings-when-using-iounmap.patch new file mode 100644 index 00000000000..46e142a8019 --- /dev/null +++ b/queue-4.14/sh-prevent-warnings-when-using-iounmap.patch @@ -0,0 +1,62 @@ +From f06766b3b1d6ec7fa6b6503b0cba23dcf615d44a Mon Sep 17 00:00:00 2001 +From: Sam Ravnborg +Date: Thu, 11 Jul 2019 20:52:52 -0700 +Subject: sh: prevent warnings when using iounmap + +[ Upstream commit 733f0025f0fb43e382b84db0930ae502099b7e62 ] + +When building drm/exynos for sh, as part of an allmodconfig build, the +following warning triggered: + + exynos7_drm_decon.c: In function `decon_remove': + exynos7_drm_decon.c:769:24: warning: unused variable `ctx' + struct decon_context *ctx = dev_get_drvdata(&pdev->dev); + +The ctx variable is only used as argument to iounmap(). + +In sh - allmodconfig CONFIG_MMU is not defined +so it ended up in: + +\#define __iounmap(addr) do { } while (0) +\#define iounmap __iounmap + +Fix the warning by introducing a static inline function for iounmap. + +This is similar to several other architectures. + +Link: http://lkml.kernel.org/r/20190622114208.24427-1-sam@ravnborg.org +Signed-off-by: Sam Ravnborg +Reviewed-by: Geert Uytterhoeven +Cc: Yoshinori Sato +Cc: Rich Felker +Cc: Will Deacon +Cc: Mark Brown +Cc: Inki Dae +Cc: Krzysztof Kozlowski +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + arch/sh/include/asm/io.h | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h +index 98cb8c802b1a..0ae60d680000 100644 +--- a/arch/sh/include/asm/io.h ++++ b/arch/sh/include/asm/io.h +@@ -371,7 +371,11 @@ static inline int iounmap_fixed(void __iomem *addr) { return -EINVAL; } + + #define ioremap_nocache ioremap + #define ioremap_uc ioremap +-#define iounmap __iounmap ++ ++static inline void iounmap(void __iomem *addr) ++{ ++ __iounmap(addr); ++} + + /* + * Convert a physical pointer to a virtual kernel pointer for /dev/mem +-- +2.20.1 + diff --git a/queue-4.14/tty-max310x-fix-invalid-baudrate-divisors-calculator.patch b/queue-4.14/tty-max310x-fix-invalid-baudrate-divisors-calculator.patch new file mode 100644 index 00000000000..389ec2ecef1 --- /dev/null +++ b/queue-4.14/tty-max310x-fix-invalid-baudrate-divisors-calculator.patch @@ -0,0 +1,112 @@ +From e5693285aeeeca9cc8e8fa377d0186fc5cb86085 Mon Sep 17 00:00:00 2001 +From: Serge Semin +Date: Tue, 14 May 2019 13:14:12 +0300 +Subject: tty: max310x: Fix invalid baudrate divisors calculator + +[ Upstream commit 35240ba26a932b279a513f66fa4cabfd7af55221 ] + +Current calculator doesn't do it' job quite correct. First of all the +max310x baud-rates generator supports the divisor being less than 16. +In this case the x2/x4 modes can be used to double or quadruple +the reference frequency. But the current baud-rate setter function +just filters all these modes out by the first condition and setups +these modes only if there is a clocks-baud division remainder. The former +doesn't seem right at all, since enabling the x2/x4 modes causes the line +noise tolerance reduction and should be only used as a last resort to +enable a requested too high baud-rate. + +Finally the fraction is supposed to be calculated from D = Fref/(c*baud) +formulae, but not from D % 16, which causes the precision loss. So to speak +the current baud-rate calculator code works well only if the baud perfectly +fits to the uart reference input frequency. + +Lets fix the calculator by implementing the algo fully compliant with +the fractional baud-rate generator described in the datasheet: +D = Fref / (c*baud), where c={16,8,4} is the x1/x2/x4 rate mode +respectively, Fref - reference input frequency. The divisor fraction is +calculated from the same formulae, but making sure it is found with a +resolution of 0.0625 (four bits). + +Signed-off-by: Serge Semin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/tty/serial/max310x.c | 51 ++++++++++++++++++++++-------------- + 1 file changed, 31 insertions(+), 20 deletions(-) + +diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c +index 1a98b6631e90..0969a0d97b2b 100644 +--- a/drivers/tty/serial/max310x.c ++++ b/drivers/tty/serial/max310x.c +@@ -494,37 +494,48 @@ static bool max310x_reg_precious(struct device *dev, unsigned int reg) + + static int max310x_set_baud(struct uart_port *port, int baud) + { +- unsigned int mode = 0, clk = port->uartclk, div = clk / baud; ++ unsigned int mode = 0, div = 0, frac = 0, c = 0, F = 0; + +- /* Check for minimal value for divider */ +- if (div < 16) +- div = 16; +- +- if (clk % baud && (div / 16) < 0x8000) { ++ /* ++ * Calculate the integer divisor first. Select a proper mode ++ * in case if the requested baud is too high for the pre-defined ++ * clocks frequency. ++ */ ++ div = port->uartclk / baud; ++ if (div < 8) { ++ /* Mode x4 */ ++ c = 4; ++ mode = MAX310X_BRGCFG_4XMODE_BIT; ++ } else if (div < 16) { + /* Mode x2 */ ++ c = 8; + mode = MAX310X_BRGCFG_2XMODE_BIT; +- clk = port->uartclk * 2; +- div = clk / baud; +- +- if (clk % baud && (div / 16) < 0x8000) { +- /* Mode x4 */ +- mode = MAX310X_BRGCFG_4XMODE_BIT; +- clk = port->uartclk * 4; +- div = clk / baud; +- } ++ } else { ++ c = 16; + } + +- max310x_port_write(port, MAX310X_BRGDIVMSB_REG, (div / 16) >> 8); +- max310x_port_write(port, MAX310X_BRGDIVLSB_REG, div / 16); +- max310x_port_write(port, MAX310X_BRGCFG_REG, (div % 16) | mode); ++ /* Calculate the divisor in accordance with the fraction coefficient */ ++ div /= c; ++ F = c*baud; ++ ++ /* Calculate the baud rate fraction */ ++ if (div > 0) ++ frac = (16*(port->uartclk % F)) / F; ++ else ++ div = 1; ++ ++ max310x_port_write(port, MAX310X_BRGDIVMSB_REG, div >> 8); ++ max310x_port_write(port, MAX310X_BRGDIVLSB_REG, div); ++ max310x_port_write(port, MAX310X_BRGCFG_REG, frac | mode); + +- return DIV_ROUND_CLOSEST(clk, div); ++ /* Return the actual baud rate we just programmed */ ++ return (16*port->uartclk) / (c*(16*div + frac)); + } + + static int max310x_update_best_err(unsigned long f, long *besterr) + { + /* Use baudrate 115200 for calculate error */ +- long err = f % (115200 * 16); ++ long err = f % (460800 * 16); + + if ((*besterr < 0) || (*besterr > err)) { + *besterr = err; +-- +2.20.1 + diff --git a/queue-4.14/tty-serial-cpm_uart-fix-init-when-smc-is-relocated.patch b/queue-4.14/tty-serial-cpm_uart-fix-init-when-smc-is-relocated.patch new file mode 100644 index 00000000000..4fb7257e871 --- /dev/null +++ b/queue-4.14/tty-serial-cpm_uart-fix-init-when-smc-is-relocated.patch @@ -0,0 +1,76 @@ +From 07f5aaefe44034d0f679cdbbd8c182bcbd786d67 Mon Sep 17 00:00:00 2001 +From: Christophe Leroy +Date: Wed, 22 May 2019 12:17:11 +0000 +Subject: tty: serial: cpm_uart - fix init when SMC is relocated + +[ Upstream commit 06aaa3d066db87e8478522d910285141d44b1e58 ] + +SMC relocation can also be activated earlier by the bootloader, +so the driver's behaviour cannot rely on selected kernel config. + +When the SMC is relocated, CPM_CR_INIT_TRX cannot be used. + +But the only thing CPM_CR_INIT_TRX does is to clear the +rstate and tstate registers, so this can be done manually, +even when SMC is not relocated. + +Signed-off-by: Christophe Leroy +Fixes: 9ab921201444 ("cpm_uart: fix non-console port startup bug") +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/tty/serial/cpm_uart/cpm_uart_core.c | 17 +++++++++++------ + 1 file changed, 11 insertions(+), 6 deletions(-) + +diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c b/drivers/tty/serial/cpm_uart/cpm_uart_core.c +index 8b2b694334ec..8f5a5a16cb3b 100644 +--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c ++++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c +@@ -421,7 +421,16 @@ static int cpm_uart_startup(struct uart_port *port) + clrbits16(&pinfo->sccp->scc_sccm, UART_SCCM_RX); + } + cpm_uart_initbd(pinfo); +- cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX); ++ if (IS_SMC(pinfo)) { ++ out_be32(&pinfo->smcup->smc_rstate, 0); ++ out_be32(&pinfo->smcup->smc_tstate, 0); ++ out_be16(&pinfo->smcup->smc_rbptr, ++ in_be16(&pinfo->smcup->smc_rbase)); ++ out_be16(&pinfo->smcup->smc_tbptr, ++ in_be16(&pinfo->smcup->smc_tbase)); ++ } else { ++ cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX); ++ } + } + /* Install interrupt handler. */ + retval = request_irq(port->irq, cpm_uart_int, 0, "cpm_uart", port); +@@ -875,16 +884,14 @@ static void cpm_uart_init_smc(struct uart_cpm_port *pinfo) + (u8 __iomem *)pinfo->tx_bd_base - DPRAM_BASE); + + /* +- * In case SMC1 is being relocated... ++ * In case SMC is being relocated... + */ +-#if defined (CONFIG_I2C_SPI_SMC1_UCODE_PATCH) + out_be16(&up->smc_rbptr, in_be16(&pinfo->smcup->smc_rbase)); + out_be16(&up->smc_tbptr, in_be16(&pinfo->smcup->smc_tbase)); + out_be32(&up->smc_rstate, 0); + out_be32(&up->smc_tstate, 0); + out_be16(&up->smc_brkcr, 1); /* number of break chars */ + out_be16(&up->smc_brkec, 0); +-#endif + + /* Set up the uart parameters in the + * parameter ram. +@@ -898,8 +905,6 @@ static void cpm_uart_init_smc(struct uart_cpm_port *pinfo) + out_be16(&up->smc_brkec, 0); + out_be16(&up->smc_brkcr, 1); + +- cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX); +- + /* Set UART mode, 8 bit, no parity, one stop. + * Enable receive and transmit. + */ +-- +2.20.1 + diff --git a/queue-4.14/tty-serial-digicolor-fix-digicolor-usart-already-reg.patch b/queue-4.14/tty-serial-digicolor-fix-digicolor-usart-already-reg.patch new file mode 100644 index 00000000000..723555b3309 --- /dev/null +++ b/queue-4.14/tty-serial-digicolor-fix-digicolor-usart-already-reg.patch @@ -0,0 +1,44 @@ +From 21ae619ce45e6182d25dab69a8e3f6e2bb16ee03 Mon Sep 17 00:00:00 2001 +From: Kefeng Wang +Date: Fri, 31 May 2019 21:37:33 +0800 +Subject: tty/serial: digicolor: Fix digicolor-usart already registered warning + +[ Upstream commit c7ad9ba0611c53cfe194223db02e3bca015f0674 ] + +When modprobe/rmmod/modprobe module, if platform_driver_register() fails, +the kernel complained, + + proc_dir_entry 'driver/digicolor-usart' already registered + WARNING: CPU: 1 PID: 5636 at fs/proc/generic.c:360 proc_register+0x19d/0x270 + +Fix this by adding uart_unregister_driver() when platform_driver_register() fails. + +Reported-by: Hulk Robot +Signed-off-by: Kefeng Wang +Acked-by: Baruch Siach +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/tty/serial/digicolor-usart.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/drivers/tty/serial/digicolor-usart.c b/drivers/tty/serial/digicolor-usart.c +index 02ad6953b167..50ec5f1ac77f 100644 +--- a/drivers/tty/serial/digicolor-usart.c ++++ b/drivers/tty/serial/digicolor-usart.c +@@ -545,7 +545,11 @@ static int __init digicolor_uart_init(void) + if (ret) + return ret; + +- return platform_driver_register(&digicolor_uart_platform); ++ ret = platform_driver_register(&digicolor_uart_platform); ++ if (ret) ++ uart_unregister_driver(&digicolor_uart); ++ ++ return ret; + } + module_init(digicolor_uart_init); + +-- +2.20.1 + diff --git a/queue-4.14/tty-serial-msm_serial-avoid-system-lockup-condition.patch b/queue-4.14/tty-serial-msm_serial-avoid-system-lockup-condition.patch new file mode 100644 index 00000000000..d4c51007755 --- /dev/null +++ b/queue-4.14/tty-serial-msm_serial-avoid-system-lockup-condition.patch @@ -0,0 +1,43 @@ +From 48f6f3401d5f4146d6696247cca47a57d379c11e Mon Sep 17 00:00:00 2001 +From: Jorge Ramirez-Ortiz +Date: Mon, 10 Jun 2019 19:23:08 +0200 +Subject: tty: serial: msm_serial: avoid system lockup condition + +[ Upstream commit ba3684f99f1b25d2a30b6956d02d339d7acb9799 ] + +The function msm_wait_for_xmitr can be taken with interrupts +disabled. In order to avoid a potential system lockup - demonstrated +under stress testing conditions on SoC QCS404/5 - make sure we wait +for a bounded amount of time. + +Tested on SoC QCS404. + +Signed-off-by: Jorge Ramirez-Ortiz +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/tty/serial/msm_serial.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c +index 716aa76abdf9..0e0ccc132ab0 100644 +--- a/drivers/tty/serial/msm_serial.c ++++ b/drivers/tty/serial/msm_serial.c +@@ -391,10 +391,14 @@ static void msm_request_rx_dma(struct msm_port *msm_port, resource_size_t base) + + static inline void msm_wait_for_xmitr(struct uart_port *port) + { ++ unsigned int timeout = 500000; ++ + while (!(msm_read(port, UART_SR) & UART_SR_TX_EMPTY)) { + if (msm_read(port, UART_ISR) & UART_ISR_TX_READY) + break; + udelay(1); ++ if (!timeout--) ++ break; + } + msm_write(port, UART_CR_CMD_RESET_TX_READY, UART_CR); + } +-- +2.20.1 + diff --git a/queue-4.14/tty-serial_core-set-port-active-bit-in-uart_port_act.patch b/queue-4.14/tty-serial_core-set-port-active-bit-in-uart_port_act.patch new file mode 100644 index 00000000000..3d8c8624d5f --- /dev/null +++ b/queue-4.14/tty-serial_core-set-port-active-bit-in-uart_port_act.patch @@ -0,0 +1,71 @@ +From 089210b654c76cbd7f693d4adc8729120c933356 Mon Sep 17 00:00:00 2001 +From: Serge Semin +Date: Wed, 8 May 2019 13:44:41 +0300 +Subject: tty: serial_core: Set port active bit in uart_port_activate + +[ Upstream commit 13b18d35909707571af9539f7731389fbf0feb31 ] + +A bug was introduced by commit b3b576461864 ("tty: serial_core: convert +uart_open to use tty_port_open"). It caused a constant warning printed +into the system log regarding the tty and port counter mismatch: + +[ 21.644197] ttyS ttySx: tty_port_close_start: tty->count = 1 port count = 2 + +in case if session hangup was detected so the warning is printed starting +from the second open-close iteration. + +Particularly the problem was discovered in situation when there is a +serial tty device without hardware back-end being setup. It is considered +by the tty-serial subsystems as a hardware problem with session hang up. +In this case uart_startup() will return a positive value with TTY_IO_ERROR +flag set in corresponding tty_struct instance. The same value will get +passed to be returned from the activate() callback and then being returned +from tty_port_open(). But since in this case tty_port_block_til_ready() +isn't called the TTY_PORT_ACTIVE flag isn't set (while the method had been +called before tty_port_open conversion was introduced and the rest of the +subsystem code expected the bit being set in this case), which prevents the +uart_hangup() method to perform any cleanups including the tty port +counter setting to zero. So the next attempt to open/close the tty device +will discover the counters mismatch. + +In order to fix the problem we need to manually set the TTY_PORT_ACTIVE +flag in case if uart_startup() returned a positive value. In this case +the hang up procedure will perform a full set of cleanup actions including +the port ref-counter resetting. + +Fixes: b3b576461864 "tty: serial_core: convert uart_open to use tty_port_open" +Signed-off-by: Serge Semin +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/tty/serial/serial_core.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c +index c39246b916af..17e2311f7b00 100644 +--- a/drivers/tty/serial/serial_core.c ++++ b/drivers/tty/serial/serial_core.c +@@ -1742,6 +1742,7 @@ static int uart_port_activate(struct tty_port *port, struct tty_struct *tty) + { + struct uart_state *state = container_of(port, struct uart_state, port); + struct uart_port *uport; ++ int ret; + + uport = uart_port_check(state); + if (!uport || uport->flags & UPF_DEAD) +@@ -1752,7 +1753,11 @@ static int uart_port_activate(struct tty_port *port, struct tty_struct *tty) + /* + * Start up the serial port. + */ +- return uart_startup(tty, state, 0); ++ ret = uart_startup(tty, state, 0); ++ if (ret > 0) ++ tty_port_set_active(port, 1); ++ ++ return ret; + } + + static const char *uart_type(struct uart_port *port) +-- +2.20.1 + diff --git a/queue-4.14/um-silence-lockdep-complaint-about-mmap_sem.patch b/queue-4.14/um-silence-lockdep-complaint-about-mmap_sem.patch new file mode 100644 index 00000000000..493e5471602 --- /dev/null +++ b/queue-4.14/um-silence-lockdep-complaint-about-mmap_sem.patch @@ -0,0 +1,111 @@ +From dd3fab735ffd506fcf9c970e0e5b028171379f86 Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Fri, 24 May 2019 21:54:14 +0200 +Subject: um: Silence lockdep complaint about mmap_sem + +[ Upstream commit 80bf6ceaf9310b3f61934c69b382d4912deee049 ] + +When we get into activate_mm(), lockdep complains that we're doing +something strange: + + WARNING: possible circular locking dependency detected + 5.1.0-10252-gb00152307319-dirty #121 Not tainted + ------------------------------------------------------ + inside.sh/366 is trying to acquire lock: + (____ptrval____) (&(&p->alloc_lock)->rlock){+.+.}, at: flush_old_exec+0x703/0x8d7 + + but task is already holding lock: + (____ptrval____) (&mm->mmap_sem){++++}, at: flush_old_exec+0x6c5/0x8d7 + + which lock already depends on the new lock. + + the existing dependency chain (in reverse order) is: + + -> #1 (&mm->mmap_sem){++++}: + [...] + __lock_acquire+0x12ab/0x139f + lock_acquire+0x155/0x18e + down_write+0x3f/0x98 + flush_old_exec+0x748/0x8d7 + load_elf_binary+0x2ca/0xddb + [...] + + -> #0 (&(&p->alloc_lock)->rlock){+.+.}: + [...] + __lock_acquire+0x12ab/0x139f + lock_acquire+0x155/0x18e + _raw_spin_lock+0x30/0x83 + flush_old_exec+0x703/0x8d7 + load_elf_binary+0x2ca/0xddb + [...] + + other info that might help us debug this: + + Possible unsafe locking scenario: + + CPU0 CPU1 + ---- ---- + lock(&mm->mmap_sem); + lock(&(&p->alloc_lock)->rlock); + lock(&mm->mmap_sem); + lock(&(&p->alloc_lock)->rlock); + + *** DEADLOCK *** + + 2 locks held by inside.sh/366: + #0: (____ptrval____) (&sig->cred_guard_mutex){+.+.}, at: __do_execve_file+0x12d/0x869 + #1: (____ptrval____) (&mm->mmap_sem){++++}, at: flush_old_exec+0x6c5/0x8d7 + + stack backtrace: + CPU: 0 PID: 366 Comm: inside.sh Not tainted 5.1.0-10252-gb00152307319-dirty #121 + Stack: + [...] + Call Trace: + [<600420de>] show_stack+0x13b/0x155 + [<6048906b>] dump_stack+0x2a/0x2c + [<6009ae64>] print_circular_bug+0x332/0x343 + [<6009c5c6>] check_prev_add+0x669/0xdad + [<600a06b4>] __lock_acquire+0x12ab/0x139f + [<6009f3d0>] lock_acquire+0x155/0x18e + [<604a07e0>] _raw_spin_lock+0x30/0x83 + [<60151e6a>] flush_old_exec+0x703/0x8d7 + [<601a8eb8>] load_elf_binary+0x2ca/0xddb + [...] + +I think it's because in exec_mmap() we have + + down_read(&old_mm->mmap_sem); +... + task_lock(tsk); +... + activate_mm(active_mm, mm); + (which does down_write(&mm->mmap_sem)) + +I'm not really sure why lockdep throws in the whole knowledge +about the task lock, but it seems that old_mm and mm shouldn't +ever be the same (and it doesn't deadlock) so tell lockdep that +they're different. + +Signed-off-by: Johannes Berg +Signed-off-by: Richard Weinberger +Signed-off-by: Sasha Levin +--- + arch/um/include/asm/mmu_context.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h +index fca34b2177e2..129fb1d1f1c5 100644 +--- a/arch/um/include/asm/mmu_context.h ++++ b/arch/um/include/asm/mmu_context.h +@@ -53,7 +53,7 @@ static inline void activate_mm(struct mm_struct *old, struct mm_struct *new) + * when the new ->mm is used for the first time. + */ + __switch_mm(&new->context.id); +- down_write(&new->mmap_sem); ++ down_write_nested(&new->mmap_sem, 1); + uml_setup_stubs(new); + up_write(&new->mmap_sem); + } +-- +2.20.1 + diff --git a/queue-4.14/usb-core-hub-disable-hub-initiated-u1-u2.patch b/queue-4.14/usb-core-hub-disable-hub-initiated-u1-u2.patch new file mode 100644 index 00000000000..d73e812d61c --- /dev/null +++ b/queue-4.14/usb-core-hub-disable-hub-initiated-u1-u2.patch @@ -0,0 +1,81 @@ +From f9e688bb3548a30b27781bc4388e6fad009c7277 Mon Sep 17 00:00:00 2001 +From: Thinh Nguyen +Date: Tue, 14 May 2019 14:38:38 -0700 +Subject: usb: core: hub: Disable hub-initiated U1/U2 + +[ Upstream commit 561759292774707b71ee61aecc07724905bb7ef1 ] + +If the device rejects the control transfer to enable device-initiated +U1/U2 entry, then the device will not initiate U1/U2 transition. To +improve the performance, the downstream port should not initate +transition to U1/U2 to avoid the delay from the device link command +response (no packet can be transmitted while waiting for a response from +the device). If the device has some quirks and does not implement U1/U2, +it may reject all the link state change requests, and the downstream +port may resend and flood the bus with more requests. This will affect +the device performance even further. This patch disables the +hub-initated U1/U2 if the device-initiated U1/U2 entry fails. + +Reference: USB 3.2 spec 7.2.4.2.3 + +Signed-off-by: Thinh Nguyen +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/usb/core/hub.c | 28 ++++++++++++++++------------ + 1 file changed, 16 insertions(+), 12 deletions(-) + +diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c +index 2e1e7399596e..b543a4730ef2 100644 +--- a/drivers/usb/core/hub.c ++++ b/drivers/usb/core/hub.c +@@ -3876,6 +3876,9 @@ static int usb_set_lpm_timeout(struct usb_device *udev, + * control transfers to set the hub timeout or enable device-initiated U1/U2 + * will be successful. + * ++ * If the control transfer to enable device-initiated U1/U2 entry fails, then ++ * hub-initiated U1/U2 will be disabled. ++ * + * If we cannot set the parent hub U1/U2 timeout, we attempt to let the xHCI + * driver know about it. If that call fails, it should be harmless, and just + * take up more slightly more bus bandwidth for unnecessary U1/U2 exit latency. +@@ -3930,23 +3933,24 @@ static void usb_enable_link_state(struct usb_hcd *hcd, struct usb_device *udev, + * host know that this link state won't be enabled. + */ + hcd->driver->disable_usb3_lpm_timeout(hcd, udev, state); +- } else { +- /* Only a configured device will accept the Set Feature +- * U1/U2_ENABLE +- */ +- if (udev->actconfig) +- usb_set_device_initiated_lpm(udev, state, true); ++ return; ++ } + +- /* As soon as usb_set_lpm_timeout(timeout) returns 0, the +- * hub-initiated LPM is enabled. Thus, LPM is enabled no +- * matter the result of usb_set_device_initiated_lpm(). +- * The only difference is whether device is able to initiate +- * LPM. +- */ ++ /* Only a configured device will accept the Set Feature ++ * U1/U2_ENABLE ++ */ ++ if (udev->actconfig && ++ usb_set_device_initiated_lpm(udev, state, true) == 0) { + if (state == USB3_LPM_U1) + udev->usb3_lpm_u1_enabled = 1; + else if (state == USB3_LPM_U2) + udev->usb3_lpm_u2_enabled = 1; ++ } else { ++ /* Don't request U1/U2 entry if the device ++ * cannot transition to U1/U2. ++ */ ++ usb_set_lpm_timeout(udev, state, 0); ++ hcd->driver->disable_usb3_lpm_timeout(hcd, udev, state); + } + } + +-- +2.20.1 + diff --git a/queue-4.14/usb-gadget-zero-ffs_io_data.patch b/queue-4.14/usb-gadget-zero-ffs_io_data.patch new file mode 100644 index 00000000000..b2c9d8a873b --- /dev/null +++ b/queue-4.14/usb-gadget-zero-ffs_io_data.patch @@ -0,0 +1,57 @@ +From 3b2024f37cc994fd635c0626678319d99b7d023b Mon Sep 17 00:00:00 2001 +From: Andrzej Pietrasiewicz +Date: Mon, 3 Jun 2019 19:05:28 +0200 +Subject: usb: gadget: Zero ffs_io_data + +[ Upstream commit 508595515f4bcfe36246e4a565cf280937aeaade ] + +In some cases the "Allocate & copy" block in ffs_epfile_io() is not +executed. Consequently, in such a case ffs_alloc_buffer() is never called +and struct ffs_io_data is not initialized properly. This in turn leads to +problems when ffs_free_buffer() is called at the end of ffs_epfile_io(). + +This patch uses kzalloc() instead of kmalloc() in the aio case and memset() +in non-aio case to properly initialize struct ffs_io_data. + +Signed-off-by: Andrzej Pietrasiewicz +Signed-off-by: Felipe Balbi +Signed-off-by: Sasha Levin +--- + drivers/usb/gadget/function/f_fs.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c +index 79900c0b4f3a..cdffbe999500 100644 +--- a/drivers/usb/gadget/function/f_fs.c ++++ b/drivers/usb/gadget/function/f_fs.c +@@ -1102,11 +1102,12 @@ static ssize_t ffs_epfile_write_iter(struct kiocb *kiocb, struct iov_iter *from) + ENTER(); + + if (!is_sync_kiocb(kiocb)) { +- p = kmalloc(sizeof(io_data), GFP_KERNEL); ++ p = kzalloc(sizeof(io_data), GFP_KERNEL); + if (unlikely(!p)) + return -ENOMEM; + p->aio = true; + } else { ++ memset(p, 0, sizeof(*p)); + p->aio = false; + } + +@@ -1138,11 +1139,12 @@ static ssize_t ffs_epfile_read_iter(struct kiocb *kiocb, struct iov_iter *to) + ENTER(); + + if (!is_sync_kiocb(kiocb)) { +- p = kmalloc(sizeof(io_data), GFP_KERNEL); ++ p = kzalloc(sizeof(io_data), GFP_KERNEL); + if (unlikely(!p)) + return -ENOMEM; + p->aio = true; + } else { ++ memset(p, 0, sizeof(*p)); + p->aio = false; + } + +-- +2.20.1 +