From: Greg Kroah-Hartman Date: Mon, 9 Mar 2020 19:36:10 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v4.4.216~44 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=acd36a2e449dfb0aa5012cbb6143a26dedf352bd;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: dmaengine-imx-sdma-fix-context-cache.patch dmaengine-imx-sdma-fix-the-event-id-check-to-include-rx-event-for-uart6.patch media-hantro-fix-broken-media-controller-links.patch media-mc-entity.c-use-to-check-pad-flags-not.patch media-v4l2-mem2mem.c-fix-broken-links.patch media-vicodec-process-all-4-components-for-rgb32-formats.patch perf-arm-spe-fix-endless-record-after-being-terminated.patch perf-cs-etm-fix-endless-record-after-being-terminated.patch perf-intel-bts-fix-endless-record-after-being-terminated.patch perf-intel-pt-fix-endless-record-after-being-terminated.patch s390-mm-fix-panic-in-gup_fast-on-large-pud.patch s390-pci-fix-unexpected-write-combine-on-resource.patch spi-spidev-fix-cs-polarity-if-gpio-descriptors-are-used.patch vt-selection-push-sel_lock-up.patch x86-pkeys-manually-set-x86_feature_ospke-to-preserve-existing-changes.patch --- diff --git a/queue-5.4/dmaengine-imx-sdma-fix-context-cache.patch b/queue-5.4/dmaengine-imx-sdma-fix-context-cache.patch new file mode 100644 index 00000000000..61999e201c9 --- /dev/null +++ b/queue-5.4/dmaengine-imx-sdma-fix-context-cache.patch @@ -0,0 +1,65 @@ +From d288bddd8374e0a043ac9dde64a1ae6a09411d74 Mon Sep 17 00:00:00 2001 +From: Martin Fuzzey +Date: Wed, 29 Jan 2020 14:40:06 +0100 +Subject: dmaengine: imx-sdma: fix context cache + +From: Martin Fuzzey + +commit d288bddd8374e0a043ac9dde64a1ae6a09411d74 upstream. + +There is a DMA problem with the serial ports on i.MX6. + +When the following sequence is performed: + +1) Open a port +2) Write some data +3) Close the port +4) Open a *different* port +5) Write some data +6) Close the port + +The second write sends nothing and the second close hangs. +If the first close() is omitted it works. + +Adding logs to the the UART driver shows that the DMA is being setup but +the callback is never invoked for the second write. + +This used to work in 4.19. + +Git bisect leads to: + ad0d92d: "dmaengine: imx-sdma: refine to load context only once" + +This commit adds a "context_loaded" flag used to avoid unnecessary context +setups. +However the flag is only reset in sdma_channel_terminate_work(), +which is only invoked in a worker triggered by sdma_terminate_all() IF +there is an active descriptor. + +So, if no active descriptor remains when the channel is terminated, the +flag is not reset and, when the channel is later reused the old context +is used. + +Fix the problem by always resetting the flag in sdma_free_chan_resources(). + +Cc: stable@vger.kernel.org +Signed-off-by: Martin Fuzzey +Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once") +Reviewed-by: Fabio Estevam +Link: https://lore.kernel.org/r/1580305274-27274-1-git-send-email-martin.fuzzey@flowbird.group +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/dma/imx-sdma.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/dma/imx-sdma.c ++++ b/drivers/dma/imx-sdma.c +@@ -1335,6 +1335,7 @@ static void sdma_free_chan_resources(str + + sdmac->event_id0 = 0; + sdmac->event_id1 = 0; ++ sdmac->context_loaded = false; + + sdma_set_channel_priority(sdmac, 0); + diff --git a/queue-5.4/dmaengine-imx-sdma-fix-the-event-id-check-to-include-rx-event-for-uart6.patch b/queue-5.4/dmaengine-imx-sdma-fix-the-event-id-check-to-include-rx-event-for-uart6.patch new file mode 100644 index 00000000000..5c7cd6bf45e --- /dev/null +++ b/queue-5.4/dmaengine-imx-sdma-fix-the-event-id-check-to-include-rx-event-for-uart6.patch @@ -0,0 +1,45 @@ +From 25962e1a7f1d522f1b57ead2f266fab570042a70 Mon Sep 17 00:00:00 2001 +From: Frieder Schrempf +Date: Tue, 25 Feb 2020 08:23:20 +0000 +Subject: dmaengine: imx-sdma: Fix the event id check to include RX event for UART6 + +From: Frieder Schrempf + +commit 25962e1a7f1d522f1b57ead2f266fab570042a70 upstream. + +On i.MX6UL/ULL and i.MX6SX the DMA event id for the RX channel of +UART6 is '0'. To fix the broken DMA support for UART6, we change +the check for event_id0 to include '0' as a valid id. + +Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support") +Signed-off-by: Frieder Schrempf +Reviewed-by: Fabio Estevam +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200225082139.7646-1-frieder.schrempf@kontron.de +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/dma/imx-sdma.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/dma/imx-sdma.c ++++ b/drivers/dma/imx-sdma.c +@@ -1328,7 +1328,7 @@ static void sdma_free_chan_resources(str + + sdma_channel_synchronize(chan); + +- if (sdmac->event_id0) ++ if (sdmac->event_id0 >= 0) + sdma_event_disable(sdmac, sdmac->event_id0); + if (sdmac->event_id1) + sdma_event_disable(sdmac, sdmac->event_id1); +@@ -1629,7 +1629,7 @@ static int sdma_config(struct dma_chan * + memcpy(&sdmac->slave_config, dmaengine_cfg, sizeof(*dmaengine_cfg)); + + /* Set ENBLn earlier to make sure dma request triggered after that */ +- if (sdmac->event_id0) { ++ if (sdmac->event_id0 >= 0) { + if (sdmac->event_id0 >= sdmac->sdma->drvdata->num_events) + return -EINVAL; + sdma_event_enable(sdmac, sdmac->event_id0); diff --git a/queue-5.4/media-hantro-fix-broken-media-controller-links.patch b/queue-5.4/media-hantro-fix-broken-media-controller-links.patch new file mode 100644 index 00000000000..71934e6f533 --- /dev/null +++ b/queue-5.4/media-hantro-fix-broken-media-controller-links.patch @@ -0,0 +1,43 @@ +From d171c45da874e3858a83e6377e00280a507fe2f2 Mon Sep 17 00:00:00 2001 +From: Ezequiel Garcia +Date: Tue, 4 Feb 2020 20:38:37 +0100 +Subject: media: hantro: Fix broken media controller links + +From: Ezequiel Garcia + +commit d171c45da874e3858a83e6377e00280a507fe2f2 upstream. + +The driver currently creates a broken topology, +with a source-to-source link and a sink-to-sink +link instead of two source-to-sink links. + +Reported-by: Nicolas Dufresne +Cc: # for v5.3 and up +Signed-off-by: Ezequiel Garcia +Tested-by: Nicolas Dufresne +Signed-off-by: Hans Verkuil +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/staging/media/hantro/hantro_drv.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/staging/media/hantro/hantro_drv.c ++++ b/drivers/staging/media/hantro/hantro_drv.c +@@ -553,13 +553,13 @@ static int hantro_attach_func(struct han + goto err_rel_entity1; + + /* Connect the three entities */ +- ret = media_create_pad_link(&func->vdev.entity, 0, &func->proc, 1, ++ ret = media_create_pad_link(&func->vdev.entity, 0, &func->proc, 0, + MEDIA_LNK_FL_IMMUTABLE | + MEDIA_LNK_FL_ENABLED); + if (ret) + goto err_rel_entity2; + +- ret = media_create_pad_link(&func->proc, 0, &func->sink, 0, ++ ret = media_create_pad_link(&func->proc, 1, &func->sink, 0, + MEDIA_LNK_FL_IMMUTABLE | + MEDIA_LNK_FL_ENABLED); + if (ret) diff --git a/queue-5.4/media-mc-entity.c-use-to-check-pad-flags-not.patch b/queue-5.4/media-mc-entity.c-use-to-check-pad-flags-not.patch new file mode 100644 index 00000000000..38b39488b17 --- /dev/null +++ b/queue-5.4/media-mc-entity.c-use-to-check-pad-flags-not.patch @@ -0,0 +1,39 @@ +From 044041cd5227ec9ccf969f4bf1cc08bffe13b9d3 Mon Sep 17 00:00:00 2001 +From: Hans Verkuil +Date: Tue, 4 Feb 2020 19:19:22 +0100 +Subject: media: mc-entity.c: use & to check pad flags, not == + +From: Hans Verkuil + +commit 044041cd5227ec9ccf969f4bf1cc08bffe13b9d3 upstream. + +These are bits so to test if a pad is a sink you use & but not ==. + +It looks like the only reason this hasn't caused problems before is that +media_get_pad_index() is currently only used with pads that do not set the +MEDIA_PAD_FL_MUST_CONNECT flag. So a pad really had only the SINK or SOURCE +flag set and nothing else. + +Signed-off-by: Hans Verkuil +Cc: # for v5.3 and up +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/mc/mc-entity.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/media/mc/mc-entity.c ++++ b/drivers/media/mc/mc-entity.c +@@ -639,9 +639,9 @@ int media_get_pad_index(struct media_ent + return -EINVAL; + + for (i = 0; i < entity->num_pads; i++) { +- if (entity->pads[i].flags == MEDIA_PAD_FL_SINK) ++ if (entity->pads[i].flags & MEDIA_PAD_FL_SINK) + pad_is_sink = true; +- else if (entity->pads[i].flags == MEDIA_PAD_FL_SOURCE) ++ else if (entity->pads[i].flags & MEDIA_PAD_FL_SOURCE) + pad_is_sink = false; + else + continue; /* This is an error! */ diff --git a/queue-5.4/media-v4l2-mem2mem.c-fix-broken-links.patch b/queue-5.4/media-v4l2-mem2mem.c-fix-broken-links.patch new file mode 100644 index 00000000000..270d900a2dd --- /dev/null +++ b/queue-5.4/media-v4l2-mem2mem.c-fix-broken-links.patch @@ -0,0 +1,43 @@ +From 316e730f1d8bb029fe6cec2468fb2a50424485b3 Mon Sep 17 00:00:00 2001 +From: Hans Verkuil +Date: Tue, 4 Feb 2020 19:13:06 +0100 +Subject: media: v4l2-mem2mem.c: fix broken links + +From: Hans Verkuil + +commit 316e730f1d8bb029fe6cec2468fb2a50424485b3 upstream. + +The topology that v4l2_m2m_register_media_controller() creates for a +processing block actually created a source-to-source link and a sink-to-sink +link instead of two source-to-sink links. + +Unfortunately v4l2-compliance never checked for such bad links, so this +went unreported for quite some time. + +Signed-off-by: Hans Verkuil +Reported-by: Nicolas Dufresne +Cc: # for v4.19 and up +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/v4l2-core/v4l2-mem2mem.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/media/v4l2-core/v4l2-mem2mem.c ++++ b/drivers/media/v4l2-core/v4l2-mem2mem.c +@@ -809,12 +809,12 @@ int v4l2_m2m_register_media_controller(s + goto err_rel_entity1; + + /* Connect the three entities */ +- ret = media_create_pad_link(m2m_dev->source, 0, &m2m_dev->proc, 1, ++ ret = media_create_pad_link(m2m_dev->source, 0, &m2m_dev->proc, 0, + MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED); + if (ret) + goto err_rel_entity2; + +- ret = media_create_pad_link(&m2m_dev->proc, 0, &m2m_dev->sink, 0, ++ ret = media_create_pad_link(&m2m_dev->proc, 1, &m2m_dev->sink, 0, + MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED); + if (ret) + goto err_rm_links0; diff --git a/queue-5.4/media-vicodec-process-all-4-components-for-rgb32-formats.patch b/queue-5.4/media-vicodec-process-all-4-components-for-rgb32-formats.patch new file mode 100644 index 00000000000..329aa8d8134 --- /dev/null +++ b/queue-5.4/media-vicodec-process-all-4-components-for-rgb32-formats.patch @@ -0,0 +1,105 @@ +From 49a56266f96f2c6608373464af8755b431ef1513 Mon Sep 17 00:00:00 2001 +From: Hans Verkuil +Date: Tue, 4 Feb 2020 13:45:04 +0100 +Subject: media: vicodec: process all 4 components for RGB32 formats + +From: Hans Verkuil + +commit 49a56266f96f2c6608373464af8755b431ef1513 upstream. + +Only ARGB32-type pixelformat were assumed to have 4 components, which is +wrong since RGB32-type pixelformats may have an alpha channel, so they +should also assume 4 color components. + +The XRGB32-type pixelformats really have only 3 color components, but this +complicated matters since that creates strides that are sometimes width * 3 +and sometimes width * 4, and in fact this can result in buffer overflows. + +Keep things simple by just always processing all 4 color components. + +In the future we might want to optimize this again for the XRGB32-type +pixelformats, but for now keep it simple and robust. + +Signed-off-by: Hans Verkuil +Cc: # for v5.4 and up +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/platform/vicodec/codec-v4l2-fwht.c | 34 ++++++----------------- + 1 file changed, 9 insertions(+), 25 deletions(-) + +--- a/drivers/media/platform/vicodec/codec-v4l2-fwht.c ++++ b/drivers/media/platform/vicodec/codec-v4l2-fwht.c +@@ -27,17 +27,17 @@ static const struct v4l2_fwht_pixfmt_inf + { V4L2_PIX_FMT_BGR24, 3, 3, 1, 3, 3, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB}, + { V4L2_PIX_FMT_RGB24, 3, 3, 1, 3, 3, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB}, + { V4L2_PIX_FMT_HSV24, 3, 3, 1, 3, 3, 1, 1, 3, 1, FWHT_FL_PIXENC_HSV}, +- { V4L2_PIX_FMT_BGR32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB}, +- { V4L2_PIX_FMT_XBGR32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB}, ++ { V4L2_PIX_FMT_BGR32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB}, ++ { V4L2_PIX_FMT_XBGR32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB}, + { V4L2_PIX_FMT_ABGR32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB}, +- { V4L2_PIX_FMT_RGB32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB}, +- { V4L2_PIX_FMT_XRGB32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB}, ++ { V4L2_PIX_FMT_RGB32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB}, ++ { V4L2_PIX_FMT_XRGB32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB}, + { V4L2_PIX_FMT_ARGB32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB}, +- { V4L2_PIX_FMT_BGRX32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB}, ++ { V4L2_PIX_FMT_BGRX32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB}, + { V4L2_PIX_FMT_BGRA32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB}, +- { V4L2_PIX_FMT_RGBX32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB}, ++ { V4L2_PIX_FMT_RGBX32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB}, + { V4L2_PIX_FMT_RGBA32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB}, +- { V4L2_PIX_FMT_HSV32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_HSV}, ++ { V4L2_PIX_FMT_HSV32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_HSV}, + { V4L2_PIX_FMT_GREY, 1, 1, 1, 1, 0, 1, 1, 1, 1, FWHT_FL_PIXENC_RGB}, + }; + +@@ -175,22 +175,14 @@ static int prepare_raw_frame(struct fwht + case V4L2_PIX_FMT_RGB32: + case V4L2_PIX_FMT_XRGB32: + case V4L2_PIX_FMT_HSV32: +- rf->cr = rf->luma + 1; +- rf->cb = rf->cr + 2; +- rf->luma += 2; +- break; +- case V4L2_PIX_FMT_BGR32: +- case V4L2_PIX_FMT_XBGR32: +- rf->cb = rf->luma; +- rf->cr = rf->cb + 2; +- rf->luma++; +- break; + case V4L2_PIX_FMT_ARGB32: + rf->alpha = rf->luma; + rf->cr = rf->luma + 1; + rf->cb = rf->cr + 2; + rf->luma += 2; + break; ++ case V4L2_PIX_FMT_BGR32: ++ case V4L2_PIX_FMT_XBGR32: + case V4L2_PIX_FMT_ABGR32: + rf->cb = rf->luma; + rf->cr = rf->cb + 2; +@@ -198,10 +190,6 @@ static int prepare_raw_frame(struct fwht + rf->alpha = rf->cr + 1; + break; + case V4L2_PIX_FMT_BGRX32: +- rf->cb = rf->luma + 1; +- rf->cr = rf->cb + 2; +- rf->luma += 2; +- break; + case V4L2_PIX_FMT_BGRA32: + rf->alpha = rf->luma; + rf->cb = rf->luma + 1; +@@ -209,10 +197,6 @@ static int prepare_raw_frame(struct fwht + rf->luma += 2; + break; + case V4L2_PIX_FMT_RGBX32: +- rf->cr = rf->luma; +- rf->cb = rf->cr + 2; +- rf->luma++; +- break; + case V4L2_PIX_FMT_RGBA32: + rf->alpha = rf->luma + 3; + rf->cr = rf->luma; diff --git a/queue-5.4/perf-arm-spe-fix-endless-record-after-being-terminated.patch b/queue-5.4/perf-arm-spe-fix-endless-record-after-being-terminated.patch new file mode 100644 index 00000000000..700d75bb8ce --- /dev/null +++ b/queue-5.4/perf-arm-spe-fix-endless-record-after-being-terminated.patch @@ -0,0 +1,47 @@ +From d6bc34c5ec18c3544c4b0d85963768dfbcd24184 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Fri, 14 Feb 2020 15:26:53 +0200 +Subject: perf arm-spe: Fix endless record after being terminated + +From: Adrian Hunter + +commit d6bc34c5ec18c3544c4b0d85963768dfbcd24184 upstream. + +In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will +be set and the event list will be disabled by evlist__disable() once. + +While in auxtrace_record.read_finish(), the related events will be +enabled again, if they are continuous, the recording seems to be +endless. + +If the event is disabled, don't enable it again here. + +Based-on-patch-by: Wei Li +Signed-off-by: Adrian Hunter +Cc: Jiri Olsa +Cc: Tan Xiaojun +Cc: stable@vger.kernel.org # 5.4+ +Link: http://lore.kernel.org/lkml/20200214132654.20395-5-adrian.hunter@intel.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/arch/arm64/util/arm-spe.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/tools/perf/arch/arm64/util/arm-spe.c ++++ b/tools/perf/arch/arm64/util/arm-spe.c +@@ -165,9 +165,12 @@ static int arm_spe_read_finish(struct au + struct evsel *evsel; + + evlist__for_each_entry(sper->evlist, evsel) { +- if (evsel->core.attr.type == sper->arm_spe_pmu->type) ++ if (evsel->core.attr.type == sper->arm_spe_pmu->type) { ++ if (evsel->disabled) ++ return 0; + return perf_evlist__enable_event_idx(sper->evlist, + evsel, idx); ++ } + } + return -EINVAL; + } diff --git a/queue-5.4/perf-cs-etm-fix-endless-record-after-being-terminated.patch b/queue-5.4/perf-cs-etm-fix-endless-record-after-being-terminated.patch new file mode 100644 index 00000000000..0ad9d76150a --- /dev/null +++ b/queue-5.4/perf-cs-etm-fix-endless-record-after-being-terminated.patch @@ -0,0 +1,60 @@ +From c9f2833cb472cf9e0a49b7bcdc210a96017a7bfd Mon Sep 17 00:00:00 2001 +From: Wei Li +Date: Fri, 14 Feb 2020 15:26:52 +0200 +Subject: perf cs-etm: Fix endless record after being terminated + +From: Wei Li + +commit c9f2833cb472cf9e0a49b7bcdc210a96017a7bfd upstream. + +In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will +be set and the event list will be disabled by evlist__disable() once. + +While in auxtrace_record.read_finish(), the related events will be +enabled again, if they are continuous, the recording seems to be +endless. + +If the cs_etm event is disabled, we don't enable it again here. + +Note: This patch is NOT tested since i don't have such a machine with +coresight feature, but the code seems buggy same as arm-spe and +intel-pt. + +Tester notes: + +Thanks for looping, Adrian. Applied this patch and tested with +CoreSight on juno board, it works well. + +Signed-off-by: Wei Li +Reviewed-by: Leo Yan +Reviewed-by: Mathieu Poirier +Tested-by: Leo Yan +Cc: Jiri Olsa +Cc: Tan Xiaojun +Cc: stable@vger.kernel.org # 5.4+ +Link: http://lore.kernel.org/lkml/20200214132654.20395-4-adrian.hunter@intel.com +[ahunter: removed redundant 'else' after 'return'] +Signed-off-by: Adrian Hunter +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/arch/arm/util/cs-etm.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/tools/perf/arch/arm/util/cs-etm.c ++++ b/tools/perf/arch/arm/util/cs-etm.c +@@ -865,9 +865,12 @@ static int cs_etm_read_finish(struct aux + struct evsel *evsel; + + evlist__for_each_entry(ptr->evlist, evsel) { +- if (evsel->core.attr.type == ptr->cs_etm_pmu->type) ++ if (evsel->core.attr.type == ptr->cs_etm_pmu->type) { ++ if (evsel->disabled) ++ return 0; + return perf_evlist__enable_event_idx(ptr->evlist, + evsel, idx); ++ } + } + + return -EINVAL; diff --git a/queue-5.4/perf-intel-bts-fix-endless-record-after-being-terminated.patch b/queue-5.4/perf-intel-bts-fix-endless-record-after-being-terminated.patch new file mode 100644 index 00000000000..5ad7c5bc2d5 --- /dev/null +++ b/queue-5.4/perf-intel-bts-fix-endless-record-after-being-terminated.patch @@ -0,0 +1,52 @@ +From 783fed2f35e2a6771c8dc6ee29b8c4b9930783ce Mon Sep 17 00:00:00 2001 +From: Wei Li +Date: Fri, 14 Feb 2020 15:26:51 +0200 +Subject: perf intel-bts: Fix endless record after being terminated + +From: Wei Li + +commit 783fed2f35e2a6771c8dc6ee29b8c4b9930783ce upstream. + +In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will +be set and the event list will be disabled by evlist__disable() once. + +While in auxtrace_record.read_finish(), the related events will be +enabled again, if they are continuous, the recording seems to be +endless. + +If the intel_bts event is disabled, we don't enable it again here. + +Note: This patch is NOT tested since i don't have such a machine with +intel_bts feature, but the code seems buggy same as arm-spe and +intel-pt. + +Signed-off-by: Wei Li +Cc: Jiri Olsa +Cc: Tan Xiaojun +Cc: stable@vger.kernel.org # 5.4+ +Link: http://lore.kernel.org/lkml/20200214132654.20395-3-adrian.hunter@intel.com +[ahunter: removed redundant 'else' after 'return'] +Signed-off-by: Adrian Hunter +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/arch/x86/util/intel-bts.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/tools/perf/arch/x86/util/intel-bts.c ++++ b/tools/perf/arch/x86/util/intel-bts.c +@@ -415,9 +415,12 @@ static int intel_bts_read_finish(struct + struct evsel *evsel; + + evlist__for_each_entry(btsr->evlist, evsel) { +- if (evsel->core.attr.type == btsr->intel_bts_pmu->type) ++ if (evsel->core.attr.type == btsr->intel_bts_pmu->type) { ++ if (evsel->disabled) ++ return 0; + return perf_evlist__enable_event_idx(btsr->evlist, + evsel, idx); ++ } + } + return -EINVAL; + } diff --git a/queue-5.4/perf-intel-pt-fix-endless-record-after-being-terminated.patch b/queue-5.4/perf-intel-pt-fix-endless-record-after-being-terminated.patch new file mode 100644 index 00000000000..ed2676ea98c --- /dev/null +++ b/queue-5.4/perf-intel-pt-fix-endless-record-after-being-terminated.patch @@ -0,0 +1,63 @@ +From 2da4dd3d6973ffdfba4fa07f53240fda7ab22929 Mon Sep 17 00:00:00 2001 +From: Wei Li +Date: Fri, 14 Feb 2020 15:26:50 +0200 +Subject: perf intel-pt: Fix endless record after being terminated + +From: Wei Li + +commit 2da4dd3d6973ffdfba4fa07f53240fda7ab22929 upstream. + +In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will +be set and the event list will be disabled by evlist__disable() once. + +While in auxtrace_record.read_finish(), the related events will be +enabled again, if they are continuous, the recording seems to be endless. + +If the intel_pt event is disabled, we don't enable it again here. + +Before the patch: + + huawei@huawei-2288H-V5:~/linux-5.5-rc4/tools/perf$ ./perf record -e \ + intel_pt//u -p 46803 + ^C^C^C^C^C^C + +After the patch: + + huawei@huawei-2288H-V5:~/linux-5.5-rc4/tools/perf$ ./perf record -e \ + intel_pt//u -p 48591 + ^C[ perf record: Woken up 0 times to write data ] + Warning: + AUX data lost 504 times out of 4816! + + [ perf record: Captured and wrote 2024.405 MB perf.data ] + +Signed-off-by: Wei Li +Cc: Jiri Olsa +Cc: Tan Xiaojun +Cc: stable@vger.kernel.org # 5.4+ +Link: http://lore.kernel.org/lkml/20200214132654.20395-2-adrian.hunter@intel.com +[ ahunter: removed redundant 'else' after 'return' ] +Signed-off-by: Adrian Hunter +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/arch/x86/util/intel-pt.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/tools/perf/arch/x86/util/intel-pt.c ++++ b/tools/perf/arch/x86/util/intel-pt.c +@@ -1099,9 +1099,12 @@ static int intel_pt_read_finish(struct a + struct evsel *evsel; + + evlist__for_each_entry(ptr->evlist, evsel) { +- if (evsel->core.attr.type == ptr->intel_pt_pmu->type) ++ if (evsel->core.attr.type == ptr->intel_pt_pmu->type) { ++ if (evsel->disabled) ++ return 0; + return perf_evlist__enable_event_idx(ptr->evlist, evsel, + idx); ++ } + } + return -EINVAL; + } diff --git a/queue-5.4/s390-mm-fix-panic-in-gup_fast-on-large-pud.patch b/queue-5.4/s390-mm-fix-panic-in-gup_fast-on-large-pud.patch new file mode 100644 index 00000000000..cd469a53a6a --- /dev/null +++ b/queue-5.4/s390-mm-fix-panic-in-gup_fast-on-large-pud.patch @@ -0,0 +1,49 @@ +From 582b4e55403e053d8a48ff687a05174da9cc3fb0 Mon Sep 17 00:00:00 2001 +From: Gerald Schaefer +Date: Thu, 27 Feb 2020 12:56:42 +0100 +Subject: s390/mm: fix panic in gup_fast on large pud + +From: Gerald Schaefer + +commit 582b4e55403e053d8a48ff687a05174da9cc3fb0 upstream. + +On s390 there currently is no implementation of pud_write(). That was ok +as long as we had our own implementation of get_user_pages_fast() which +checked for pud protection by testing the bit directly w/o using +pud_write(). The other callers of pud_write() are not reachable on s390. + +After commit 1a42010cdc26 ("s390/mm: convert to the generic +get_user_pages_fast code") we use the generic get_user_pages_fast(), which +does call pud_write() in pud_access_permitted() for FOLL_WRITE access on +a large pud. Without an s390 specific pud_write(), the generic version is +called, which contains a BUG() statement to remind us that we don't have a +proper implementation. This results in a kernel panic. + +Fix this by providing an implementation of pud_write(). + +Cc: # 5.2+ +Fixes: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code") +Signed-off-by: Gerald Schaefer +Reviewed-by: Heiko Carstens +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/include/asm/pgtable.h | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/arch/s390/include/asm/pgtable.h ++++ b/arch/s390/include/asm/pgtable.h +@@ -756,6 +756,12 @@ static inline int pmd_write(pmd_t pmd) + return (pmd_val(pmd) & _SEGMENT_ENTRY_WRITE) != 0; + } + ++#define pud_write pud_write ++static inline int pud_write(pud_t pud) ++{ ++ return (pud_val(pud) & _REGION3_ENTRY_WRITE) != 0; ++} ++ + static inline int pmd_dirty(pmd_t pmd) + { + int dirty = 1; diff --git a/queue-5.4/s390-pci-fix-unexpected-write-combine-on-resource.patch b/queue-5.4/s390-pci-fix-unexpected-write-combine-on-resource.patch new file mode 100644 index 00000000000..36542ae8b72 --- /dev/null +++ b/queue-5.4/s390-pci-fix-unexpected-write-combine-on-resource.patch @@ -0,0 +1,50 @@ +From df057c914a9c219ac8b8ed22caf7da2f80c1fe26 Mon Sep 17 00:00:00 2001 +From: Niklas Schnelle +Date: Thu, 27 Feb 2020 12:17:18 +0100 +Subject: s390/pci: Fix unexpected write combine on resource + +From: Niklas Schnelle + +commit df057c914a9c219ac8b8ed22caf7da2f80c1fe26 upstream. + +In the initial MIO support introduced in + +commit 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions") + +zpci_map_resource() and zpci_setup_resources() default to using the +mio_wb address as the resource's start address. This means users of the +mapping, which includes most drivers, will get write combining on PCI +Stores. This may lead to problems when drivers expect write through +behavior when not using an explicit ioremap_wc(). + +Cc: stable@vger.kernel.org +Fixes: 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions") +Signed-off-by: Niklas Schnelle +Reviewed-by: Pierre Morel +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/pci/pci.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/s390/pci/pci.c ++++ b/arch/s390/pci/pci.c +@@ -423,7 +423,7 @@ static void zpci_map_resources(struct pc + + if (zpci_use_mio(zdev)) + pdev->resource[i].start = +- (resource_size_t __force) zdev->bars[i].mio_wb; ++ (resource_size_t __force) zdev->bars[i].mio_wt; + else + pdev->resource[i].start = (resource_size_t __force) + pci_iomap_range_fh(pdev, i, 0, 0); +@@ -530,7 +530,7 @@ static int zpci_setup_bus_resources(stru + flags |= IORESOURCE_MEM_64; + + if (zpci_use_mio(zdev)) +- addr = (unsigned long) zdev->bars[i].mio_wb; ++ addr = (unsigned long) zdev->bars[i].mio_wt; + else + addr = ZPCI_ADDR(entry); + size = 1UL << zdev->bars[i].size; diff --git a/queue-5.4/series b/queue-5.4/series index 74ee4890ce5..fe11ca907d1 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -86,3 +86,18 @@ tty-serial-fsl_lpuart-free-ids-allocated-by-ida.patch serial-8250_exar-add-support-for-acces-cards.patch vt-selection-close-sel_buffer-race.patch vt-selection-push-console-lock-down.patch +vt-selection-push-sel_lock-up.patch +media-hantro-fix-broken-media-controller-links.patch +media-mc-entity.c-use-to-check-pad-flags-not.patch +media-vicodec-process-all-4-components-for-rgb32-formats.patch +media-v4l2-mem2mem.c-fix-broken-links.patch +perf-intel-pt-fix-endless-record-after-being-terminated.patch +perf-intel-bts-fix-endless-record-after-being-terminated.patch +perf-cs-etm-fix-endless-record-after-being-terminated.patch +perf-arm-spe-fix-endless-record-after-being-terminated.patch +spi-spidev-fix-cs-polarity-if-gpio-descriptors-are-used.patch +x86-pkeys-manually-set-x86_feature_ospke-to-preserve-existing-changes.patch +s390-pci-fix-unexpected-write-combine-on-resource.patch +s390-mm-fix-panic-in-gup_fast-on-large-pud.patch +dmaengine-imx-sdma-fix-context-cache.patch +dmaengine-imx-sdma-fix-the-event-id-check-to-include-rx-event-for-uart6.patch diff --git a/queue-5.4/spi-spidev-fix-cs-polarity-if-gpio-descriptors-are-used.patch b/queue-5.4/spi-spidev-fix-cs-polarity-if-gpio-descriptors-are-used.patch new file mode 100644 index 00000000000..74ee9cd5a48 --- /dev/null +++ b/queue-5.4/spi-spidev-fix-cs-polarity-if-gpio-descriptors-are-used.patch @@ -0,0 +1,55 @@ +From 138c9c32f090894614899eca15e0bb7279f59865 Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Tue, 18 Feb 2020 13:08:00 +0100 +Subject: spi: spidev: Fix CS polarity if GPIO descriptors are used + +From: Lukas Wunner + +commit 138c9c32f090894614899eca15e0bb7279f59865 upstream. + +Commit f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") +amended of_spi_parse_dt() to always set SPI_CS_HIGH for SPI slaves whose +Chip Select is defined by a "cs-gpios" devicetree property. + +This change broke userspace applications which issue an SPI_IOC_WR_MODE +ioctl() to an spidev: Chip Select polarity will be incorrect unless the +application is changed to set SPI_CS_HIGH. And once changed, it will be +incompatible with kernels not containing the commit. + +Fix by setting SPI_CS_HIGH in spidev_ioctl() (under the same conditions +as in of_spi_parse_dt()). + +Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") +Reported-by: Simon Han +Signed-off-by: Lukas Wunner +Reviewed-by: Linus Walleij +Link: https://lore.kernel.org/r/fca3ba7cdc930cd36854666ceac4fbcf01b89028.1582027457.git.lukas@wunner.de +Signed-off-by: Mark Brown +Cc: stable@vger.kernel.org # v5.1+ +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/spi/spidev.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/spi/spidev.c ++++ b/drivers/spi/spidev.c +@@ -394,6 +394,7 @@ spidev_ioctl(struct file *filp, unsigned + else + retval = get_user(tmp, (u32 __user *)arg); + if (retval == 0) { ++ struct spi_controller *ctlr = spi->controller; + u32 save = spi->mode; + + if (tmp & ~SPI_MODE_MASK) { +@@ -401,6 +402,10 @@ spidev_ioctl(struct file *filp, unsigned + break; + } + ++ if (ctlr->use_gpio_descriptors && ctlr->cs_gpiods && ++ ctlr->cs_gpiods[spi->chip_select]) ++ tmp |= SPI_CS_HIGH; ++ + tmp |= spi->mode & ~SPI_MODE_MASK; + spi->mode = (u16)tmp; + retval = spi_setup(spi); diff --git a/queue-5.4/vt-selection-push-sel_lock-up.patch b/queue-5.4/vt-selection-push-sel_lock-up.patch new file mode 100644 index 00000000000..9810799fc0a --- /dev/null +++ b/queue-5.4/vt-selection-push-sel_lock-up.patch @@ -0,0 +1,145 @@ +From e8c75a30a23c6ba63f4ef6895cbf41fd42f21aa2 Mon Sep 17 00:00:00 2001 +From: Jiri Slaby +Date: Fri, 28 Feb 2020 12:54:06 +0100 +Subject: vt: selection, push sel_lock up + +From: Jiri Slaby + +commit e8c75a30a23c6ba63f4ef6895cbf41fd42f21aa2 upstream. + +sel_lock cannot nest in the console lock. Thanks to syzkaller, the +kernel states firmly: + +> WARNING: possible circular locking dependency detected +> 5.6.0-rc3-syzkaller #0 Not tainted +> ------------------------------------------------------ +> syz-executor.4/20336 is trying to acquire lock: +> ffff8880a2e952a0 (&tty->termios_rwsem){++++}, at: tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136 +> +> but task is already holding lock: +> ffffffff89462e70 (sel_lock){+.+.}, at: paste_selection+0x118/0x470 drivers/tty/vt/selection.c:374 +> +> which lock already depends on the new lock. +> +> the existing dependency chain (in reverse order) is: +> +> -> #2 (sel_lock){+.+.}: +> mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1118 +> set_selection_kernel+0x3b8/0x18a0 drivers/tty/vt/selection.c:217 +> set_selection_user+0x63/0x80 drivers/tty/vt/selection.c:181 +> tioclinux+0x103/0x530 drivers/tty/vt/vt.c:3050 +> vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364 + +This is ioctl(TIOCL_SETSEL). +Locks held on the path: console_lock -> sel_lock + +> -> #1 (console_lock){+.+.}: +> console_lock+0x46/0x70 kernel/printk/printk.c:2289 +> con_flush_chars+0x50/0x650 drivers/tty/vt/vt.c:3223 +> n_tty_write+0xeae/0x1200 drivers/tty/n_tty.c:2350 +> do_tty_write drivers/tty/tty_io.c:962 [inline] +> tty_write+0x5a1/0x950 drivers/tty/tty_io.c:1046 + +This is write(). +Locks held on the path: termios_rwsem -> console_lock + +> -> #0 (&tty->termios_rwsem){++++}: +> down_write+0x57/0x140 kernel/locking/rwsem.c:1534 +> tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136 +> mkiss_receive_buf+0x12aa/0x1340 drivers/net/hamradio/mkiss.c:902 +> tty_ldisc_receive_buf+0x12f/0x170 drivers/tty/tty_buffer.c:465 +> paste_selection+0x346/0x470 drivers/tty/vt/selection.c:389 +> tioclinux+0x121/0x530 drivers/tty/vt/vt.c:3055 +> vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364 + +This is ioctl(TIOCL_PASTESEL). +Locks held on the path: sel_lock -> termios_rwsem + +> other info that might help us debug this: +> +> Chain exists of: +> &tty->termios_rwsem --> console_lock --> sel_lock + +Clearly. From the above, we have: + console_lock -> sel_lock + sel_lock -> termios_rwsem + termios_rwsem -> console_lock + +Fix this by reversing the console_lock -> sel_lock dependency in +ioctl(TIOCL_SETSEL). First, lock sel_lock, then console_lock. + +Signed-off-by: Jiri Slaby +Reported-by: syzbot+26183d9746e62da329b8@syzkaller.appspotmail.com +Fixes: 07e6124a1a46 ("vt: selection, close sel_buffer race") +Cc: stable +Link: https://lore.kernel.org/r/20200228115406.5735-2-jslaby@suse.cz +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/vt/selection.c | 16 +++++++--------- + 1 file changed, 7 insertions(+), 9 deletions(-) + +--- a/drivers/tty/vt/selection.c ++++ b/drivers/tty/vt/selection.c +@@ -214,7 +214,6 @@ static int __set_selection_kernel(struct + if (ps > pe) /* make sel_start <= sel_end */ + swap(ps, pe); + +- mutex_lock(&sel_lock); + if (sel_cons != vc_cons[fg_console].d) { + clear_selection(); + sel_cons = vc_cons[fg_console].d; +@@ -260,10 +259,9 @@ static int __set_selection_kernel(struct + break; + case TIOCL_SELPOINTER: + highlight_pointer(pe); +- goto unlock; ++ return 0; + default: +- ret = -EINVAL; +- goto unlock; ++ return -EINVAL; + } + + /* remove the pointer */ +@@ -285,7 +283,7 @@ static int __set_selection_kernel(struct + else if (new_sel_start == sel_start) + { + if (new_sel_end == sel_end) /* no action required */ +- goto unlock; ++ return 0; + else if (new_sel_end > sel_end) /* extend to right */ + highlight(sel_end + 2, new_sel_end); + else /* contract from right */ +@@ -313,8 +311,7 @@ static int __set_selection_kernel(struct + if (!bp) { + printk(KERN_WARNING "selection: kmalloc() failed\n"); + clear_selection(); +- ret = -ENOMEM; +- goto unlock; ++ return -ENOMEM; + } + kfree(sel_buffer); + sel_buffer = bp; +@@ -339,8 +336,7 @@ static int __set_selection_kernel(struct + } + } + sel_buffer_lth = bp - sel_buffer; +-unlock: +- mutex_unlock(&sel_lock); ++ + return ret; + } + +@@ -348,9 +344,11 @@ int set_selection_kernel(struct tiocl_se + { + int ret; + ++ mutex_lock(&sel_lock); + console_lock(); + ret = __set_selection_kernel(v, tty); + console_unlock(); ++ mutex_unlock(&sel_lock); + + return ret; + } diff --git a/queue-5.4/x86-pkeys-manually-set-x86_feature_ospke-to-preserve-existing-changes.patch b/queue-5.4/x86-pkeys-manually-set-x86_feature_ospke-to-preserve-existing-changes.patch new file mode 100644 index 00000000000..d318b672667 --- /dev/null +++ b/queue-5.4/x86-pkeys-manually-set-x86_feature_ospke-to-preserve-existing-changes.patch @@ -0,0 +1,56 @@ +From 735a6dd02222d8d070c7bb748f25895239ca8c92 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 26 Feb 2020 15:16:15 -0800 +Subject: x86/pkeys: Manually set X86_FEATURE_OSPKE to preserve existing changes + +From: Sean Christopherson + +commit 735a6dd02222d8d070c7bb748f25895239ca8c92 upstream. + +Explicitly set X86_FEATURE_OSPKE via set_cpu_cap() instead of calling +get_cpu_cap() to pull the feature bit from CPUID after enabling CR4.PKE. +Invoking get_cpu_cap() effectively wipes out any {set,clear}_cpu_cap() +changes that were made between this_cpu->c_init() and setup_pku(), as +all non-synthetic feature words are reinitialized from the CPU's CPUID +values. + +Blasting away capability updates manifests most visibility when running +on a VMX capable CPU, but with VMX disabled by BIOS. To indicate that +VMX is disabled, init_ia32_feat_ctl() clears X86_FEATURE_VMX, using +clear_cpu_cap() instead of setup_clear_cpu_cap() so that KVM can report +which CPU is misconfigured (KVM needs to probe every CPU anyways). +Restoring X86_FEATURE_VMX from CPUID causes KVM to think VMX is enabled, +ultimately leading to an unexpected #GP when KVM attempts to do VMXON. + +Arguably, init_ia32_feat_ctl() should use setup_clear_cpu_cap() and let +KVM figure out a different way to report the misconfigured CPU, but VMX +is not the only feature bit that is affected, i.e. there is precedent +that tweaking feature bits via {set,clear}_cpu_cap() after ->c_init() +is expected to work. Most notably, x86_init_rdrand()'s clearing of +X86_FEATURE_RDRAND when RDRAND malfunctions is also overwritten. + +Fixes: 0697694564c8 ("x86/mm/pkeys: Actually enable Memory Protection Keys in the CPU") +Reported-by: Jacob Keller +Signed-off-by: Sean Christopherson +Signed-off-by: Borislav Petkov +Acked-by: Dave Hansen +Tested-by: Jacob Keller +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20200226231615.13664-1-sean.j.christopherson@intel.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/common.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/cpu/common.c ++++ b/arch/x86/kernel/cpu/common.c +@@ -464,7 +464,7 @@ static __always_inline void setup_pku(st + * cpuid bit to be set. We need to ensure that we + * update that bit in this CPU's "cpu_info". + */ +- get_cpu_cap(c); ++ set_cpu_cap(c, X86_FEATURE_OSPKE); + } + + #ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS