June 2019 - Linux-stable-mirror

FAILED: patch "[PATCH] drm/amd/display: Don't load DMCU for Raven 1" failed to apply to 5.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 55143dc23ca4792868ea8c17bce65ca7b3d3e8c4 Mon Sep 17 00:00:00 2001 From: Harry Wentland <harry.wentland(a)amd.com> Date: Mon, 29 Apr 2019 09:39:15 -0400 Subject: [PATCH] drm/amd/display: Don't load DMCU for Raven 1 [WHY] Some early Raven boards had a bad SBIOS that doesn't play nicely with the DMCU FW. We thought the issues were fixed by ignoring errors on DMCU load but that doesn't seem to be the case. We've still seen reports of users unable to boot their systems at all. [HOW] Disable DMCU load on Raven 1. Only load it for Raven 2 and Picasso. Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 995f9df66142..0680c740f6fe 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -29,6 +29,7 @@ #include "dm_services_types.h" #include "dc.h" #include "dc/inc/core_types.h" +#include "dal_asic_id.h" #include "vid.h" #include "amdgpu.h" @@ -640,7 +641,7 @@ static void amdgpu_dm_fini(struct amdgpu_device *adev) static int load_dmcu_fw(struct amdgpu_device *adev) { - const char *fw_name_dmcu; + const char *fw_name_dmcu = NULL; int r; const struct dmcu_firmware_header_v1_0 *hdr; @@ -663,7 +664,14 @@ static int load_dmcu_fw(struct amdgpu_device *adev) case CHIP_VEGA20: return 0; case CHIP_RAVEN: - fw_name_dmcu = FIRMWARE_RAVEN_DMCU; + if (ASICREV_IS_PICASSO(adev->external_rev_id)) + fw_name_dmcu = FIRMWARE_RAVEN_DMCU; +#if defined(CONFIG_DRM_AMD_DC_DCN1_01) + else if (ASICREV_IS_RAVEN2(adev->external_rev_id)) + fw_name_dmcu = FIRMWARE_RAVEN_DMCU; +#endif + else + return 0; break; default: DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);

5 years, 12 months

1
0
0 0

FAILED: patch "[PATCH] drm/amd/display: Don't load DMCU for Raven 1 (v2)" failed to apply to 5.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From c08e56c647ba8e4964ffc9e43360f16c9740337e Mon Sep 17 00:00:00 2001 From: Harry Wentland <harry.wentland(a)amd.com> Date: Mon, 29 Apr 2019 09:39:15 -0400 Subject: [PATCH] drm/amd/display: Don't load DMCU for Raven 1 (v2) [WHY] Some early Raven boards had a bad SBIOS that doesn't play nicely with the DMCU FW. We thought the issues were fixed by ignoring errors on DMCU load but that doesn't seem to be the case. We've still seen reports of users unable to boot their systems at all. [HOW] Disable DMCU load on Raven 1. Only load it for Raven 2 and Picasso. v2: Fix ifdef (Alex) Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 995f9df66142..bcb1a93c0b4c 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -29,6 +29,7 @@ #include "dm_services_types.h" #include "dc.h" #include "dc/inc/core_types.h" +#include "dal_asic_id.h" #include "vid.h" #include "amdgpu.h" @@ -640,7 +641,7 @@ static void amdgpu_dm_fini(struct amdgpu_device *adev) static int load_dmcu_fw(struct amdgpu_device *adev) { - const char *fw_name_dmcu; + const char *fw_name_dmcu = NULL; int r; const struct dmcu_firmware_header_v1_0 *hdr; @@ -663,7 +664,14 @@ static int load_dmcu_fw(struct amdgpu_device *adev) case CHIP_VEGA20: return 0; case CHIP_RAVEN: - fw_name_dmcu = FIRMWARE_RAVEN_DMCU; +#if defined(CONFIG_DRM_AMD_DC_DCN1_01) + if (ASICREV_IS_PICASSO(adev->external_rev_id)) + fw_name_dmcu = FIRMWARE_RAVEN_DMCU; + else if (ASICREV_IS_RAVEN2(adev->external_rev_id)) + fw_name_dmcu = FIRMWARE_RAVEN_DMCU; + else +#endif + return 0; break; default: DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);

5 years, 12 months

1
0
0 0

FAILED: patch "[PATCH] drm/i915: Maintain consistent documentation subsection" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 551bd3368a7b3cfef01edaade8970948d178d40a Mon Sep 17 00:00:00 2001 From: Jonathan Corbet <corbet(a)lwn.net> Date: Thu, 23 May 2019 10:06:46 -0600 Subject: [PATCH] drm/i915: Maintain consistent documentation subsection ordering With Sphinx 2.0 (or prior versions with the deprecation warnings fixed) the docs build fails with: Documentation/gpu/i915.rst:403: WARNING: Title level inconsistent: Global GTT Fence Handling ~~~~~~~~~~~~~~~~~~~~~~~~~ reST markup error: Documentation/gpu/i915.rst:403: (SEVERE/4) Title level inconsistent: I "fixed" it by changing the subsections in i915.rst, but that didn't seem like the correct change. It turns out that a couple of i915 files create their own subsections in kerneldoc comments using apostrophes as the heading marker: Layout '''''' That breaks the normal subsection marker ordering, and newer Sphinx is rather more strict about enforcing that ordering. So fix the offending comments to make Sphinx happy. (This is unfortunate, in that kerneldoc comments shouldn't need to be aware of where they might be included in the heading hierarchy, but I don't see a better way around it). Cc: stable(a)vger.kernel.org # v4.14+ Acked-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Jonathan Corbet <corbet(a)lwn.net> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index b74824f0b5b1..249d35c12a75 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -35,7 +35,7 @@ * macros. Do **not** mass change existing definitions just to update the style. * * Layout - * '''''' + * ~~~~~~ * * Keep helper macros near the top. For example, _PIPE() and friends. * @@ -79,7 +79,7 @@ * style. Use lower case in hexadecimal values. * * Naming - * '''''' + * ~~~~~~ * * Try to name registers according to the specs. If the register name changes in * the specs from platform to another, stick to the original name. @@ -97,7 +97,7 @@ * suffix to the name. For example, ``_SKL`` or ``_GEN8``. * * Examples - * '''''''' + * ~~~~~~~~ * * (Note that the values in the example are indented using spaces instead of * TABs to avoid misalignment in generated documentation. Use TABs in the diff --git a/drivers/gpu/drm/i915/intel_workarounds.c b/drivers/gpu/drm/i915/intel_workarounds.c index 9682dd575152..6decd432f4d3 100644 --- a/drivers/gpu/drm/i915/intel_workarounds.c +++ b/drivers/gpu/drm/i915/intel_workarounds.c @@ -37,7 +37,7 @@ * costly and simplifies things. We can revisit this in the future. * * Layout - * '''''' + * ~~~~~~ * * Keep things in this file ordered by WA type, as per the above (context, GT, * display, register whitelist, batchbuffer). Then, inside each type, keep the

5 years, 12 months

1
0
0 0

FAILED: patch "[PATCH] drm/i915: Fix fastset vs. pfit on/off on HSW EDP transcoder" failed to apply to 5.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From da471250706e2f103a1627d1d279c9de44325993 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Thu, 25 Apr 2019 19:29:05 +0300 Subject: [PATCH] drm/i915: Fix fastset vs. pfit on/off on HSW EDP transcoder MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On HSW the pipe A panel fitter lives inside the display power well, and the input MUX for the EDP transcoder needs to be configured appropriately to route the data through the power well as needed. Changing the MUX setting is not allowed while the pipe is active, so we need to force a full modeset whenever we need to change it. Currently we may end up doing a fastset which won't change the MUX settings, but it will drop the power well reference, and that kills the pipe. Cc: stable(a)vger.kernel.org Cc: Hans de Goede <hdegoede(a)redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190425162906.5242-1-ville.s… Reviewed-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> (cherry picked from commit 13b7648b7eab7e8259a2fb267b498bd9eba81ca0) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3bd40a4a6739..5098228f1302 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12082,6 +12082,7 @@ intel_pipe_config_compare(struct drm_i915_private *dev_priv, struct intel_crtc_state *pipe_config, bool adjust) { + struct intel_crtc *crtc = to_intel_crtc(current_config->base.crtc); bool ret = true; bool fixup_inherited = adjust && (current_config->base.mode.private_flags & I915_MODE_FLAG_INHERITED) && @@ -12303,6 +12304,14 @@ intel_pipe_config_compare(struct drm_i915_private *dev_priv, PIPE_CONF_CHECK_X(gmch_pfit.pgm_ratios); PIPE_CONF_CHECK_X(gmch_pfit.lvds_border_bits); + /* + * Changing the EDP transcoder input mux + * (A_ONOFF vs. A_ON) requires a full modeset. + */ + if (IS_HASWELL(dev_priv) && crtc->pipe == PIPE_A && + current_config->cpu_transcoder == TRANSCODER_EDP) + PIPE_CONF_CHECK_BOOL(pch_pfit.enabled); + if (!adjust) { PIPE_CONF_CHECK_I(pipe_src_w); PIPE_CONF_CHECK_I(pipe_src_h); diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c b/drivers/gpu/drm/i915/intel_pipe_crc.c index e94b5b1bc1b7..e7c7be4911c1 100644 --- a/drivers/gpu/drm/i915/intel_pipe_crc.c +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c @@ -311,10 +311,17 @@ intel_crtc_crc_setup_workarounds(struct intel_crtc *crtc, bool enable) pipe_config->base.mode_changed = pipe_config->has_psr; pipe_config->crc_enabled = enable; - if (IS_HASWELL(dev_priv) && crtc->pipe == PIPE_A) { + if (IS_HASWELL(dev_priv) && + pipe_config->base.active && crtc->pipe == PIPE_A && + pipe_config->cpu_transcoder == TRANSCODER_EDP) { + bool old_need_power_well = pipe_config->pch_pfit.enabled || + pipe_config->pch_pfit.force_thru; + bool new_need_power_well = pipe_config->pch_pfit.enabled || + enable; + pipe_config->pch_pfit.force_thru = enable; - if (pipe_config->cpu_transcoder == TRANSCODER_EDP && - pipe_config->pch_pfit.enabled != enable) + + if (old_need_power_well != new_need_power_well) pipe_config->base.connectors_changed = true; }

5 years, 12 months

1
0
0 0

[PATCH AUTOSEL 4.9 01/25] iio: adc: xilinx: fix potential use-after-free on remove

by Sasha Levin

From: Sven Van Asbroeck <thesven73(a)gmail.com> [ Upstream commit 62039b6aef63380ba7a37c113bbaeee8a55c5342 ] When cancel_delayed_work() returns, the delayed work may still be running. This means that the core could potentially free the private structure (struct xadc) while the delayed work is still using it. This is a potential use-after-free. Fix by calling cancel_delayed_work_sync(), which waits for any residual work to finish before returning. Signed-off-by: Sven Van Asbroeck <TheSven73(a)gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/iio/adc/xilinx-xadc-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/xilinx-xadc-core.c b/drivers/iio/adc/xilinx-xadc-core.c index 56cf5907a5f0..143894a315d9 100644 --- a/drivers/iio/adc/xilinx-xadc-core.c +++ b/drivers/iio/adc/xilinx-xadc-core.c @@ -1299,7 +1299,7 @@ static int xadc_remove(struct platform_device *pdev) } free_irq(irq, indio_dev); clk_disable_unprepare(xadc->clk); - cancel_delayed_work(&xadc->zynq_unmask_work); + cancel_delayed_work_sync(&xadc->zynq_unmask_work); kfree(xadc->data); kfree(indio_dev->channels); -- 2.20.1

5 years, 12 months

3
26
0 0

✅ PASS: Stable queue: queue-5.1

by CKI Project

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 937cc0cc22a2 - Linux 5.1.8 The results of these automated tests are provided below. Overall result: PASSED Merge: OK Compile: OK Tests: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out the following commit: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 937cc0cc22a2 - Linux 5.1.8 We then merged the patchset with `git am`: ethtool-fix-potential-userspace-buffer-overflow.patch fix-memory-leak-in-sctp_process_init.patch ipv4-not-do-cache-for-local-delivery-if-bc_forwarding-is-enabled.patch ipv6-fix-the-check-before-getting-the-cookie-in-rt6_get_cookie.patch net-ethernet-ti-cpsw_ethtool-fix-ethtool-ring-param-set.patch net-mvpp2-use-strscpy-to-handle-stat-strings.patch net-rds-fix-memory-leak-in-rds_ib_flush_mr_pool.patch net-sfp-read-eeprom-in-maximum-16-byte-increments.patch packet-unconditionally-free-po-rollover.patch pktgen-do-not-sleep-with-the-thread-lock-held.patch revert-fib_rules-return-0-directly-if-an-exactly-same-rule-exists-when-nlm_f_excl-not-supplied.patch udp-only-choose-unbound-udp-socket-for-multicast-when-not-in-a-vrf.patch ipv6-use-read_once-for-inet-hdrincl-as-in-ipv4.patch ipv6-fix-efault-on-sendto-with-icmpv6-and-hdrincl.patch net-aquantia-fix-wol-configuration-not-applied-sometimes.patch neighbor-reset-gc_entries-counter-if-new-entry-is-released-before-insert.patch neighbor-call-__ipv4_neigh_lookup_noref-in-neigh_xmit.patch cls_matchall-avoid-panic-when-receiving-a-packet-before-filter-set.patch ipmr_base-do-not-reset-index-in-mr_table_dump.patch net-mlx4_en-ethtool-remove-unsupported-sfp-eeprom-high-pages-query.patch net-tls-replace-the-sleeping-lock-around-rx-resync-with-a-bit-lock.patch Compile testing --------------- We compiled the kernel for 4 architectures: aarch64: build options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/aarch64/kernel-stable_queue_5.1-aa… kernel build: https://artifacts.cki-project.org/builds/aarch64/kernel-stable_queue_5.1-aa… ppc64le: build options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/ppc64le/kernel-stable_queue_5.1-pp… kernel build: https://artifacts.cki-project.org/builds/ppc64le/kernel-stable_queue_5.1-pp… s390x: build options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/s390x/kernel-stable_queue_5.1-s390… kernel build: https://artifacts.cki-project.org/builds/s390x/kernel-stable_queue_5.1-s390… x86_64: build options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/x86_64/kernel-stable_queue_5.1-x86… kernel build: https://artifacts.cki-project.org/builds/x86_64/kernel-stable_queue_5.1-x86… Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: Host 1: ✅ Boot test [0] ✅ selinux-policy: serge-testsuite [1] Host 2: ✅ Boot test [0] ✅ LTP lite [2] ✅ AMTU (Abstract Machine Test Utility) [3] ✅ Ethernet drivers sanity [4] ✅ audit: audit testsuite test [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ iotop: sanity [7] ✅ tuned: tune-processes-through-perf [8] 🚧 ✅ Networking socket: fuzz [9] 🚧 ✅ Networking sctp-auth: sockopts test [10] 🚧 ✅ Networking route: pmtu [11] 🚧 ✅ Networking route_func: local [12] 🚧 ✅ Networking route_func: forward [12] 🚧 ✅ Networking UDP: socket [13] ppc64le: Host 1: ✅ Boot test [0] ✅ selinux-policy: serge-testsuite [1] Host 2: ✅ Boot test [0] ✅ LTP lite [2] ✅ AMTU (Abstract Machine Test Utility) [3] ✅ Ethernet drivers sanity [4] ✅ audit: audit testsuite test [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ iotop: sanity [7] ✅ tuned: tune-processes-through-perf [8] 🚧 ✅ Networking socket: fuzz [9] 🚧 ✅ Networking sctp-auth: sockopts test [10] 🚧 ✅ Networking route: pmtu [11] 🚧 ✅ Networking route_func: local [12] 🚧 ✅ Networking route_func: forward [12] 🚧 ✅ Networking UDP: socket [13] s390x: Host 1: ✅ Boot test [0] ✅ selinux-policy: serge-testsuite [1] Host 2: ✅ Boot test [0] ✅ LTP lite [2] ✅ Ethernet drivers sanity [4] ✅ audit: audit testsuite test [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ iotop: sanity [7] ✅ tuned: tune-processes-through-perf [8] 🚧 ✅ Networking socket: fuzz [9] 🚧 ✅ Networking sctp-auth: sockopts test [10] 🚧 ✅ Networking route: pmtu [11] 🚧 ✅ Networking route_func: local [12] 🚧 ✅ Networking route_func: forward [12] 🚧 ✅ Networking UDP: socket [13] x86_64: Host 1: ✅ Boot test [0] ✅ LTP lite [2] ✅ AMTU (Abstract Machine Test Utility) [3] ✅ Ethernet drivers sanity [4] ✅ audit: audit testsuite test [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ iotop: sanity [7] ✅ tuned: tune-processes-through-perf [8] 🚧 ✅ Networking socket: fuzz [9] 🚧 ✅ Networking sctp-auth: sockopts test [10] 🚧 ✅ Networking route: pmtu [11] 🚧 ✅ Networking route_func: local [12] 🚧 ✅ Networking route_func: forward [12] 🚧 ✅ Networking UDP: socket [13] Host 2: ✅ Boot test [0] ✅ selinux-policy: serge-testsuite [1] Test source: 💚 Pull requests are welcome for new tests or improvements to existing tests! [0]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [1]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/packages/se… [2]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [3]: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu [4]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… [5]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/aud… [6]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… [7]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/iot… [8]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/tun… [9]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… [10]: https://github.com/CKI-project/tests-beaker/archive/master.zip#networking/s… [11]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… [12]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… [13]: https://github.com/CKI-project/tests-beaker/archive/master.zip#networking/u… Waived tests (marked with 🚧) ----------------------------- This test run included waived tests. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed.

5 years, 12 months

1
0
0 0

FAILED: patch "[PATCH] nvme-tcp: fix queue mapping when queue count is limited" failed to apply to 5.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 6486199378a505c58fddc47459631235c9fb7638 Mon Sep 17 00:00:00 2001 From: Sagi Grimberg <sagi(a)grimberg.me> Date: Tue, 28 May 2019 22:49:05 -0700 Subject: [PATCH] nvme-tcp: fix queue mapping when queue count is limited When the controller supports less queues than requested, we should make sure that queue mapping does the right thing and not assume that all queues are available. This fixes a crash when the controller supports less queues than requested. The rules are: 1. if no write queues are requested, we assign the available queues to the default queue map. The default and read queue maps share the existing queues. 2. if write queues are requested: - first make sure that read queue map gets the requested nr_io_queues count - then grant the default queue map the minimum between the requested nr_write_queues and the remaining queues. If there are no available queues to dedicate to the default queue map, fallback to (1) and share all the queues in the existing queue map. Also, provide a log indication on how we constructed the different queue maps. Reported-by: Harris, James R <james.r.harris(a)intel.com> Tested-by: Jim Harris <james.r.harris(a)intel.com> Cc: <stable(a)vger.kernel.org> # v5.0+ Suggested-by: Roy Shterman <roys(a)lightbitslabs.com> Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c index 2b107a1d152b..08a2501b9357 100644 --- a/drivers/nvme/host/tcp.c +++ b/drivers/nvme/host/tcp.c @@ -111,6 +111,7 @@ struct nvme_tcp_ctrl { struct work_struct err_work; struct delayed_work connect_work; struct nvme_tcp_request async_req; + u32 io_queues[HCTX_MAX_TYPES]; }; static LIST_HEAD(nvme_tcp_ctrl_list); @@ -1564,6 +1565,35 @@ static unsigned int nvme_tcp_nr_io_queues(struct nvme_ctrl *ctrl) return nr_io_queues; } +static void nvme_tcp_set_io_queues(struct nvme_ctrl *nctrl, + unsigned int nr_io_queues) +{ + struct nvme_tcp_ctrl *ctrl = to_tcp_ctrl(nctrl); + struct nvmf_ctrl_options *opts = nctrl->opts; + + if (opts->nr_write_queues && opts->nr_io_queues < nr_io_queues) { + /* + * separate read/write queues + * hand out dedicated default queues only after we have + * sufficient read queues. + */ + ctrl->io_queues[HCTX_TYPE_READ] = opts->nr_io_queues; + nr_io_queues -= ctrl->io_queues[HCTX_TYPE_READ]; + ctrl->io_queues[HCTX_TYPE_DEFAULT] = + min(opts->nr_write_queues, nr_io_queues); + nr_io_queues -= ctrl->io_queues[HCTX_TYPE_DEFAULT]; + } else { + /* + * shared read/write queues + * either no write queues were requested, or we don't have + * sufficient queue count to have dedicated default queues. + */ + ctrl->io_queues[HCTX_TYPE_DEFAULT] = + min(opts->nr_io_queues, nr_io_queues); + nr_io_queues -= ctrl->io_queues[HCTX_TYPE_DEFAULT]; + } +} + static int nvme_tcp_alloc_io_queues(struct nvme_ctrl *ctrl) { unsigned int nr_io_queues; @@ -1581,6 +1611,8 @@ static int nvme_tcp_alloc_io_queues(struct nvme_ctrl *ctrl) dev_info(ctrl->device, "creating %d I/O queues.\n", nr_io_queues); + nvme_tcp_set_io_queues(ctrl, nr_io_queues); + return __nvme_tcp_alloc_io_queues(ctrl); } @@ -2089,23 +2121,34 @@ static blk_status_t nvme_tcp_queue_rq(struct blk_mq_hw_ctx *hctx, static int nvme_tcp_map_queues(struct blk_mq_tag_set *set) { struct nvme_tcp_ctrl *ctrl = set->driver_data; + struct nvmf_ctrl_options *opts = ctrl->ctrl.opts; - set->map[HCTX_TYPE_DEFAULT].queue_offset = 0; - set->map[HCTX_TYPE_READ].nr_queues = ctrl->ctrl.opts->nr_io_queues; - if (ctrl->ctrl.opts->nr_write_queues) { + if (opts->nr_write_queues && ctrl->io_queues[HCTX_TYPE_READ]) { /* separate read/write queues */ set->map[HCTX_TYPE_DEFAULT].nr_queues = - ctrl->ctrl.opts->nr_write_queues; + ctrl->io_queues[HCTX_TYPE_DEFAULT]; + set->map[HCTX_TYPE_DEFAULT].queue_offset = 0; + set->map[HCTX_TYPE_READ].nr_queues = + ctrl->io_queues[HCTX_TYPE_READ]; set->map[HCTX_TYPE_READ].queue_offset = - ctrl->ctrl.opts->nr_write_queues; + ctrl->io_queues[HCTX_TYPE_DEFAULT]; } else { - /* mixed read/write queues */ + /* shared read/write queues */ set->map[HCTX_TYPE_DEFAULT].nr_queues = - ctrl->ctrl.opts->nr_io_queues; + ctrl->io_queues[HCTX_TYPE_DEFAULT]; + set->map[HCTX_TYPE_DEFAULT].queue_offset = 0; + set->map[HCTX_TYPE_READ].nr_queues = + ctrl->io_queues[HCTX_TYPE_DEFAULT]; set->map[HCTX_TYPE_READ].queue_offset = 0; } blk_mq_map_queues(&set->map[HCTX_TYPE_DEFAULT]); blk_mq_map_queues(&set->map[HCTX_TYPE_READ]); + + dev_info(ctrl->ctrl.device, + "mapped %d/%d default/read queues.\n", + ctrl->io_queues[HCTX_TYPE_DEFAULT], + ctrl->io_queues[HCTX_TYPE_READ]); + return 0; }

5 years, 12 months

1
0
0 0

FAILED: patch "[PATCH] NFSv4.1: Fix bug only first CB_NOTIFY_LOCK is handled" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From ba851a39c9703f09684a541885ed176f8fb7c868 Mon Sep 17 00:00:00 2001 From: Yihao Wu <wuyihao(a)linux.alibaba.com> Date: Mon, 13 May 2019 14:58:22 +0800 Subject: [PATCH] NFSv4.1: Fix bug only first CB_NOTIFY_LOCK is handled When a waiter is waked by CB_NOTIFY_LOCK, it will retry nfs4_proc_setlk(). The waiter may fail to nfs4_proc_setlk() and sleep again. However, the waiter is already removed from clp->cl_lock_waitq when handling CB_NOTIFY_LOCK in nfs4_wake_lock_waiter(). So any subsequent CB_NOTIFY_LOCK won't wake this waiter anymore. We should put the waiter back to clp->cl_lock_waitq before retrying. Cc: stable(a)vger.kernel.org #4.9+ Signed-off-by: Yihao Wu <wuyihao(a)linux.alibaba.com> Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 5f89bbd177c6..e38f4af20950 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -6987,20 +6987,22 @@ nfs4_retry_setlk(struct nfs4_state *state, int cmd, struct file_lock *request) init_wait(&wait); wait.private = &waiter; wait.func = nfs4_wake_lock_waiter; - add_wait_queue(q, &wait); while(!signalled()) { + add_wait_queue(q, &wait); status = nfs4_proc_setlk(state, cmd, request); - if ((status != -EAGAIN) || IS_SETLK(cmd)) + if ((status != -EAGAIN) || IS_SETLK(cmd)) { + finish_wait(q, &wait); break; + } status = -ERESTARTSYS; freezer_do_not_count(); wait_woken(&wait, TASK_INTERRUPTIBLE, NFS4_LOCK_MAXTIMEOUT); freezer_count(); + finish_wait(q, &wait); } - finish_wait(q, &wait); return status; } #else /* !CONFIG_NFS_V4_1 */

5 years, 12 months

1
0
0 0

FAILED: patch "[PATCH] NFSv4.1: Fix bug only first CB_NOTIFY_LOCK is handled" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From ba851a39c9703f09684a541885ed176f8fb7c868 Mon Sep 17 00:00:00 2001 From: Yihao Wu <wuyihao(a)linux.alibaba.com> Date: Mon, 13 May 2019 14:58:22 +0800 Subject: [PATCH] NFSv4.1: Fix bug only first CB_NOTIFY_LOCK is handled When a waiter is waked by CB_NOTIFY_LOCK, it will retry nfs4_proc_setlk(). The waiter may fail to nfs4_proc_setlk() and sleep again. However, the waiter is already removed from clp->cl_lock_waitq when handling CB_NOTIFY_LOCK in nfs4_wake_lock_waiter(). So any subsequent CB_NOTIFY_LOCK won't wake this waiter anymore. We should put the waiter back to clp->cl_lock_waitq before retrying. Cc: stable(a)vger.kernel.org #4.9+ Signed-off-by: Yihao Wu <wuyihao(a)linux.alibaba.com> Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 5f89bbd177c6..e38f4af20950 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -6987,20 +6987,22 @@ nfs4_retry_setlk(struct nfs4_state *state, int cmd, struct file_lock *request) init_wait(&wait); wait.private = &waiter; wait.func = nfs4_wake_lock_waiter; - add_wait_queue(q, &wait); while(!signalled()) { + add_wait_queue(q, &wait); status = nfs4_proc_setlk(state, cmd, request); - if ((status != -EAGAIN) || IS_SETLK(cmd)) + if ((status != -EAGAIN) || IS_SETLK(cmd)) { + finish_wait(q, &wait); break; + } status = -ERESTARTSYS; freezer_do_not_count(); wait_woken(&wait, TASK_INTERRUPTIBLE, NFS4_LOCK_MAXTIMEOUT); freezer_count(); + finish_wait(q, &wait); } - finish_wait(q, &wait); return status; } #else /* !CONFIG_NFS_V4_1 */

5 years, 12 months

1
0
0 0

FAILED: patch "[PATCH] NFSv4.1: Again fix a race where CB_NOTIFY_LOCK fails to wake" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 52b042ab9948cc367b61f9ca9c18603aa7813c3a Mon Sep 17 00:00:00 2001 From: Yihao Wu <wuyihao(a)linux.alibaba.com> Date: Wed, 22 May 2019 01:57:10 +0800 Subject: [PATCH] NFSv4.1: Again fix a race where CB_NOTIFY_LOCK fails to wake a waiter Commit b7dbcc0e433f "NFSv4.1: Fix a race where CB_NOTIFY_LOCK fails to wake a waiter" found this bug. However it didn't fix it. This commit replaces schedule_timeout() with wait_woken() and default_wake_function() with woken_wake_function() in function nfs4_retry_setlk() and nfs4_wake_lock_waiter(). wait_woken() uses memory barriers in its implementation to avoid potential race condition when putting a process into sleeping state and then waking it up. Fixes: a1d617d8f134 ("nfs: allow blocking locks to be awoken by lock callbacks") Cc: stable(a)vger.kernel.org #4.9+ Signed-off-by: Yihao Wu <wuyihao(a)linux.alibaba.com> Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index c29cbef6b53f..5f89bbd177c6 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -6932,7 +6932,6 @@ struct nfs4_lock_waiter { struct task_struct *task; struct inode *inode; struct nfs_lowner *owner; - bool notified; }; static int @@ -6954,13 +6953,13 @@ nfs4_wake_lock_waiter(wait_queue_entry_t *wait, unsigned int mode, int flags, vo /* Make sure it's for the right inode */ if (nfs_compare_fh(NFS_FH(waiter->inode), &cbnl->cbnl_fh)) return 0; - - waiter->notified = true; } /* override "private" so we can use default_wake_function */ wait->private = waiter->task; - ret = autoremove_wake_function(wait, mode, flags, key); + ret = woken_wake_function(wait, mode, flags, key); + if (ret) + list_del_init(&wait->entry); wait->private = waiter; return ret; } @@ -6969,7 +6968,6 @@ static int nfs4_retry_setlk(struct nfs4_state *state, int cmd, struct file_lock *request) { int status = -ERESTARTSYS; - unsigned long flags; struct nfs4_lock_state *lsp = request->fl_u.nfs4_fl.owner; struct nfs_server *server = NFS_SERVER(state->inode); struct nfs_client *clp = server->nfs_client; @@ -6979,8 +6977,7 @@ nfs4_retry_setlk(struct nfs4_state *state, int cmd, struct file_lock *request) .s_dev = server->s_dev }; struct nfs4_lock_waiter waiter = { .task = current, .inode = state->inode, - .owner = &owner, - .notified = false }; + .owner = &owner}; wait_queue_entry_t wait; /* Don't bother with waitqueue if we don't expect a callback */ @@ -6993,21 +6990,14 @@ nfs4_retry_setlk(struct nfs4_state *state, int cmd, struct file_lock *request) add_wait_queue(q, &wait); while(!signalled()) { - waiter.notified = false; status = nfs4_proc_setlk(state, cmd, request); if ((status != -EAGAIN) || IS_SETLK(cmd)) break; status = -ERESTARTSYS; - spin_lock_irqsave(&q->lock, flags); - if (waiter.notified) { - spin_unlock_irqrestore(&q->lock, flags); - continue; - } - set_current_state(TASK_INTERRUPTIBLE); - spin_unlock_irqrestore(&q->lock, flags); - - freezable_schedule_timeout(NFS4_LOCK_MAXTIMEOUT); + freezer_do_not_count(); + wait_woken(&wait, TASK_INTERRUPTIBLE, NFS4_LOCK_MAXTIMEOUT); + freezer_count(); } finish_wait(q, &wait);

5 years, 12 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2019