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

FAILED: patch "[PATCH] drm/i915/psr: Chase psr.enabled only under the psr.lock" 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 daeb725e919c0d2d4b628aeaa1fa053125f888b2 Mon Sep 17 00:00:00 2001 From: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Thu, 5 Apr 2018 12:49:15 +0100 Subject: [PATCH] drm/i915/psr: Chase psr.enabled only under the psr.lock Inside the psr work function, we want to wait for PSR to idle first and wish to do so without blocking the normal modeset path, so we do so without holding the PSR lock. However, we first have to find which pipe PSR was enabled on, which requires chasing into the PSR struct and requires locking to prevent intel_psr_disable() from concurrently setting our pointer to NULL. Fixes: 995d30477496 ("drm/i915: VLV/CHV PSR Software timer mode") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Durgadoss R <durgadoss.r(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: <stable(a)vger.kernel.org> # v4.0+ Reviewed-by: Jose Roberto de Souza <jose.souza(a)intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405114915.29609-1-chris@… diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 2d53f7398a6d..69a5b276f4d8 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -775,53 +775,59 @@ void intel_psr_disable(struct intel_dp *intel_dp, cancel_delayed_work_sync(&dev_priv->psr.work); } -static void intel_psr_work(struct work_struct *work) +static bool psr_wait_for_idle(struct drm_i915_private *dev_priv) { - struct drm_i915_private *dev_priv = - container_of(work, typeof(*dev_priv), psr.work.work); - struct intel_dp *intel_dp = dev_priv->psr.enabled; - struct drm_crtc *crtc = dp_to_dig_port(intel_dp)->base.base.crtc; - enum pipe pipe = to_intel_crtc(crtc)->pipe; + struct intel_dp *intel_dp; + i915_reg_t reg; + u32 mask; + int err; + + intel_dp = dev_priv->psr.enabled; + if (!intel_dp) + return false; - /* We have to make sure PSR is ready for re-enable - * otherwise it keeps disabled until next full enable/disable cycle. - * PSR might take some time to get fully disabled - * and be ready for re-enable. - */ if (HAS_DDI(dev_priv)) { if (dev_priv->psr.psr2_enabled) { - if (intel_wait_for_register(dev_priv, - EDP_PSR2_STATUS, - EDP_PSR2_STATUS_STATE_MASK, - 0, - 50)) { - DRM_ERROR("Timed out waiting for PSR2 Idle for re-enable\n"); - return; - } + reg = EDP_PSR2_STATUS; + mask = EDP_PSR2_STATUS_STATE_MASK; } else { - if (intel_wait_for_register(dev_priv, - EDP_PSR_STATUS, - EDP_PSR_STATUS_STATE_MASK, - 0, - 50)) { - DRM_ERROR("Timed out waiting for PSR Idle for re-enable\n"); - return; - } + reg = EDP_PSR_STATUS; + mask = EDP_PSR_STATUS_STATE_MASK; } } else { - if (intel_wait_for_register(dev_priv, - VLV_PSRSTAT(pipe), - VLV_EDP_PSR_IN_TRANS, - 0, - 1)) { - DRM_ERROR("Timed out waiting for PSR Idle for re-enable\n"); - return; - } + struct drm_crtc *crtc = + dp_to_dig_port(intel_dp)->base.base.crtc; + enum pipe pipe = to_intel_crtc(crtc)->pipe; + + reg = VLV_PSRSTAT(pipe); + mask = VLV_EDP_PSR_IN_TRANS; } + + mutex_unlock(&dev_priv->psr.lock); + + err = intel_wait_for_register(dev_priv, reg, mask, 0, 50); + if (err) + DRM_ERROR("Timed out waiting for PSR Idle for re-enable\n"); + + /* After the unlocked wait, verify that PSR is still wanted! */ mutex_lock(&dev_priv->psr.lock); - intel_dp = dev_priv->psr.enabled; + return err == 0 && dev_priv->psr.enabled; +} - if (!intel_dp) +static void intel_psr_work(struct work_struct *work) +{ + struct drm_i915_private *dev_priv = + container_of(work, typeof(*dev_priv), psr.work.work); + + mutex_lock(&dev_priv->psr.lock); + + /* + * We have to make sure PSR is ready for re-enable + * otherwise it keeps disabled until next full enable/disable cycle. + * PSR might take some time to get fully disabled + * and be ready for re-enable. + */ + if (!psr_wait_for_idle(dev_priv)) goto unlock; /* @@ -832,7 +838,7 @@ static void intel_psr_work(struct work_struct *work) if (dev_priv->psr.busy_frontbuffer_bits) goto unlock; - intel_psr_activate(intel_dp); + intel_psr_activate(dev_priv->psr.enabled); unlock: mutex_unlock(&dev_priv->psr.lock); }

7 years, 5 months

1
0
0 0

FAILED: patch "[PATCH] drm/i915/psr: Chase psr.enabled only under the psr.lock" 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 daeb725e919c0d2d4b628aeaa1fa053125f888b2 Mon Sep 17 00:00:00 2001 From: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Thu, 5 Apr 2018 12:49:15 +0100 Subject: [PATCH] drm/i915/psr: Chase psr.enabled only under the psr.lock Inside the psr work function, we want to wait for PSR to idle first and wish to do so without blocking the normal modeset path, so we do so without holding the PSR lock. However, we first have to find which pipe PSR was enabled on, which requires chasing into the PSR struct and requires locking to prevent intel_psr_disable() from concurrently setting our pointer to NULL. Fixes: 995d30477496 ("drm/i915: VLV/CHV PSR Software timer mode") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Durgadoss R <durgadoss.r(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: <stable(a)vger.kernel.org> # v4.0+ Reviewed-by: Jose Roberto de Souza <jose.souza(a)intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405114915.29609-1-chris@… diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 2d53f7398a6d..69a5b276f4d8 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -775,53 +775,59 @@ void intel_psr_disable(struct intel_dp *intel_dp, cancel_delayed_work_sync(&dev_priv->psr.work); } -static void intel_psr_work(struct work_struct *work) +static bool psr_wait_for_idle(struct drm_i915_private *dev_priv) { - struct drm_i915_private *dev_priv = - container_of(work, typeof(*dev_priv), psr.work.work); - struct intel_dp *intel_dp = dev_priv->psr.enabled; - struct drm_crtc *crtc = dp_to_dig_port(intel_dp)->base.base.crtc; - enum pipe pipe = to_intel_crtc(crtc)->pipe; + struct intel_dp *intel_dp; + i915_reg_t reg; + u32 mask; + int err; + + intel_dp = dev_priv->psr.enabled; + if (!intel_dp) + return false; - /* We have to make sure PSR is ready for re-enable - * otherwise it keeps disabled until next full enable/disable cycle. - * PSR might take some time to get fully disabled - * and be ready for re-enable. - */ if (HAS_DDI(dev_priv)) { if (dev_priv->psr.psr2_enabled) { - if (intel_wait_for_register(dev_priv, - EDP_PSR2_STATUS, - EDP_PSR2_STATUS_STATE_MASK, - 0, - 50)) { - DRM_ERROR("Timed out waiting for PSR2 Idle for re-enable\n"); - return; - } + reg = EDP_PSR2_STATUS; + mask = EDP_PSR2_STATUS_STATE_MASK; } else { - if (intel_wait_for_register(dev_priv, - EDP_PSR_STATUS, - EDP_PSR_STATUS_STATE_MASK, - 0, - 50)) { - DRM_ERROR("Timed out waiting for PSR Idle for re-enable\n"); - return; - } + reg = EDP_PSR_STATUS; + mask = EDP_PSR_STATUS_STATE_MASK; } } else { - if (intel_wait_for_register(dev_priv, - VLV_PSRSTAT(pipe), - VLV_EDP_PSR_IN_TRANS, - 0, - 1)) { - DRM_ERROR("Timed out waiting for PSR Idle for re-enable\n"); - return; - } + struct drm_crtc *crtc = + dp_to_dig_port(intel_dp)->base.base.crtc; + enum pipe pipe = to_intel_crtc(crtc)->pipe; + + reg = VLV_PSRSTAT(pipe); + mask = VLV_EDP_PSR_IN_TRANS; } + + mutex_unlock(&dev_priv->psr.lock); + + err = intel_wait_for_register(dev_priv, reg, mask, 0, 50); + if (err) + DRM_ERROR("Timed out waiting for PSR Idle for re-enable\n"); + + /* After the unlocked wait, verify that PSR is still wanted! */ mutex_lock(&dev_priv->psr.lock); - intel_dp = dev_priv->psr.enabled; + return err == 0 && dev_priv->psr.enabled; +} - if (!intel_dp) +static void intel_psr_work(struct work_struct *work) +{ + struct drm_i915_private *dev_priv = + container_of(work, typeof(*dev_priv), psr.work.work); + + mutex_lock(&dev_priv->psr.lock); + + /* + * We have to make sure PSR is ready for re-enable + * otherwise it keeps disabled until next full enable/disable cycle. + * PSR might take some time to get fully disabled + * and be ready for re-enable. + */ + if (!psr_wait_for_idle(dev_priv)) goto unlock; /* @@ -832,7 +838,7 @@ static void intel_psr_work(struct work_struct *work) if (dev_priv->psr.busy_frontbuffer_bits) goto unlock; - intel_psr_activate(intel_dp); + intel_psr_activate(dev_priv->psr.enabled); unlock: mutex_unlock(&dev_priv->psr.lock); }

7 years, 5 months

1
0
0 0

FAILED: patch "[PATCH] drm/i915/psr: Chase psr.enabled only under the psr.lock" failed to apply to 4.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.17-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 daeb725e919c0d2d4b628aeaa1fa053125f888b2 Mon Sep 17 00:00:00 2001 From: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Thu, 5 Apr 2018 12:49:15 +0100 Subject: [PATCH] drm/i915/psr: Chase psr.enabled only under the psr.lock Inside the psr work function, we want to wait for PSR to idle first and wish to do so without blocking the normal modeset path, so we do so without holding the PSR lock. However, we first have to find which pipe PSR was enabled on, which requires chasing into the PSR struct and requires locking to prevent intel_psr_disable() from concurrently setting our pointer to NULL. Fixes: 995d30477496 ("drm/i915: VLV/CHV PSR Software timer mode") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Durgadoss R <durgadoss.r(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: <stable(a)vger.kernel.org> # v4.0+ Reviewed-by: Jose Roberto de Souza <jose.souza(a)intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405114915.29609-1-chris@… diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 2d53f7398a6d..69a5b276f4d8 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -775,53 +775,59 @@ void intel_psr_disable(struct intel_dp *intel_dp, cancel_delayed_work_sync(&dev_priv->psr.work); } -static void intel_psr_work(struct work_struct *work) +static bool psr_wait_for_idle(struct drm_i915_private *dev_priv) { - struct drm_i915_private *dev_priv = - container_of(work, typeof(*dev_priv), psr.work.work); - struct intel_dp *intel_dp = dev_priv->psr.enabled; - struct drm_crtc *crtc = dp_to_dig_port(intel_dp)->base.base.crtc; - enum pipe pipe = to_intel_crtc(crtc)->pipe; + struct intel_dp *intel_dp; + i915_reg_t reg; + u32 mask; + int err; + + intel_dp = dev_priv->psr.enabled; + if (!intel_dp) + return false; - /* We have to make sure PSR is ready for re-enable - * otherwise it keeps disabled until next full enable/disable cycle. - * PSR might take some time to get fully disabled - * and be ready for re-enable. - */ if (HAS_DDI(dev_priv)) { if (dev_priv->psr.psr2_enabled) { - if (intel_wait_for_register(dev_priv, - EDP_PSR2_STATUS, - EDP_PSR2_STATUS_STATE_MASK, - 0, - 50)) { - DRM_ERROR("Timed out waiting for PSR2 Idle for re-enable\n"); - return; - } + reg = EDP_PSR2_STATUS; + mask = EDP_PSR2_STATUS_STATE_MASK; } else { - if (intel_wait_for_register(dev_priv, - EDP_PSR_STATUS, - EDP_PSR_STATUS_STATE_MASK, - 0, - 50)) { - DRM_ERROR("Timed out waiting for PSR Idle for re-enable\n"); - return; - } + reg = EDP_PSR_STATUS; + mask = EDP_PSR_STATUS_STATE_MASK; } } else { - if (intel_wait_for_register(dev_priv, - VLV_PSRSTAT(pipe), - VLV_EDP_PSR_IN_TRANS, - 0, - 1)) { - DRM_ERROR("Timed out waiting for PSR Idle for re-enable\n"); - return; - } + struct drm_crtc *crtc = + dp_to_dig_port(intel_dp)->base.base.crtc; + enum pipe pipe = to_intel_crtc(crtc)->pipe; + + reg = VLV_PSRSTAT(pipe); + mask = VLV_EDP_PSR_IN_TRANS; } + + mutex_unlock(&dev_priv->psr.lock); + + err = intel_wait_for_register(dev_priv, reg, mask, 0, 50); + if (err) + DRM_ERROR("Timed out waiting for PSR Idle for re-enable\n"); + + /* After the unlocked wait, verify that PSR is still wanted! */ mutex_lock(&dev_priv->psr.lock); - intel_dp = dev_priv->psr.enabled; + return err == 0 && dev_priv->psr.enabled; +} - if (!intel_dp) +static void intel_psr_work(struct work_struct *work) +{ + struct drm_i915_private *dev_priv = + container_of(work, typeof(*dev_priv), psr.work.work); + + mutex_lock(&dev_priv->psr.lock); + + /* + * We have to make sure PSR is ready for re-enable + * otherwise it keeps disabled until next full enable/disable cycle. + * PSR might take some time to get fully disabled + * and be ready for re-enable. + */ + if (!psr_wait_for_idle(dev_priv)) goto unlock; /* @@ -832,7 +838,7 @@ static void intel_psr_work(struct work_struct *work) if (dev_priv->psr.busy_frontbuffer_bits) goto unlock; - intel_psr_activate(intel_dp); + intel_psr_activate(dev_priv->psr.enabled); unlock: mutex_unlock(&dev_priv->psr.lock); }

7 years, 5 months

1
0
0 0

FAILED: patch "[PATCH] Revert "drm/amd/display: fix dereferencing possible" failed to apply to 4.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.17-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 642ad57058baaa2c105925a75c153bb486877513 Mon Sep 17 00:00:00 2001 From: Harry Wentland <harry.wentland(a)amd.com> Date: Thu, 12 Apr 2018 10:51:51 -0400 Subject: [PATCH] Revert "drm/amd/display: fix dereferencing possible ERR_PTR()" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This reverts commit cd2d6c92a8e39d7e50a5af9fcc67d07e6a89e91d. Cc: Shirish S <shirish.s(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com> Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> 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 265f0166f688..0c29f3b97398 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4941,9 +4941,6 @@ static int dm_atomic_check_plane_state_fb(struct drm_atomic_state *state, return -EDEADLK; crtc_state = drm_atomic_get_crtc_state(plane_state->state, crtc); - if (IS_ERR(crtc_state)) - return PTR_ERR(crtc_state); - if (crtc->primary == plane && crtc_state->active) { if (!plane_state->fb) return -EINVAL;

7 years, 5 months

1
0
0 0

4.17.2 -> 4.17.3 iwlwifi regression

by Yan, Zheng

I started to get following warning and unstable connection after upgrading kernel to 4.17.3 (from 4.17.2). iwlwifi 0000:04:00.0: loaded firmware version 38.c0e03d94.0 op_mode iwlmvm iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 9260, REV=0x324 audit: type=1130 audit(1529640588.009:69): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' iwlwifi 0000:04:00.0: base HW address: 74:e5:f9:a6:bb:52 … WARNING: CPU: 1 PID: 0 at drivers/net/wireless/intel/iwlwifi/mvm/tx.c:710 iwl_mvm_tx_tso_segment+0x28a/0x2a0 [iwlmvm] Modules linked in: joydev(E) xt_nat(E) it87(OE) netconsole(E) rmd160(E) ip_vti(E) ip_tunnel(E) af_key(E) ah6(E) ah4(E) esp6(E) esp4(E) xfrm4_mode_beet(E) xfrm4_tunnel(E) tunnel4(E) xfrm4_mode_tunnel(E) xfrm4_mode_transport(E) xfrm6_mode_transport(E) xfrm6_mode_ro(E) xfrm6_mode_beet(E) xfrm6_mode_tunnel(E) ipcomp(E) ipcomp6(E) xfrm6_tunnel(E) xfrm_ipcomp(E) tunnel6(E) sha1_ssse3(E) salsa20_x86_64(E) salsa20_generic(E) poly1305_x86_64(E) poly1305_generic(E) des3_ede_x86_64(E) chacha20_x86_64(E) chacha20_generic(E) chacha20poly1305(E) camellia_generic(E) camellia_aesni_avx2(E) camellia_aesni_avx_x86_64(E) camellia_x86_64(E) cast6_avx_x86_64(E) cast6_generic(E) cast5_avx_x86_64(E) cast5_generic(E) cast_common(E) serpent_avx2(E) serpent_avx_x86_64(E) serpent_sse2_x86_64(E) serpent_generic(E) blowfish_generic(E) blowfish_x86_64(E) blowfish_common(E) twofish_generic(E) twofish_avx_x86_64(E) twofish_x86_64_3way(E) twofish_x86_64(E) twofish_common(E) xcbc(E) sha256_mb(E) sha256_ssse3(E) sha512_mb(E) mcryptd(E) sha512_ssse3(E) sha512_generic(E) des_generic(E) xt_CHECKSUM(E) ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E) tun(E) ccm(E) nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) xt_CT(E) ip6t_rpfilter(E) ip6t_REJECT(E) nf_reject_ipv6(E) xt_conntrack(E) ip_set(E) nfnetlink(E) ebtable_nat(E) ebtable_broute(E) bridge(E) stp(E) llc(E) ip6table_nat(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) nf_nat_ipv6(E) ip6table_mangle(E) ip6table_raw(E) ip6table_security(E) iptable_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) ebtable_filter(E) ebtables(E) ip6table_filter(E) ip6_tables(E) cmac(E) bnep(E) hwmon_vid(E) ib_isert(E) iscsi_target_mod(E) ib_srpt(E) target_core_mod(E) ib_srp(E) scsi_transport_srp(E) vfat(E) fat(E) xfs(E) libcrc32c(E) ib_ucm(E) arc4(E) rpcrdma(E) sunrpc(E) iwlmvm(E) mac80211(E) rdma_ucm(E) ib_uverbs(E) ib_iser(E) snd_hda_codec_realtek(E) rdma_cm(E) btusb(E) snd_hda_codec_generic(E) snd_hda_codec_hdmi(E) iw_cm(E) btrtl(E) snd_hda_intel(E) btbcm(E) btintel(E) snd_hda_codec(E) bluetooth(E) snd_hda_core(E) ib_umad(E) edac_mce_amd(E) snd_hwdep(E) ib_ipoib(E) libiscsi(E) scsi_transport_iscsi(E) iwlwifi(E) snd_seq(E) snd_seq_device(E) kvm_amd(E) ib_cm(E) mlx4_ib(E) ib_core(E) kvm(E) snd_pcm(E) snd_timer(E) sp5100_tco(E) snd(E) i2c_piix4(E) soundcore(E) gpio_amdpt(E) gpio_generic(E) ecdh_generic(E) cfg80211(E) irqbypass(E) mxm_wmi(E) rfkill(E) wmi_bmof(E) crct10dif_pclmul(E) crc32_pclmul(E) wmi(E) ghash_clmulni_intel(E) k10temp(E) ccp(E) pinctrl_amd(E) shpchp(E) pcspkr(E) acpi_cpufreq(E) mlx4_en(E) amdkfd(E) amd_iommu_v2(E) amdgpu(E) chash(E) gpu_sched(E) drm_kms_helper(E) ttm(E) crc32c_intel(E) mlx4_core(E) igb(E) devlink(E) drm(E) ptp(E) pps_core(E) dca(E) i2c_algo_bit(E) nvme(E) nvme_core(E) tcp_bbr(E) CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 4.17.2 #4 Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 3803 01/22/2018 RIP: 0010:iwl_mvm_tx_tso_segment+0x28a/0x2a0 [iwlmvm] RSP: 0018:ffff961e1ec437c0 EFLAGS: 00010202 RAX: 00000000000002c0 RBX: fffffffffffffff4 RCX: ffff961c38339c64 RDX: ffff961c38339c00 RSI: 0000000000000000 RDI: ffff961c38339c64 RBP: ffff961e1ec43850 R08: ffff9618f295b700 R09: fffffffffffffff4 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000dc6f R13: 0000000000000008 R14: 0000000000000000 R15: 00000000000005a8 FS: 0000000000000000(0000) GS:ffff961e1ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559b4fc3e240 CR3: 000000063c20a000 CR4: 00000000003406e0 Call Trace: <IRQ> ? iwl_mvm_tx_mpdu+0x1a2/0x5b0 [iwlmvm] iwl_mvm_tx_skb+0x3f0/0x440 [iwlmvm] iwl_mvm_mac_tx+0xb5/0x1b0 [iwlmvm] ieee80211_tx_frags+0x14c/0x220 [mac80211] ieee80211_xmit_fast+0x7ea/0x8b0 [mac80211] ? sched_clock+0x5/0x10 ? sched_clock_cpu+0xc/0xb0 __ieee80211_subif_start_xmit+0xa9/0x1e0 [mac80211] ieee80211_subif_start_xmit+0x44/0x2d0 [mac80211] dev_hard_start_xmit+0xa5/0x210 sch_direct_xmit+0x158/0x340 __dev_queue_xmit+0x53b/0x7e0 ? xfrm_lookup+0x2f2/0x930 ip_finish_output2+0x29c/0x3b0 ip_output+0x6c/0xe0 ? ip_append_data.part.50+0xc0/0xc0 ip_forward+0x396/0x450 ? ip_defrag.cold.17+0x22/0x22 ip_rcv+0x26e/0x3a6 ? inet_add_protocol.cold.1+0x1e/0x1e __netif_receive_skb_core+0x4fb/0xb30 ? mlx4_en_process_rx_cq+0x9b5/0xc60 [mlx4_en] ? ktime_get_with_offset+0x4d/0xc0 netif_receive_skb_internal+0x42/0xf0 napi_gro_flush+0x50/0x70 napi_complete_done+0x39/0xf0 mlx4_en_poll_rx_cq+0xa4/0xf0 [mlx4_en] net_rx_action+0x149/0x3a0 __do_softirq+0xe3/0x2d4 irq_exit+0xe8/0xf0 do_IRQ+0x7d/0xc0 common_interrupt+0xf/0xf </IRQ> RIP: 0010:native_safe_halt+0x2/0x10 RSP: 0018:ffffaeb84323be40 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffda RAX: 0000000080000000 RBX: ffff961dfa98dc00 RCX: ffff961e1ec40000 RDX: 4ec4ec4ec4ec4ec5 RSI: 0000000000000034 RDI: ffff961dfa98dc64 RBP: ffff961dfa98dc64 R08: 00002b4f757437c4 R09: 0000000000000249 R10: 000000000000024b R11: ffff961e1ec5fae8 R12: 0000000000000001 R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000 acpi_safe_halt+0x1b/0x30 acpi_idle_enter+0xf3/0x2b0 cpuidle_enter_state+0x70/0x2a0 do_idle+0x21d/0x260 cpu_startup_entry+0x6f/0x80 start_secondary+0x1a4/0x1f0 secondary_startup_64+0xa5/0xb0 Code: 00 48 03 bb d0 00 00 00 44 89 44 24 14 48 89 74 24 08 48 89 0c 24 e8 76 ba 94 ea 44 8b 44 24 14 48 8b 74 24 08 48 8b 0c 24 eb aa <0f> 0b b8 ea ff ff ff e9 78 ff ff ff e8 45 19 22 ea 0f 1f 44 00

7 years, 5 months

3
3
0 0

[PATCH] arm64: dts: marvell: fix CP110 ICU node size

by Miquel Raynal

commit 2f872ddcdb1e8e2186162616cea4581b8403849d upstream. ICU size in CP110 is not 0x10 but at least 0x440 bytes long (from the specification). Fixes: 6ef84a827c37 ("arm64: dts: marvell: enable GICP and ICU on Armada 7K/8K") Cc: stable(a)vger.kernel.org # 4.14.x Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> Reviewed-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com> --- Backport to 4.14 stable tree: the original patch did not applied because of the effort of DT de-duplication that merged two files in one. arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 2 +- arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi index 9a7b63cd63a3..7c19f32d0f44 100644 --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi @@ -169,7 +169,7 @@ cpm_icu: interrupt-controller@1e0000 { compatible = "marvell,cp110-icu"; - reg = <0x1e0000 0x10>; + reg = <0x1e0000 0x440>; #interrupt-cells = <3>; interrupt-controller; msi-parent = <&gicp>; diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi index faf28633a309..150e97a1dfea 100644 --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi @@ -169,7 +169,7 @@ cps_icu: interrupt-controller@1e0000 { compatible = "marvell,cp110-icu"; - reg = <0x1e0000 0x10>; + reg = <0x1e0000 0x440>; #interrupt-cells = <3>; interrupt-controller; msi-parent = <&gicp>; -- 2.14.1

7 years, 5 months

2
2
0 0

[PATCH] HID: debug: check length before copy_to_user()

by Daniel Rosenberg

If our length is greater than the size of the buffer, we overflow the buffer Signed-off-by: Daniel Rosenberg <drosen(a)google.com> Cc: stable(a)vger.kernel.org --- drivers/hid/hid-debug.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c index 8469b6964ff64..b48100236df89 100644 --- a/drivers/hid/hid-debug.c +++ b/drivers/hid/hid-debug.c @@ -1154,6 +1154,8 @@ static ssize_t hid_debug_events_read(struct file *file, char __user *buffer, goto out; if (list->tail > list->head) { len = list->tail - list->head; + if (len > count) + len = count; if (copy_to_user(buffer + ret, &list->hid_debug_buf[list->head], len)) { ret = -EFAULT; @@ -1163,6 +1165,8 @@ static ssize_t hid_debug_events_read(struct file *file, char __user *buffer, list->head += len; } else { len = HID_DEBUG_BUFSIZE - list->head; + if (len > count) + len = count; if (copy_to_user(buffer, &list->hid_debug_buf[list->head], len)) { ret = -EFAULT; @@ -1170,7 +1174,9 @@ static ssize_t hid_debug_events_read(struct file *file, char __user *buffer, } list->head = 0; ret += len; - goto copy_rest; + count -= len; + if (count > 0) + goto copy_rest; } } -- 2.18.0.399.gad0ab374a1-goog

7 years, 5 months

4
3
0 0

[PATCH v4 3/3] x86/mm: add TLB purge to free pmd/pte page interfaces

by Toshi Kani

ioremap() calls pud_free_pmd_page() / pmd_free_pte_page() when it creates a pud / pmd map. The following preconditions are met at their entry. - All pte entries for a target pud/pmd address range have been cleared. - System-wide TLB purges have been peformed for a target pud/pmd address range. The preconditions assure that there is no stale TLB entry for the range. Speculation may not cache TLB entries since it requires all levels of page entries, including ptes, to have P & A-bits set for an associated address. However, speculation may cache pud/pmd entries (paging-structure caches) when they have P-bit set. Add a system-wide TLB purge (INVLPG) to a single page after clearing pud/pmd entry's P-bit. SDM 4.10.4.1, Operation that Invalidate TLBs and Paging-Structure Caches, states that: INVLPG invalidates all paging-structure caches associated with the current PCID regardless of the liner addresses to which they correspond. Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces") Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Joerg Roedel <joro(a)8bytes.org> Cc: <stable(a)vger.kernel.org> --- arch/x86/mm/pgtable.c | 36 ++++++++++++++++++++++++++++++------ 1 file changed, 30 insertions(+), 6 deletions(-) diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c index fbd14e506758..e3deefb891da 100644 --- a/arch/x86/mm/pgtable.c +++ b/arch/x86/mm/pgtable.c @@ -725,24 +725,44 @@ int pmd_clear_huge(pmd_t *pmd) * @pud: Pointer to a PUD. * @addr: Virtual address associated with pud. * - * Context: The pud range has been unmaped and TLB purged. + * Context: The pud range has been unmapped and TLB purged. * Return: 1 if clearing the entry succeeded. 0 otherwise. + * + * NOTE: Callers must allow a single page allocation. */ int pud_free_pmd_page(pud_t *pud, unsigned long addr) { - pmd_t *pmd; + pmd_t *pmd, *pmd_sv; + pte_t *pte; int i; if (pud_none(*pud)) return 1; pmd = (pmd_t *)pud_page_vaddr(*pud); + pmd_sv = (pmd_t *)__get_free_page(GFP_KERNEL); + if (!pmd_sv) + return 0; - for (i = 0; i < PTRS_PER_PMD; i++) - if (!pmd_free_pte_page(&pmd[i], addr + (i * PMD_SIZE))) - return 0; + for (i = 0; i < PTRS_PER_PMD; i++) { + pmd_sv[i] = pmd[i]; + if (!pmd_none(pmd[i])) + pmd_clear(&pmd[i]); + } pud_clear(pud); + + /* INVLPG to clear all paging-structure caches */ + flush_tlb_kernel_range(addr, addr + PAGE_SIZE-1); + + for (i = 0; i < PTRS_PER_PMD; i++) { + if (!pmd_none(pmd_sv[i])) { + pte = (pte_t *)pmd_page_vaddr(pmd_sv[i]); + free_page((unsigned long)pte); + } + } + + free_page((unsigned long)pmd_sv); free_page((unsigned long)pmd); return 1; @@ -753,7 +773,7 @@ int pud_free_pmd_page(pud_t *pud, unsigned long addr) * @pmd: Pointer to a PMD. * @addr: Virtual address associated with pmd. * - * Context: The pmd range has been unmaped and TLB purged. + * Context: The pmd range has been unmapped and TLB purged. * Return: 1 if clearing the entry succeeded. 0 otherwise. */ int pmd_free_pte_page(pmd_t *pmd, unsigned long addr) @@ -765,6 +785,10 @@ int pmd_free_pte_page(pmd_t *pmd, unsigned long addr) pte = (pte_t *)pmd_page_vaddr(*pmd); pmd_clear(pmd); + + /* INVLPG to clear all paging-structure caches */ + flush_tlb_kernel_range(addr, addr + PAGE_SIZE-1); + free_page((unsigned long)pte); return 1;

7 years, 5 months

2
1
0 0

[PATCH v4 1/3] x86/mm: disable ioremap free page handling on x86-PAE

by Toshi Kani

ioremap() supports pmd mappings on x86-PAE. However, kernel's pmd tables are not shared among processes on x86-PAE. Therefore, any update to sync'd pmd entries need re-syncing. Freeing a pte page also leads to a vmalloc fault and hits the BUG_ON in vmalloc_sync_one(). Disable free page handling on x86-PAE. pud_free_pmd_page() and pmd_free_pte_page() simply return 0 if a given pud/pmd entry is present. This assures that ioremap() does not update sync'd pmd entries at the cost of falling back to pte mappings. Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces") Reported-by: Joerg Roedel <joro(a)8bytes.org> Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Joerg Roedel <joro(a)8bytes.org> Cc: <stable(a)vger.kernel.org> --- arch/x86/mm/pgtable.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c index 47b5951e592b..1aeb7a5dbce5 100644 --- a/arch/x86/mm/pgtable.c +++ b/arch/x86/mm/pgtable.c @@ -719,6 +719,7 @@ int pmd_clear_huge(pmd_t *pmd) return 0; } +#ifdef CONFIG_X86_64 /** * pud_free_pmd_page - Clear pud entry and free pmd page. * @pud: Pointer to a PUD. @@ -766,4 +767,22 @@ int pmd_free_pte_page(pmd_t *pmd) return 1; } + +#else /* !CONFIG_X86_64 */ + +int pud_free_pmd_page(pud_t *pud) +{ + return pud_none(*pud); +} + +/* + * Disable free page handling on x86-PAE. This assures that ioremap() + * does not update sync'd pmd entries. See vmalloc_sync_one(). + */ +int pmd_free_pte_page(pmd_t *pmd) +{ + return pmd_none(*pmd); +} + +#endif /* CONFIG_X86_64 */ #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */

7 years, 5 months

2
1
0 0

[PATCH] cifs: Fix memory leak in smb2_set_ea()

by Paulo Alcantara

This patch fixes a memory leak when doing a setxattr(2) in SMB2+. Signed-off-by: Paulo Alcantara <palcantara(a)suse.de> Cc: stable(a)vger.kernel.org --- fs/cifs/smb2ops.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c index 0356b5559c71..957ea2a5cf1d 100644 --- a/fs/cifs/smb2ops.c +++ b/fs/cifs/smb2ops.c @@ -855,6 +855,8 @@ smb2_set_ea(const unsigned int xid, struct cifs_tcon *tcon, rc = SMB2_set_ea(xid, tcon, fid.persistent_fid, fid.volatile_fid, ea, len); + kfree(ea); + SMB2_close(xid, tcon, fid.persistent_fid, fid.volatile_fid); return rc; -- 2.18.0

7 years, 5 months

1
0
0 0

[PATCH 1/4] USB: serial: keyspan_pda: fix modem-status error handling

by Johan Hovold

Fix broken modem-status error handling which could lead to bits of slab data leaking to user space. Fixes: 3b36a8fd6777 ("usb: fix uninitialized variable warning in keyspan_pda") Cc: stable <stable(a)vger.kernel.org> # 2.6.27 Cc: Benny Halevy <bhalevy(a)panasas.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/usb/serial/keyspan_pda.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/serial/keyspan_pda.c b/drivers/usb/serial/keyspan_pda.c index 5169624d8b11..38d43c4b7ce5 100644 --- a/drivers/usb/serial/keyspan_pda.c +++ b/drivers/usb/serial/keyspan_pda.c @@ -369,8 +369,10 @@ static int keyspan_pda_get_modem_info(struct usb_serial *serial, 3, /* get pins */ USB_TYPE_VENDOR|USB_RECIP_INTERFACE|USB_DIR_IN, 0, 0, data, 1, 2000); - if (rc >= 0) + if (rc == 1) *value = *data; + else if (rc >= 0) + rc = -EIO; kfree(data); return rc; -- 2.18.0

7 years, 5 months

1
1
0 0

[PATCH v3] block: don't use blocking queue entered for recursive bio submits

by Alexandru Moise

From: Jens Axboe <axboe(a)kernel.dk> commit cd4a4ae4683dc2e09380118e205e057896dcda2b upstream If we end up splitting a bio and the queue goes away between the initial submission and the later split submission, then we can block forever in blk_queue_enter() waiting for the reference to drop to zero. This will never happen, since we already hold a reference. Mark a split bio as already having entered the queue, so we can just use the live non-blocking queue enter variant. Thanks to Tetsuo Handa for the analysis. We're running fio tests and the tasks get stuck in a D state forever when systemd-udevd tries to read the partition table. This patch solves it. Please apply to 4.17 stable. Reported-by: syzbot+c4f9cebf9d651f6e54de(a)syzkaller.appspotmail.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Alexandru Moise <00moses.alexander00(a)gmail.com> --- v2: Fixed "From:" v3: Added "From: Jens Axboe" above commit sha block/blk-core.c | 4 +++- block/blk-merge.c | 10 ++++++++++ include/linux/blk_types.h | 2 ++ 3 files changed, 15 insertions(+), 1 deletion(-) diff --git a/block/blk-core.c b/block/blk-core.c index b559b9d4f1a2..47ab2d9d02d9 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -2392,7 +2392,9 @@ blk_qc_t generic_make_request(struct bio *bio) if (bio->bi_opf & REQ_NOWAIT) flags = BLK_MQ_REQ_NOWAIT; - if (blk_queue_enter(q, flags) < 0) { + if (bio_flagged(bio, BIO_QUEUE_ENTERED)) + blk_queue_enter_live(q); + else if (blk_queue_enter(q, flags) < 0) { if (!blk_queue_dying(q) && (bio->bi_opf & REQ_NOWAIT)) bio_wouldblock_error(bio); else diff --git a/block/blk-merge.c b/block/blk-merge.c index 782940c65d8a..481dc02668f9 100644 --- a/block/blk-merge.c +++ b/block/blk-merge.c @@ -210,6 +210,16 @@ void blk_queue_split(struct request_queue *q, struct bio **bio) /* there isn't chance to merge the splitted bio */ split->bi_opf |= REQ_NOMERGE; + /* + * Since we're recursing into make_request here, ensure + * that we mark this bio as already having entered the queue. + * If not, and the queue is going away, we can get stuck + * forever on waiting for the queue reference to drop. But + * that will never happen, as we're already holding a + * reference to it. + */ + bio_set_flag(*bio, BIO_QUEUE_ENTERED); + bio_chain(split, *bio); trace_block_split(q, split, (*bio)->bi_iter.bi_sector); generic_make_request(*bio); diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h index 17b18b91ebac..1602bf4ab4cd 100644 --- a/include/linux/blk_types.h +++ b/include/linux/blk_types.h @@ -186,6 +186,8 @@ struct bio { * throttling rules. Don't do it again. */ #define BIO_TRACE_COMPLETION 10 /* bio_endio() should trace the final completion * of this bio. */ +#define BIO_QUEUE_ENTERED 11 /* can use blk_queue_enter_live() */ + /* See BVEC_POOL_OFFSET below before adding new flags */ /* -- 2.18.0

7 years, 5 months

2
1
0 0

[PATCH v2] ARM: dts: armada-38x: use the new thermal binding

by Baruch Siach

Commit 2f28e4c24b10e (thermal: armada: Clarify control registers accesses) introduced the new thermal binding. The new binding extends the second registers field size to 8. Switch to the new binding to fix thermal reading values. Without this change the fix for errata #132698 introduced in commit 8c0b888f661 (thermal: armada: Change sensors trim default value) has no effect. Cc: stable(a)vger.kernel.org # v4.16+ Reviewed-by: Miquel Raynal <miquel.raynal(a)bootlin.com> Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> --- v2: * Typo fixes (Andreas Färber) * Add Miquel's review tag * Minor wording changes * Cc stable --- arch/arm/boot/dts/armada-38x.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi index 18edc9bc7927..929459c42760 100644 --- a/arch/arm/boot/dts/armada-38x.dtsi +++ b/arch/arm/boot/dts/armada-38x.dtsi @@ -547,7 +547,7 @@ thermal: thermal@e8078 { compatible = "marvell,armada380-thermal"; - reg = <0xe4078 0x4>, <0xe4074 0x4>; + reg = <0xe4078 0x4>, <0xe4070 0x8>; status = "okay"; }; -- 2.18.0

7 years, 5 months

2
1
0 0

[PATCH v2] block: don't use blocking queue entered for recursive bio submits

by Alexandru Moise

commit cd4a4ae4683dc2e09380118e205e057896dcda2b upstream. If we end up splitting a bio and the queue goes away between the initial submission and the later split submission, then we can block forever in blk_queue_enter() waiting for the reference to drop to zero. This will never happen, since we already hold a reference. Mark a split bio as already having entered the queue, so we can just use the live non-blocking queue enter variant. Thanks to Tetsuo Handa for the analysis. We're running fio tests and the tasks get stuck in a D state forever when systemd-udevd tries to read the partition table. This patch solves it. Please apply to 4.17 stable. Reported-by: syzbot+c4f9cebf9d651f6e54de(a)syzkaller.appspotmail.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Alexandru Moise <00moses.alexander00(a)gmail.com> --- v2: Changed "From:" The email sent as being from Jens instead of me, sorry again Jens. block/blk-core.c | 4 +++- block/blk-merge.c | 10 ++++++++++ include/linux/blk_types.h | 2 ++ 3 files changed, 15 insertions(+), 1 deletion(-) diff --git a/block/blk-core.c b/block/blk-core.c index b559b9d4f1a2..47ab2d9d02d9 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -2392,7 +2392,9 @@ blk_qc_t generic_make_request(struct bio *bio) if (bio->bi_opf & REQ_NOWAIT) flags = BLK_MQ_REQ_NOWAIT; - if (blk_queue_enter(q, flags) < 0) { + if (bio_flagged(bio, BIO_QUEUE_ENTERED)) + blk_queue_enter_live(q); + else if (blk_queue_enter(q, flags) < 0) { if (!blk_queue_dying(q) && (bio->bi_opf & REQ_NOWAIT)) bio_wouldblock_error(bio); else diff --git a/block/blk-merge.c b/block/blk-merge.c index 782940c65d8a..481dc02668f9 100644 --- a/block/blk-merge.c +++ b/block/blk-merge.c @@ -210,6 +210,16 @@ void blk_queue_split(struct request_queue *q, struct bio **bio) /* there isn't chance to merge the splitted bio */ split->bi_opf |= REQ_NOMERGE; + /* + * Since we're recursing into make_request here, ensure + * that we mark this bio as already having entered the queue. + * If not, and the queue is going away, we can get stuck + * forever on waiting for the queue reference to drop. But + * that will never happen, as we're already holding a + * reference to it. + */ + bio_set_flag(*bio, BIO_QUEUE_ENTERED); + bio_chain(split, *bio); trace_block_split(q, split, (*bio)->bi_iter.bi_sector); generic_make_request(*bio); diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h index 17b18b91ebac..1602bf4ab4cd 100644 --- a/include/linux/blk_types.h +++ b/include/linux/blk_types.h @@ -186,6 +186,8 @@ struct bio { * throttling rules. Don't do it again. */ #define BIO_TRACE_COMPLETION 10 /* bio_endio() should trace the final completion * of this bio. */ +#define BIO_QUEUE_ENTERED 11 /* can use blk_queue_enter_live() */ + /* See BVEC_POOL_OFFSET below before adding new flags */ /* -- 2.18.0

7 years, 5 months

3
6
0 0

[PATCH] ubifs: log: Don't leak kernel memory to the MTD

by Richard Weinberger

ubifs_log_start_commit() allocates a buffer with kmalloc(), this buffer is used to build UBIFS CS and REF nodes, all structure attributes get set, except for the padding field in the ubifs_ref_node. That way we leak 28 bytes of kernel memory to the MTD. Fix it by using kzalloc(). Cc: stable(a)vger.kernel.org Fixes: 1e51764a3c2a ("UBIFS: add new flash file system") Signed-off-by: Richard Weinberger <richard(a)nod.at> --- fs/ubifs/log.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ubifs/log.c b/fs/ubifs/log.c index 7cffa120a750..60d49c6dd470 100644 --- a/fs/ubifs/log.c +++ b/fs/ubifs/log.c @@ -369,7 +369,7 @@ int ubifs_log_start_commit(struct ubifs_info *c, int *ltail_lnum) max_len = UBIFS_CS_NODE_SZ + c->jhead_cnt * UBIFS_REF_NODE_SZ; max_len = ALIGN(max_len, c->min_io_size); - buf = cs = kmalloc(max_len, GFP_NOFS); + buf = cs = kzalloc(max_len, GFP_NOFS); if (!buf) return -ENOMEM; -- 2.18.0

7 years, 5 months

1
0
0 0

[PATCH 2/4] rtc: omap: fix resource leak in registration error path

by Johan Hovold

Make sure to deregister the pin controller in case rtc registration fails. Fixes: 57072758623f ("rtc: omap: switch to rtc_register_device") Cc: stable <stable(a)vger.kernel.org> # 4.14 Cc: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/rtc/rtc-omap.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index c214b69a8787..6a7b804c3074 100644 --- a/drivers/rtc/rtc-omap.c +++ b/drivers/rtc/rtc-omap.c @@ -873,7 +873,7 @@ static int omap_rtc_probe(struct platform_device *pdev) ret = rtc_register_device(rtc->rtc); if (ret) - goto err; + goto err_deregister_pinctrl; rtc_nvmem_register(rtc->rtc, &omap_rtc_nvmem_config); @@ -886,6 +886,8 @@ static int omap_rtc_probe(struct platform_device *pdev) return 0; +err_deregister_pinctrl: + pinctrl_unregister(rtc->pctldev); err: clk_disable_unprepare(rtc->clk); device_init_wakeup(&pdev->dev, false); -- 2.18.0

7 years, 5 months

1
0
0 0

Offerte

by Firma

Sehr geehrte Damen und Herren, ich habe bemerkt, dass Sie Ihr Angebot zum größten Teil an Firmen richten und deswegen möchte ich Ihnen ein Produkt anbieten, welches zur Erhöhung der Anzahl Ihrer Kunden erheblich beitragen wird. Die Datenbanken der Firmen sind in für Sie interessante und relevante Zielgruppen untergliedert. Der neue Katalog enthält 187.764 schweizerische Firmen und stellt solche Daten zur Verfügung wie: Namen der Firma, Firmenanschrift, Kontaktdaten des Firmeninhabers oder des Managers, E-Mail-Adresse, Telefonummer, Faxnummer, Branche usw. http://www.topadressen-ch.net/?page=catalog *** 1. Schweiz 2018 ( 187 764 ) - 149 EUR ( bis zum 04.07.2018 ) *** Die Verwendungsmöglichkeiten der Datenbanken sind praktisch unbegrenzt und Sie können durch Verwendung der von uns entwickelten Programme des personalisierten Versendens von Angeboten u.ä. mittels E-mailing bzw. Fax effektive und sichere Werbekampagnen damit durchführen. Bitte informieren Sie sich über die weiteren Details einmal unverbindlich auf unseren Webseite: http://www.topadressen-ch.net/?page=catalog MfG GL-Team

7 years, 5 months

1
0
0 0

[PATCH] drm/amdgpu: Reserve fence slots for command submission

by Junwei Zhang

From: Michel Dänzer <michel.daenzer(a)amd.com> Without this, there could not be enough slots, which could trigger the BUG_ON in reservation_object_add_shared_fence. v2: * Jump to the error label instead of returning directly (Jerry Zhang) v3: * Reserve slots for command submission after VM updates (Christian König) Cc: stable(a)vger.kernel.org Bugzilla: https://bugs.freedesktop.org/106418 Reported-by: mikhail.v.gavrilov(a)gmail.com Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com> Signed-off-by: Junwei Zhang <Jerry.Zhang(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 7a625f3..1bc0281 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -928,6 +928,10 @@ static int amdgpu_cs_ib_vm_chunk(struct amdgpu_device *adev, r = amdgpu_bo_vm_update_pte(p); if (r) return r; + + r = reservation_object_reserve_shared(vm->root.base.bo->tbo.resv); + if (r) + return r; } return amdgpu_cs_sync_rings(p); -- 1.9.1

7 years, 5 months

3
2
0 0

v4.14.53 build: 0 failures 0 warnings (v4.14.53)

by Build bot for Mark Brown

Tree/Branch: v4.14.53 Git describe: v4.14.53 Commit: fa745a1bd9 Linux 4.14.53 Build Time: 98 min 43 sec Passed: 11 / 11 (100.00 %) Failed: 0 / 11 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig x86_64-allmodconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 5 months

1
0
0 0

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

by Build bot for Mark Brown

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

7 years, 5 months

1
0
0 0

[patch 5/5] mm: teach dump_page() to correctly output poisoned struct pages

by akpm＠linux-foundation.org

From: Pavel Tatashin <pasha.tatashin(a)oracle.com> Subject: mm: teach dump_page() to correctly output poisoned struct pages If struct page is poisoned, and uninitialized access is detected via PF_POISONED_CHECK(page) dump_page() is called to output the page. But, the dump_page() itself accesses struct page to determine how to print it, and therefore gets into a recursive loop. For example: dump_page() __dump_page() PageSlab(page) PF_POISONED_CHECK(page) VM_BUG_ON_PGFLAGS(PagePoisoned(page), page) dump_page() recursion loop. Link: http://lkml.kernel.org/r/20180702180536.2552-1-pasha.tatashin@oracle.com Fixes: f165b378bbdf ("mm: uninitialized struct page poisoning sanity checking") Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/debug.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff -puN mm/debug.c~mm-teach-dump_page-to-correctly-output-poisoned-struct-pages mm/debug.c --- a/mm/debug.c~mm-teach-dump_page-to-correctly-output-poisoned-struct-pages +++ a/mm/debug.c @@ -43,12 +43,25 @@ const struct trace_print_flags vmaflag_n void __dump_page(struct page *page, const char *reason) { + bool page_poisoned = PagePoisoned(page); + int mapcount; + + /* + * If struct page is poisoned don't access Page*() functions as that + * leads to recursive loop. Page*() check for poisoned pages, and calls + * dump_page() when detected. + */ + if (page_poisoned) { + pr_emerg("page:%px is uninitialized and poisoned", page); + goto hex_only; + } + /* * Avoid VM_BUG_ON() in page_mapcount(). * page->_mapcount space in struct page is used by sl[aou]b pages to * encode own info. */ - int mapcount = PageSlab(page) ? 0 : page_mapcount(page); + mapcount = PageSlab(page) ? 0 : page_mapcount(page); pr_emerg("page:%px count:%d mapcount:%d mapping:%px index:%#lx", page, page_ref_count(page), mapcount, @@ -60,6 +73,7 @@ void __dump_page(struct page *page, cons pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags); +hex_only: print_hex_dump(KERN_ALERT, "raw: ", DUMP_PREFIX_NONE, 32, sizeof(unsigned long), page, sizeof(struct page), false); @@ -68,7 +82,7 @@ void __dump_page(struct page *page, cons pr_alert("page dumped because: %s\n", reason); #ifdef CONFIG_MEMCG - if (page->mem_cgroup) + if (!page_poisoned && page->mem_cgroup) pr_alert("page->mem_cgroup:%px\n", page->mem_cgroup); #endif } _

7 years, 5 months

1
0
0 0

[patch 2/5] mm: hugetlb: yield when prepping struct pages

by akpm＠linux-foundation.org

From: Cannon Matthews <cannonmatthews(a)google.com> Subject: mm: hugetlb: yield when prepping struct pages When booting with very large numbers of gigantic (i.e. 1G) pages, the operations in the loop of gather_bootmem_prealloc, and specifically prep_compound_gigantic_page, takes a very long time, and can cause a softlockup if enough pages are requested at boot. For example booting with 3844 1G pages requires prepping (set_compound_head, init the count) over 1 billion 4K tail pages, which takes considerable time. Add a cond_resched() to the outer loop in gather_bootmem_prealloc() to prevent this lockup. Tested: Booted with softlockup_panic=1 hugepagesz=1G hugepages=3844 and no softlockup is reported, and the hugepages are reported as successfully setup. Link: http://lkml.kernel.org/r/20180627214447.260804-1-cannonmatthews@google.com Signed-off-by: Cannon Matthews <cannonmatthews(a)google.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Andres Lagar-Cavilla <andreslc(a)google.com> Cc: Peter Feiner <pfeiner(a)google.com> Cc: Greg Thelen <gthelen(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 1 + 1 file changed, 1 insertion(+) diff -puN mm/hugetlb.c~mm-hugetlb-yield-when-prepping-struct-pages mm/hugetlb.c --- a/mm/hugetlb.c~mm-hugetlb-yield-when-prepping-struct-pages +++ a/mm/hugetlb.c @@ -2163,6 +2163,7 @@ static void __init gather_bootmem_preall */ if (hstate_is_gigantic(h)) adjust_managed_page_count(page, 1 << h->order); + cond_resched(); } } _

7 years, 5 months

1
0
0 0

[patch 1/5] userfaultfd: hugetlbfs: fix userfaultfd_huge_must_wait() pte access

by akpm＠linux-foundation.org

From: Janosch Frank <frankja(a)linux.ibm.com> Subject: userfaultfd: hugetlbfs: fix userfaultfd_huge_must_wait() pte access Use huge_ptep_get() to translate huge ptes to normal ptes so we can check them with the huge_pte_* functions. Otherwise some architectures will check the wrong values and will not wait for userspace to bring in the memory. Link: http://lkml.kernel.org/r/20180626132421.78084-1-frankja@linux.ibm.com Fixes: 369cd2121be4 ("userfaultfd: hugetlbfs: userfaultfd_huge_must_wait for hugepmd ranges") Signed-off-by: Janosch Frank <frankja(a)linux.ibm.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/userfaultfd.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff -puN fs/userfaultfd.c~userfaultfd-hugetlbfs-fix-userfaultfd_huge_must_wait-pte-access fs/userfaultfd.c --- a/fs/userfaultfd.c~userfaultfd-hugetlbfs-fix-userfaultfd_huge_must_wait-pte-access +++ a/fs/userfaultfd.c @@ -222,24 +222,26 @@ static inline bool userfaultfd_huge_must unsigned long reason) { struct mm_struct *mm = ctx->mm; - pte_t *pte; + pte_t *ptep, pte; bool ret = true; VM_BUG_ON(!rwsem_is_locked(&mm->mmap_sem)); - pte = huge_pte_offset(mm, address, vma_mmu_pagesize(vma)); - if (!pte) + ptep = huge_pte_offset(mm, address, vma_mmu_pagesize(vma)); + + if (!ptep) goto out; ret = false; + pte = huge_ptep_get(ptep); /* * Lockless access: we're in a wait_event so it's ok if it * changes under us. */ - if (huge_pte_none(*pte)) + if (huge_pte_none(pte)) ret = true; - if (!huge_pte_write(*pte) && (reason & VM_UFFD_WP)) + if (!huge_pte_write(pte) && (reason & VM_UFFD_WP)) ret = true; out: return ret; _

7 years, 5 months

1
0
0 0

+ mm-fix-locked-field-in-proc-pid-smaps.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: fs/proc/task_mmu.c: fix Locked field in /proc/pid/smaps* has been added to the -mm tree. Its filename is mm-fix-locked-field-in-proc-pid-smaps.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-fix-locked-field-in-proc-pid-sm… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-fix-locked-field-in-proc-pid-sm… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Vlastimil Babka <vbabka(a)suse.cz> Subject: fs/proc/task_mmu.c: fix Locked field in /proc/pid/smaps* Thomas reports: : While looking around in /proc on my v4.14.52 system I noticed that : all processes got a lot of "Locked" memory in /proc/*/smaps. A lot : more memory than a regular user can usually lock with mlock(). : : commit 493b0e9d945fa9dfe96be93ae41b4ca4b6fdb317 (v4.14-rc1) seems : to have changed the behavior of "Locked". : : Before that commit the code was like this. Notice the VM_LOCKED : check. : : (vma->vm_flags & VM_LOCKED) ? : (unsigned long)(mss.pss >> (10 + PSS_SHIFT)) : 0); : : After that commit Locked is now the same as Pss. This looks like a : mistake. : : (unsigned long)(mss->pss >> (10 + PSS_SHIFT))); Indeed, the commit has added mss->pss_locked with the correct value that depends on VM_LOCKED, but forgot to actually use it. Fix it. Link: http://lkml.kernel.org/r/ebf6c7fb-fec3-6a26-544f-710ed193c154@suse.cz Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup") Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Reported-by: Thomas Lindroth <thomas.lindroth(a)gmail.com> Cc: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_mmu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN fs/proc/task_mmu.c~mm-fix-locked-field-in-proc-pid-smaps fs/proc/task_mmu.c --- a/fs/proc/task_mmu.c~mm-fix-locked-field-in-proc-pid-smaps +++ a/fs/proc/task_mmu.c @@ -831,7 +831,8 @@ static int show_smap(struct seq_file *m, SEQ_PUT_DEC(" kB\nSwap: ", mss->swap); SEQ_PUT_DEC(" kB\nSwapPss: ", mss->swap_pss >> PSS_SHIFT); - SEQ_PUT_DEC(" kB\nLocked: ", mss->pss >> PSS_SHIFT); + SEQ_PUT_DEC(" kB\nLocked: ", + mss->pss_locked >> PSS_SHIFT); seq_puts(m, " kB\n"); } if (!rollup_mode) { _ Patches currently in -mm which might be from vbabka(a)suse.cz are mm-page_alloc-actually-ignore-mempolicies-for-high-priority-allocations.patch mm-fix-locked-field-in-proc-pid-smaps.patch

7 years, 5 months

1
0
0 0

v4.9.111 build: 0 failures 0 warnings (v4.9.111)

by Build bot for Mark Brown

Tree/Branch: v4.9.111 Git describe: v4.9.111 Commit: e692f66fab Linux 4.9.111 Build Time: 83 min 48 sec Passed: 11 / 11 (100.00 %) Failed: 0 / 11 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig x86_64-allmodconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror