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

by Hemdan, Hagar Gamal Halim

Hi, Please backport commits: c02d5feb6e2f ("ACPI: processor: perflib: Use the "no limit" frequency QoS") 99387b016022 ("ACPI: processor: perflib: Avoid updating frequency QoS unnecessarily") e8a0e30b742f ("cpufreq: intel_pstate: Drop ACPI _PSS states table patching") To stable trees 5.4.y, 5.10.y, 5.15.y, 6.1.y. These commits fix Intel Turbo enabling when bringing CPUs offline and online again. I've tested this on the mentioned stable trees. Feel free to add Tested-by: Hagar Hemdan <hagarhem(a)amazon.de> Thanks, Hagar Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879

2 years, 2 months

2
1
0 0

FAILED: patch "[PATCH] drm/amd/display: Revert vblank change that causes null" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x c02b04633c4f4654331c53966cb937df1c73a9bb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080128-reshuffle-aching-6a89@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: c02b04633c4f ("drm/amd/display: Revert vblank change that causes null pointer crash") 1a4bcdbea431 ("drm/amd/display: Fix possible underflow for displays with large vblank") 469a62938a45 ("drm/amd/display: update extended blank for dcn314 onwards") e3416e872f84 ("drm/amd/display: Add FAMS validation before trying to use it") 0db13eae41fc ("drm/amd/display: Add minimum Z8 residency debug option") 73dd4ca4b5a0 ("drm/amd/display: Fix Z8 support configurations") db4107e92a81 ("drm/amd/display: fix dc/core/dc.c kernel-doc") 00812bfc7bcb ("drm/amd/display: Add debug option to skip PSR CRTC disable") 80676936805e ("drm/amd/display: Add Z8 allow states to z-state support list") e366f36958f6 ("drm/amd/display: Rework comments on dc file") bd829d570773 ("drm/amd/display: Refactor eDP PSR codes") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From c02b04633c4f4654331c53966cb937df1c73a9bb Mon Sep 17 00:00:00 2001 From: Daniel Miess <daniel.miess(a)amd.com> Date: Thu, 11 May 2023 09:12:09 -0400 Subject: [PATCH] drm/amd/display: Revert vblank change that causes null pointer crash Revert commit 1a4bcdbea431 ("drm/amd/display: Fix possible underflow for displays with large vblank") Because it cause some regression Fixes: 1a4bcdbea431 ("drm/amd/display: Fix possible underflow for displays with large vblank") Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> Acked-by: Tom Chung <chiahsuan.chung(a)amd.com> Signed-off-by: Daniel Miess <daniel.miess(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c b/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c index 554152371eb5..1d00eb9e73c6 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c @@ -33,7 +33,7 @@ #include "dml/display_mode_vba.h" struct _vcs_dpi_ip_params_st dcn3_14_ip = { - .VBlankNomDefaultUS = 800, + .VBlankNomDefaultUS = 668, .gpuvm_enable = 1, .gpuvm_max_page_table_levels = 1, .hostvm_enable = 1, @@ -286,7 +286,7 @@ int dcn314_populate_dml_pipes_from_context_fpu(struct dc *dc, struct dc_state *c struct resource_context *res_ctx = &context->res_ctx; struct pipe_ctx *pipe; bool upscaled = false; - const unsigned int max_allowed_vblank_nom = 1023; + bool isFreesyncVideo = false; dc_assert_fp_enabled(); @@ -300,11 +300,16 @@ int dcn314_populate_dml_pipes_from_context_fpu(struct dc *dc, struct dc_state *c pipe = &res_ctx->pipe_ctx[i]; timing = &pipe->stream->timing; - pipes[pipe_cnt].pipe.dest.vtotal = pipe->stream->adjust.v_total_min; - pipes[pipe_cnt].pipe.dest.vblank_nom = timing->v_total - pipes[pipe_cnt].pipe.dest.vactive; - pipes[pipe_cnt].pipe.dest.vblank_nom = min(pipes[pipe_cnt].pipe.dest.vblank_nom, dcn3_14_ip.VBlankNomDefaultUS); - pipes[pipe_cnt].pipe.dest.vblank_nom = max(pipes[pipe_cnt].pipe.dest.vblank_nom, timing->v_sync_width); - pipes[pipe_cnt].pipe.dest.vblank_nom = min(pipes[pipe_cnt].pipe.dest.vblank_nom, max_allowed_vblank_nom); + isFreesyncVideo = pipe->stream->adjust.v_total_max == pipe->stream->adjust.v_total_min; + isFreesyncVideo = isFreesyncVideo && pipe->stream->adjust.v_total_min > timing->v_total; + + if (!isFreesyncVideo) { + pipes[pipe_cnt].pipe.dest.vblank_nom = + dcn3_14_ip.VBlankNomDefaultUS / (timing->h_total / (timing->pix_clk_100hz / 10000.0)); + } else { + pipes[pipe_cnt].pipe.dest.vtotal = pipe->stream->adjust.v_total_min; + pipes[pipe_cnt].pipe.dest.vblank_nom = timing->v_total - pipes[pipe_cnt].pipe.dest.vactive; + } if (pipe->plane_state && (pipe->plane_state->src_rect.height < pipe->plane_state->dst_rect.height ||

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] drm/amd/display: Revert vblank change that causes null" failed to apply to 6.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.4.y git checkout FETCH_HEAD git cherry-pick -x c02b04633c4f4654331c53966cb937df1c73a9bb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080120-jalapeno-cubicle-d3d2@gregkh' --subject-prefix 'PATCH 6.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From c02b04633c4f4654331c53966cb937df1c73a9bb Mon Sep 17 00:00:00 2001 From: Daniel Miess <daniel.miess(a)amd.com> Date: Thu, 11 May 2023 09:12:09 -0400 Subject: [PATCH] drm/amd/display: Revert vblank change that causes null pointer crash Revert commit 1a4bcdbea431 ("drm/amd/display: Fix possible underflow for displays with large vblank") Because it cause some regression Fixes: 1a4bcdbea431 ("drm/amd/display: Fix possible underflow for displays with large vblank") Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> Acked-by: Tom Chung <chiahsuan.chung(a)amd.com> Signed-off-by: Daniel Miess <daniel.miess(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c b/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c index 554152371eb5..1d00eb9e73c6 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c @@ -33,7 +33,7 @@ #include "dml/display_mode_vba.h" struct _vcs_dpi_ip_params_st dcn3_14_ip = { - .VBlankNomDefaultUS = 800, + .VBlankNomDefaultUS = 668, .gpuvm_enable = 1, .gpuvm_max_page_table_levels = 1, .hostvm_enable = 1, @@ -286,7 +286,7 @@ int dcn314_populate_dml_pipes_from_context_fpu(struct dc *dc, struct dc_state *c struct resource_context *res_ctx = &context->res_ctx; struct pipe_ctx *pipe; bool upscaled = false; - const unsigned int max_allowed_vblank_nom = 1023; + bool isFreesyncVideo = false; dc_assert_fp_enabled(); @@ -300,11 +300,16 @@ int dcn314_populate_dml_pipes_from_context_fpu(struct dc *dc, struct dc_state *c pipe = &res_ctx->pipe_ctx[i]; timing = &pipe->stream->timing; - pipes[pipe_cnt].pipe.dest.vtotal = pipe->stream->adjust.v_total_min; - pipes[pipe_cnt].pipe.dest.vblank_nom = timing->v_total - pipes[pipe_cnt].pipe.dest.vactive; - pipes[pipe_cnt].pipe.dest.vblank_nom = min(pipes[pipe_cnt].pipe.dest.vblank_nom, dcn3_14_ip.VBlankNomDefaultUS); - pipes[pipe_cnt].pipe.dest.vblank_nom = max(pipes[pipe_cnt].pipe.dest.vblank_nom, timing->v_sync_width); - pipes[pipe_cnt].pipe.dest.vblank_nom = min(pipes[pipe_cnt].pipe.dest.vblank_nom, max_allowed_vblank_nom); + isFreesyncVideo = pipe->stream->adjust.v_total_max == pipe->stream->adjust.v_total_min; + isFreesyncVideo = isFreesyncVideo && pipe->stream->adjust.v_total_min > timing->v_total; + + if (!isFreesyncVideo) { + pipes[pipe_cnt].pipe.dest.vblank_nom = + dcn3_14_ip.VBlankNomDefaultUS / (timing->h_total / (timing->pix_clk_100hz / 10000.0)); + } else { + pipes[pipe_cnt].pipe.dest.vtotal = pipe->stream->adjust.v_total_min; + pipes[pipe_cnt].pipe.dest.vblank_nom = timing->v_total - pipes[pipe_cnt].pipe.dest.vactive; + } if (pipe->plane_state && (pipe->plane_state->src_rect.height < pipe->plane_state->dst_rect.height ||

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] PM: sleep: wakeirq: fix wake irq arming" 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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x 8527beb12087238d4387607597b4020bc393c4b4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080148-footman-giggly-b733@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: 8527beb12087 ("PM: sleep: wakeirq: fix wake irq arming") 259714100d98 ("PM / wakeirq: support enabling wake-up irq after runtime_suspend called") 69728051f5bf ("PM / wakeirq: Fix unbalanced IRQ enable for wakeirq") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8527beb12087238d4387607597b4020bc393c4b4 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Thu, 13 Jul 2023 16:57:39 +0200 Subject: [PATCH] PM: sleep: wakeirq: fix wake irq arming The decision whether to enable a wake irq during suspend can not be done based on the runtime PM state directly as a driver may use wake irqs without implementing runtime PM. Such drivers specifically leave the state set to the default 'suspended' and the wake irq is thus never enabled at suspend. Add a new wake irq flag to track whether a dedicated wake irq has been enabled at runtime suspend and therefore must not be enabled at system suspend. Note that pm_runtime_enabled() can not be used as runtime PM is always disabled during late suspend. Fixes: 69728051f5bf ("PM / wakeirq: Fix unbalanced IRQ enable for wakeirq") Cc: 4.16+ <stable(a)vger.kernel.org> # 4.16+ Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Tony Lindgren <tony(a)atomide.com> Tested-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> diff --git a/drivers/base/power/power.h b/drivers/base/power/power.h index 0eb7f02b3ad5..922ed457db19 100644 --- a/drivers/base/power/power.h +++ b/drivers/base/power/power.h @@ -29,6 +29,7 @@ extern u64 pm_runtime_active_time(struct device *dev); #define WAKE_IRQ_DEDICATED_MASK (WAKE_IRQ_DEDICATED_ALLOCATED | \ WAKE_IRQ_DEDICATED_MANAGED | \ WAKE_IRQ_DEDICATED_REVERSE) +#define WAKE_IRQ_DEDICATED_ENABLED BIT(3) struct wake_irq { struct device *dev; diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c index d487a6bac630..afd094dec5ca 100644 --- a/drivers/base/power/wakeirq.c +++ b/drivers/base/power/wakeirq.c @@ -314,8 +314,10 @@ void dev_pm_enable_wake_irq_check(struct device *dev, return; enable: - if (!can_change_status || !(wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) + if (!can_change_status || !(wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) { enable_irq(wirq->irq); + wirq->status |= WAKE_IRQ_DEDICATED_ENABLED; + } } /** @@ -336,8 +338,10 @@ void dev_pm_disable_wake_irq_check(struct device *dev, bool cond_disable) if (cond_disable && (wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) return; - if (wirq->status & WAKE_IRQ_DEDICATED_MANAGED) + if (wirq->status & WAKE_IRQ_DEDICATED_MANAGED) { + wirq->status &= ~WAKE_IRQ_DEDICATED_ENABLED; disable_irq_nosync(wirq->irq); + } } /** @@ -376,7 +380,7 @@ void dev_pm_arm_wake_irq(struct wake_irq *wirq) if (device_may_wakeup(wirq->dev)) { if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED && - !pm_runtime_status_suspended(wirq->dev)) + !(wirq->status & WAKE_IRQ_DEDICATED_ENABLED)) enable_irq(wirq->irq); enable_irq_wake(wirq->irq); @@ -399,7 +403,7 @@ void dev_pm_disarm_wake_irq(struct wake_irq *wirq) disable_irq_wake(wirq->irq); if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED && - !pm_runtime_status_suspended(wirq->dev)) + !(wirq->status & WAKE_IRQ_DEDICATED_ENABLED)) disable_irq_nosync(wirq->irq); } }

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] PM: sleep: wakeirq: fix wake irq arming" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 8527beb12087238d4387607597b4020bc393c4b4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080147-enclose-senate-c22b@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 8527beb12087 ("PM: sleep: wakeirq: fix wake irq arming") 259714100d98 ("PM / wakeirq: support enabling wake-up irq after runtime_suspend called") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8527beb12087238d4387607597b4020bc393c4b4 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Thu, 13 Jul 2023 16:57:39 +0200 Subject: [PATCH] PM: sleep: wakeirq: fix wake irq arming The decision whether to enable a wake irq during suspend can not be done based on the runtime PM state directly as a driver may use wake irqs without implementing runtime PM. Such drivers specifically leave the state set to the default 'suspended' and the wake irq is thus never enabled at suspend. Add a new wake irq flag to track whether a dedicated wake irq has been enabled at runtime suspend and therefore must not be enabled at system suspend. Note that pm_runtime_enabled() can not be used as runtime PM is always disabled during late suspend. Fixes: 69728051f5bf ("PM / wakeirq: Fix unbalanced IRQ enable for wakeirq") Cc: 4.16+ <stable(a)vger.kernel.org> # 4.16+ Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Tony Lindgren <tony(a)atomide.com> Tested-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> diff --git a/drivers/base/power/power.h b/drivers/base/power/power.h index 0eb7f02b3ad5..922ed457db19 100644 --- a/drivers/base/power/power.h +++ b/drivers/base/power/power.h @@ -29,6 +29,7 @@ extern u64 pm_runtime_active_time(struct device *dev); #define WAKE_IRQ_DEDICATED_MASK (WAKE_IRQ_DEDICATED_ALLOCATED | \ WAKE_IRQ_DEDICATED_MANAGED | \ WAKE_IRQ_DEDICATED_REVERSE) +#define WAKE_IRQ_DEDICATED_ENABLED BIT(3) struct wake_irq { struct device *dev; diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c index d487a6bac630..afd094dec5ca 100644 --- a/drivers/base/power/wakeirq.c +++ b/drivers/base/power/wakeirq.c @@ -314,8 +314,10 @@ void dev_pm_enable_wake_irq_check(struct device *dev, return; enable: - if (!can_change_status || !(wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) + if (!can_change_status || !(wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) { enable_irq(wirq->irq); + wirq->status |= WAKE_IRQ_DEDICATED_ENABLED; + } } /** @@ -336,8 +338,10 @@ void dev_pm_disable_wake_irq_check(struct device *dev, bool cond_disable) if (cond_disable && (wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) return; - if (wirq->status & WAKE_IRQ_DEDICATED_MANAGED) + if (wirq->status & WAKE_IRQ_DEDICATED_MANAGED) { + wirq->status &= ~WAKE_IRQ_DEDICATED_ENABLED; disable_irq_nosync(wirq->irq); + } } /** @@ -376,7 +380,7 @@ void dev_pm_arm_wake_irq(struct wake_irq *wirq) if (device_may_wakeup(wirq->dev)) { if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED && - !pm_runtime_status_suspended(wirq->dev)) + !(wirq->status & WAKE_IRQ_DEDICATED_ENABLED)) enable_irq(wirq->irq); enable_irq_wake(wirq->irq); @@ -399,7 +403,7 @@ void dev_pm_disarm_wake_irq(struct wake_irq *wirq) disable_irq_wake(wirq->irq); if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED && - !pm_runtime_status_suspended(wirq->dev)) + !(wirq->status & WAKE_IRQ_DEDICATED_ENABLED)) disable_irq_nosync(wirq->irq); } }

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] PM: sleep: wakeirq: fix wake irq arming" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 8527beb12087238d4387607597b4020bc393c4b4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080146-gallows-railroad-57e4@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 8527beb12087 ("PM: sleep: wakeirq: fix wake irq arming") 259714100d98 ("PM / wakeirq: support enabling wake-up irq after runtime_suspend called") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8527beb12087238d4387607597b4020bc393c4b4 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Thu, 13 Jul 2023 16:57:39 +0200 Subject: [PATCH] PM: sleep: wakeirq: fix wake irq arming The decision whether to enable a wake irq during suspend can not be done based on the runtime PM state directly as a driver may use wake irqs without implementing runtime PM. Such drivers specifically leave the state set to the default 'suspended' and the wake irq is thus never enabled at suspend. Add a new wake irq flag to track whether a dedicated wake irq has been enabled at runtime suspend and therefore must not be enabled at system suspend. Note that pm_runtime_enabled() can not be used as runtime PM is always disabled during late suspend. Fixes: 69728051f5bf ("PM / wakeirq: Fix unbalanced IRQ enable for wakeirq") Cc: 4.16+ <stable(a)vger.kernel.org> # 4.16+ Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Tony Lindgren <tony(a)atomide.com> Tested-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> diff --git a/drivers/base/power/power.h b/drivers/base/power/power.h index 0eb7f02b3ad5..922ed457db19 100644 --- a/drivers/base/power/power.h +++ b/drivers/base/power/power.h @@ -29,6 +29,7 @@ extern u64 pm_runtime_active_time(struct device *dev); #define WAKE_IRQ_DEDICATED_MASK (WAKE_IRQ_DEDICATED_ALLOCATED | \ WAKE_IRQ_DEDICATED_MANAGED | \ WAKE_IRQ_DEDICATED_REVERSE) +#define WAKE_IRQ_DEDICATED_ENABLED BIT(3) struct wake_irq { struct device *dev; diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c index d487a6bac630..afd094dec5ca 100644 --- a/drivers/base/power/wakeirq.c +++ b/drivers/base/power/wakeirq.c @@ -314,8 +314,10 @@ void dev_pm_enable_wake_irq_check(struct device *dev, return; enable: - if (!can_change_status || !(wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) + if (!can_change_status || !(wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) { enable_irq(wirq->irq); + wirq->status |= WAKE_IRQ_DEDICATED_ENABLED; + } } /** @@ -336,8 +338,10 @@ void dev_pm_disable_wake_irq_check(struct device *dev, bool cond_disable) if (cond_disable && (wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) return; - if (wirq->status & WAKE_IRQ_DEDICATED_MANAGED) + if (wirq->status & WAKE_IRQ_DEDICATED_MANAGED) { + wirq->status &= ~WAKE_IRQ_DEDICATED_ENABLED; disable_irq_nosync(wirq->irq); + } } /** @@ -376,7 +380,7 @@ void dev_pm_arm_wake_irq(struct wake_irq *wirq) if (device_may_wakeup(wirq->dev)) { if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED && - !pm_runtime_status_suspended(wirq->dev)) + !(wirq->status & WAKE_IRQ_DEDICATED_ENABLED)) enable_irq(wirq->irq); enable_irq_wake(wirq->irq); @@ -399,7 +403,7 @@ void dev_pm_disarm_wake_irq(struct wake_irq *wirq) disable_irq_wake(wirq->irq); if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED && - !pm_runtime_status_suspended(wirq->dev)) + !(wirq->status & WAKE_IRQ_DEDICATED_ENABLED)) disable_irq_nosync(wirq->irq); } }

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] PM: sleep: wakeirq: fix wake irq arming" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 8527beb12087238d4387607597b4020bc393c4b4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080144-trolling-shifter-1ed1@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 8527beb12087 ("PM: sleep: wakeirq: fix wake irq arming") 259714100d98 ("PM / wakeirq: support enabling wake-up irq after runtime_suspend called") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8527beb12087238d4387607597b4020bc393c4b4 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Thu, 13 Jul 2023 16:57:39 +0200 Subject: [PATCH] PM: sleep: wakeirq: fix wake irq arming The decision whether to enable a wake irq during suspend can not be done based on the runtime PM state directly as a driver may use wake irqs without implementing runtime PM. Such drivers specifically leave the state set to the default 'suspended' and the wake irq is thus never enabled at suspend. Add a new wake irq flag to track whether a dedicated wake irq has been enabled at runtime suspend and therefore must not be enabled at system suspend. Note that pm_runtime_enabled() can not be used as runtime PM is always disabled during late suspend. Fixes: 69728051f5bf ("PM / wakeirq: Fix unbalanced IRQ enable for wakeirq") Cc: 4.16+ <stable(a)vger.kernel.org> # 4.16+ Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Tony Lindgren <tony(a)atomide.com> Tested-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> diff --git a/drivers/base/power/power.h b/drivers/base/power/power.h index 0eb7f02b3ad5..922ed457db19 100644 --- a/drivers/base/power/power.h +++ b/drivers/base/power/power.h @@ -29,6 +29,7 @@ extern u64 pm_runtime_active_time(struct device *dev); #define WAKE_IRQ_DEDICATED_MASK (WAKE_IRQ_DEDICATED_ALLOCATED | \ WAKE_IRQ_DEDICATED_MANAGED | \ WAKE_IRQ_DEDICATED_REVERSE) +#define WAKE_IRQ_DEDICATED_ENABLED BIT(3) struct wake_irq { struct device *dev; diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c index d487a6bac630..afd094dec5ca 100644 --- a/drivers/base/power/wakeirq.c +++ b/drivers/base/power/wakeirq.c @@ -314,8 +314,10 @@ void dev_pm_enable_wake_irq_check(struct device *dev, return; enable: - if (!can_change_status || !(wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) + if (!can_change_status || !(wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) { enable_irq(wirq->irq); + wirq->status |= WAKE_IRQ_DEDICATED_ENABLED; + } } /** @@ -336,8 +338,10 @@ void dev_pm_disable_wake_irq_check(struct device *dev, bool cond_disable) if (cond_disable && (wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) return; - if (wirq->status & WAKE_IRQ_DEDICATED_MANAGED) + if (wirq->status & WAKE_IRQ_DEDICATED_MANAGED) { + wirq->status &= ~WAKE_IRQ_DEDICATED_ENABLED; disable_irq_nosync(wirq->irq); + } } /** @@ -376,7 +380,7 @@ void dev_pm_arm_wake_irq(struct wake_irq *wirq) if (device_may_wakeup(wirq->dev)) { if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED && - !pm_runtime_status_suspended(wirq->dev)) + !(wirq->status & WAKE_IRQ_DEDICATED_ENABLED)) enable_irq(wirq->irq); enable_irq_wake(wirq->irq); @@ -399,7 +403,7 @@ void dev_pm_disarm_wake_irq(struct wake_irq *wirq) disable_irq_wake(wirq->irq); if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED && - !pm_runtime_status_suspended(wirq->dev)) + !(wirq->status & WAKE_IRQ_DEDICATED_ENABLED)) disable_irq_nosync(wirq->irq); } }

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] PM: sleep: wakeirq: fix wake irq arming" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 8527beb12087238d4387607597b4020bc393c4b4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080143-spry-emptier-f572@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 8527beb12087 ("PM: sleep: wakeirq: fix wake irq arming") 259714100d98 ("PM / wakeirq: support enabling wake-up irq after runtime_suspend called") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8527beb12087238d4387607597b4020bc393c4b4 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Thu, 13 Jul 2023 16:57:39 +0200 Subject: [PATCH] PM: sleep: wakeirq: fix wake irq arming The decision whether to enable a wake irq during suspend can not be done based on the runtime PM state directly as a driver may use wake irqs without implementing runtime PM. Such drivers specifically leave the state set to the default 'suspended' and the wake irq is thus never enabled at suspend. Add a new wake irq flag to track whether a dedicated wake irq has been enabled at runtime suspend and therefore must not be enabled at system suspend. Note that pm_runtime_enabled() can not be used as runtime PM is always disabled during late suspend. Fixes: 69728051f5bf ("PM / wakeirq: Fix unbalanced IRQ enable for wakeirq") Cc: 4.16+ <stable(a)vger.kernel.org> # 4.16+ Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Tony Lindgren <tony(a)atomide.com> Tested-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> diff --git a/drivers/base/power/power.h b/drivers/base/power/power.h index 0eb7f02b3ad5..922ed457db19 100644 --- a/drivers/base/power/power.h +++ b/drivers/base/power/power.h @@ -29,6 +29,7 @@ extern u64 pm_runtime_active_time(struct device *dev); #define WAKE_IRQ_DEDICATED_MASK (WAKE_IRQ_DEDICATED_ALLOCATED | \ WAKE_IRQ_DEDICATED_MANAGED | \ WAKE_IRQ_DEDICATED_REVERSE) +#define WAKE_IRQ_DEDICATED_ENABLED BIT(3) struct wake_irq { struct device *dev; diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c index d487a6bac630..afd094dec5ca 100644 --- a/drivers/base/power/wakeirq.c +++ b/drivers/base/power/wakeirq.c @@ -314,8 +314,10 @@ void dev_pm_enable_wake_irq_check(struct device *dev, return; enable: - if (!can_change_status || !(wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) + if (!can_change_status || !(wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) { enable_irq(wirq->irq); + wirq->status |= WAKE_IRQ_DEDICATED_ENABLED; + } } /** @@ -336,8 +338,10 @@ void dev_pm_disable_wake_irq_check(struct device *dev, bool cond_disable) if (cond_disable && (wirq->status & WAKE_IRQ_DEDICATED_REVERSE)) return; - if (wirq->status & WAKE_IRQ_DEDICATED_MANAGED) + if (wirq->status & WAKE_IRQ_DEDICATED_MANAGED) { + wirq->status &= ~WAKE_IRQ_DEDICATED_ENABLED; disable_irq_nosync(wirq->irq); + } } /** @@ -376,7 +380,7 @@ void dev_pm_arm_wake_irq(struct wake_irq *wirq) if (device_may_wakeup(wirq->dev)) { if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED && - !pm_runtime_status_suspended(wirq->dev)) + !(wirq->status & WAKE_IRQ_DEDICATED_ENABLED)) enable_irq(wirq->irq); enable_irq_wake(wirq->irq); @@ -399,7 +403,7 @@ void dev_pm_disarm_wake_irq(struct wake_irq *wirq) disable_irq_wake(wirq->irq); if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED && - !pm_runtime_status_suspended(wirq->dev)) + !(wirq->status & WAKE_IRQ_DEDICATED_ENABLED)) disable_irq_nosync(wirq->irq); } }

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] soundwire: fix enumeration completion" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x c40d6b3249b11d60e09d81530588f56233d9aa44 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080128-durably-grading-2e25@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: c40d6b3249b1 ("soundwire: fix enumeration completion") e557bca49b81 ("soundwire: bus: pm_runtime_request_resume on peripheral attachment") f1b690261247 ("soundwire: bus: add better dev_dbg to track complete() calls") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From c40d6b3249b11d60e09d81530588f56233d9aa44 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Wed, 5 Jul 2023 14:30:11 +0200 Subject: [PATCH] soundwire: fix enumeration completion The soundwire subsystem uses two completion structures that allow drivers to wait for soundwire device to become enumerated on the bus and initialised by their drivers, respectively. The code implementing the signalling is currently broken as it does not signal all current and future waiters and also uses the wrong reinitialisation function, which can potentially lead to memory corruption if there are still waiters on the queue. Not signalling future waiters specifically breaks sound card probe deferrals as codec drivers can not tell that the soundwire device is already attached when being reprobed. Some codec runtime PM implementations suffer from similar problems as waiting for enumeration during resume can also timeout despite the device already having been enumerated. Fixes: fb9469e54fa7 ("soundwire: bus: fix race condition with enumeration_complete signaling") Fixes: a90def068127 ("soundwire: bus: fix race condition with initialization_complete signaling") Cc: stable(a)vger.kernel.org # 5.7 Cc: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Cc: Rander Wang <rander.wang(a)linux.intel.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20230705123018.30903-2-johan+linaro@kernel.org Signed-off-by: Vinod Koul <vkoul(a)kernel.org> diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index dba920ec88f6..cf78839b3f74 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -922,8 +922,8 @@ static void sdw_modify_slave_status(struct sdw_slave *slave, "initializing enumeration and init completion for Slave %d\n", slave->dev_num); - init_completion(&slave->enumeration_complete); - init_completion(&slave->initialization_complete); + reinit_completion(&slave->enumeration_complete); + reinit_completion(&slave->initialization_complete); } else if ((status == SDW_SLAVE_ATTACHED) && (slave->status == SDW_SLAVE_UNATTACHED)) { @@ -931,7 +931,7 @@ static void sdw_modify_slave_status(struct sdw_slave *slave, "signaling enumeration completion for Slave %d\n", slave->dev_num); - complete(&slave->enumeration_complete); + complete_all(&slave->enumeration_complete); } slave->status = status; mutex_unlock(&bus->bus_lock); @@ -1951,7 +1951,7 @@ int sdw_handle_slave_status(struct sdw_bus *bus, "signaling initialization completion for Slave %d\n", slave->dev_num); - complete(&slave->initialization_complete); + complete_all(&slave->initialization_complete); /* * If the manager became pm_runtime active, the peripherals will be

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] soundwire: fix enumeration completion" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x c40d6b3249b11d60e09d81530588f56233d9aa44 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080127-unquote-heaviness-e2c5@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: c40d6b3249b1 ("soundwire: fix enumeration completion") e557bca49b81 ("soundwire: bus: pm_runtime_request_resume on peripheral attachment") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From c40d6b3249b11d60e09d81530588f56233d9aa44 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Wed, 5 Jul 2023 14:30:11 +0200 Subject: [PATCH] soundwire: fix enumeration completion The soundwire subsystem uses two completion structures that allow drivers to wait for soundwire device to become enumerated on the bus and initialised by their drivers, respectively. The code implementing the signalling is currently broken as it does not signal all current and future waiters and also uses the wrong reinitialisation function, which can potentially lead to memory corruption if there are still waiters on the queue. Not signalling future waiters specifically breaks sound card probe deferrals as codec drivers can not tell that the soundwire device is already attached when being reprobed. Some codec runtime PM implementations suffer from similar problems as waiting for enumeration during resume can also timeout despite the device already having been enumerated. Fixes: fb9469e54fa7 ("soundwire: bus: fix race condition with enumeration_complete signaling") Fixes: a90def068127 ("soundwire: bus: fix race condition with initialization_complete signaling") Cc: stable(a)vger.kernel.org # 5.7 Cc: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Cc: Rander Wang <rander.wang(a)linux.intel.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20230705123018.30903-2-johan+linaro@kernel.org Signed-off-by: Vinod Koul <vkoul(a)kernel.org> diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index dba920ec88f6..cf78839b3f74 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -922,8 +922,8 @@ static void sdw_modify_slave_status(struct sdw_slave *slave, "initializing enumeration and init completion for Slave %d\n", slave->dev_num); - init_completion(&slave->enumeration_complete); - init_completion(&slave->initialization_complete); + reinit_completion(&slave->enumeration_complete); + reinit_completion(&slave->initialization_complete); } else if ((status == SDW_SLAVE_ATTACHED) && (slave->status == SDW_SLAVE_UNATTACHED)) { @@ -931,7 +931,7 @@ static void sdw_modify_slave_status(struct sdw_slave *slave, "signaling enumeration completion for Slave %d\n", slave->dev_num); - complete(&slave->enumeration_complete); + complete_all(&slave->enumeration_complete); } slave->status = status; mutex_unlock(&bus->bus_lock); @@ -1951,7 +1951,7 @@ int sdw_handle_slave_status(struct sdw_bus *bus, "signaling initialization completion for Slave %d\n", slave->dev_num); - complete(&slave->initialization_complete); + complete_all(&slave->initialization_complete); /* * If the manager became pm_runtime active, the peripherals will be

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] selftests/rseq: Play nice with binaries statically linked" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 3bcbc20942db5d738221cca31a928efc09827069 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080154-ageless-blooper-418e@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 3bcbc20942db ("selftests/rseq: Play nice with binaries statically linked against glibc 2.35+") d1a997ba4c1b ("selftests/rseq: check if libc rseq support is registered") 889c5d60fbcf ("selftests/rseq: Change type of rseq_offset to ptrdiff_t") 4e15bb766b6c ("selftests/rseq: x86-64: use %fs segment selector for accessing rseq thread area") 233e667e1ae3 ("selftests/rseq: Uplift rseq selftests for compatibility with glibc-2.35") e546cd48ccc4 ("selftests/rseq: Introduce rseq_get_abi() helper") 94b80a19ebfe ("selftests/rseq: Remove volatile from __rseq_abi") 5c105d55a9dc ("selftests/rseq: introduce own copy of rseq uapi header") 07ad4f7629d4 ("selftests/rseq: remove ARRAY_SIZE define from individual tests") ea366dd79c05 ("rseq/selftests,x86_64: Add rseq_offset_deref_addv()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3bcbc20942db5d738221cca31a928efc09827069 Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc(a)google.com> Date: Fri, 21 Jul 2023 15:33:52 -0700 Subject: [PATCH] selftests/rseq: Play nice with binaries statically linked against glibc 2.35+ To allow running rseq and KVM's rseq selftests as statically linked binaries, initialize the various "trampoline" pointers to point directly at the expect glibc symbols, and skip the dlysm() lookups if the rseq size is non-zero, i.e. the binary is statically linked *and* the libc registered its own rseq. Define weak versions of the symbols so as not to break linking against libc versions that don't support rseq in any capacity. The KVM selftests in particular are often statically linked so that they can be run on targets with very limited runtime environments, i.e. test machines. Fixes: 233e667e1ae3 ("selftests/rseq: Uplift rseq selftests for compatibility with glibc-2.35") Cc: Aaron Lewis <aaronlewis(a)google.com> Cc: kvm(a)vger.kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20230721223352.2333911-1-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/tools/testing/selftests/rseq/rseq.c b/tools/testing/selftests/rseq/rseq.c index 4e4aa006004c..a723da253244 100644 --- a/tools/testing/selftests/rseq/rseq.c +++ b/tools/testing/selftests/rseq/rseq.c @@ -34,9 +34,17 @@ #include "../kselftest.h" #include "rseq.h" -static const ptrdiff_t *libc_rseq_offset_p; -static const unsigned int *libc_rseq_size_p; -static const unsigned int *libc_rseq_flags_p; +/* + * Define weak versions to play nice with binaries that are statically linked + * against a libc that doesn't support registering its own rseq. + */ +__weak ptrdiff_t __rseq_offset; +__weak unsigned int __rseq_size; +__weak unsigned int __rseq_flags; + +static const ptrdiff_t *libc_rseq_offset_p = &__rseq_offset; +static const unsigned int *libc_rseq_size_p = &__rseq_size; +static const unsigned int *libc_rseq_flags_p = &__rseq_flags; /* Offset from the thread pointer to the rseq area. */ ptrdiff_t rseq_offset; @@ -155,9 +163,17 @@ unsigned int get_rseq_feature_size(void) static __attribute__((constructor)) void rseq_init(void) { - libc_rseq_offset_p = dlsym(RTLD_NEXT, "__rseq_offset"); - libc_rseq_size_p = dlsym(RTLD_NEXT, "__rseq_size"); - libc_rseq_flags_p = dlsym(RTLD_NEXT, "__rseq_flags"); + /* + * If the libc's registered rseq size isn't already valid, it may be + * because the binary is dynamically linked and not necessarily due to + * libc not having registered a restartable sequence. Try to find the + * symbols if that's the case. + */ + if (!*libc_rseq_size_p) { + libc_rseq_offset_p = dlsym(RTLD_NEXT, "__rseq_offset"); + libc_rseq_size_p = dlsym(RTLD_NEXT, "__rseq_size"); + libc_rseq_flags_p = dlsym(RTLD_NEXT, "__rseq_flags"); + } if (libc_rseq_size_p && libc_rseq_offset_p && libc_rseq_flags_p && *libc_rseq_size_p != 0) { /* rseq registration owned by glibc */

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] selftests/rseq: Play nice with binaries statically linked" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 3bcbc20942db5d738221cca31a928efc09827069 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080153-drivable-stout-f966@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 3bcbc20942db ("selftests/rseq: Play nice with binaries statically linked against glibc 2.35+") d1a997ba4c1b ("selftests/rseq: check if libc rseq support is registered") 889c5d60fbcf ("selftests/rseq: Change type of rseq_offset to ptrdiff_t") 4e15bb766b6c ("selftests/rseq: x86-64: use %fs segment selector for accessing rseq thread area") 233e667e1ae3 ("selftests/rseq: Uplift rseq selftests for compatibility with glibc-2.35") e546cd48ccc4 ("selftests/rseq: Introduce rseq_get_abi() helper") 94b80a19ebfe ("selftests/rseq: Remove volatile from __rseq_abi") 5c105d55a9dc ("selftests/rseq: introduce own copy of rseq uapi header") 07ad4f7629d4 ("selftests/rseq: remove ARRAY_SIZE define from individual tests") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3bcbc20942db5d738221cca31a928efc09827069 Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc(a)google.com> Date: Fri, 21 Jul 2023 15:33:52 -0700 Subject: [PATCH] selftests/rseq: Play nice with binaries statically linked against glibc 2.35+ To allow running rseq and KVM's rseq selftests as statically linked binaries, initialize the various "trampoline" pointers to point directly at the expect glibc symbols, and skip the dlysm() lookups if the rseq size is non-zero, i.e. the binary is statically linked *and* the libc registered its own rseq. Define weak versions of the symbols so as not to break linking against libc versions that don't support rseq in any capacity. The KVM selftests in particular are often statically linked so that they can be run on targets with very limited runtime environments, i.e. test machines. Fixes: 233e667e1ae3 ("selftests/rseq: Uplift rseq selftests for compatibility with glibc-2.35") Cc: Aaron Lewis <aaronlewis(a)google.com> Cc: kvm(a)vger.kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20230721223352.2333911-1-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/tools/testing/selftests/rseq/rseq.c b/tools/testing/selftests/rseq/rseq.c index 4e4aa006004c..a723da253244 100644 --- a/tools/testing/selftests/rseq/rseq.c +++ b/tools/testing/selftests/rseq/rseq.c @@ -34,9 +34,17 @@ #include "../kselftest.h" #include "rseq.h" -static const ptrdiff_t *libc_rseq_offset_p; -static const unsigned int *libc_rseq_size_p; -static const unsigned int *libc_rseq_flags_p; +/* + * Define weak versions to play nice with binaries that are statically linked + * against a libc that doesn't support registering its own rseq. + */ +__weak ptrdiff_t __rseq_offset; +__weak unsigned int __rseq_size; +__weak unsigned int __rseq_flags; + +static const ptrdiff_t *libc_rseq_offset_p = &__rseq_offset; +static const unsigned int *libc_rseq_size_p = &__rseq_size; +static const unsigned int *libc_rseq_flags_p = &__rseq_flags; /* Offset from the thread pointer to the rseq area. */ ptrdiff_t rseq_offset; @@ -155,9 +163,17 @@ unsigned int get_rseq_feature_size(void) static __attribute__((constructor)) void rseq_init(void) { - libc_rseq_offset_p = dlsym(RTLD_NEXT, "__rseq_offset"); - libc_rseq_size_p = dlsym(RTLD_NEXT, "__rseq_size"); - libc_rseq_flags_p = dlsym(RTLD_NEXT, "__rseq_flags"); + /* + * If the libc's registered rseq size isn't already valid, it may be + * because the binary is dynamically linked and not necessarily due to + * libc not having registered a restartable sequence. Try to find the + * symbols if that's the case. + */ + if (!*libc_rseq_size_p) { + libc_rseq_offset_p = dlsym(RTLD_NEXT, "__rseq_offset"); + libc_rseq_size_p = dlsym(RTLD_NEXT, "__rseq_size"); + libc_rseq_flags_p = dlsym(RTLD_NEXT, "__rseq_flags"); + } if (libc_rseq_size_p && libc_rseq_offset_p && libc_rseq_flags_p && *libc_rseq_size_p != 0) { /* rseq registration owned by glibc */

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] selftests/rseq: Play nice with binaries statically linked" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 3bcbc20942db5d738221cca31a928efc09827069 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080147-playset-hydrogen-cc0c@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 3bcbc20942db ("selftests/rseq: Play nice with binaries statically linked against glibc 2.35+") d1a997ba4c1b ("selftests/rseq: check if libc rseq support is registered") 889c5d60fbcf ("selftests/rseq: Change type of rseq_offset to ptrdiff_t") 4e15bb766b6c ("selftests/rseq: x86-64: use %fs segment selector for accessing rseq thread area") 233e667e1ae3 ("selftests/rseq: Uplift rseq selftests for compatibility with glibc-2.35") e546cd48ccc4 ("selftests/rseq: Introduce rseq_get_abi() helper") 94b80a19ebfe ("selftests/rseq: Remove volatile from __rseq_abi") 5c105d55a9dc ("selftests/rseq: introduce own copy of rseq uapi header") 07ad4f7629d4 ("selftests/rseq: remove ARRAY_SIZE define from individual tests") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3bcbc20942db5d738221cca31a928efc09827069 Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc(a)google.com> Date: Fri, 21 Jul 2023 15:33:52 -0700 Subject: [PATCH] selftests/rseq: Play nice with binaries statically linked against glibc 2.35+ To allow running rseq and KVM's rseq selftests as statically linked binaries, initialize the various "trampoline" pointers to point directly at the expect glibc symbols, and skip the dlysm() lookups if the rseq size is non-zero, i.e. the binary is statically linked *and* the libc registered its own rseq. Define weak versions of the symbols so as not to break linking against libc versions that don't support rseq in any capacity. The KVM selftests in particular are often statically linked so that they can be run on targets with very limited runtime environments, i.e. test machines. Fixes: 233e667e1ae3 ("selftests/rseq: Uplift rseq selftests for compatibility with glibc-2.35") Cc: Aaron Lewis <aaronlewis(a)google.com> Cc: kvm(a)vger.kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20230721223352.2333911-1-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/tools/testing/selftests/rseq/rseq.c b/tools/testing/selftests/rseq/rseq.c index 4e4aa006004c..a723da253244 100644 --- a/tools/testing/selftests/rseq/rseq.c +++ b/tools/testing/selftests/rseq/rseq.c @@ -34,9 +34,17 @@ #include "../kselftest.h" #include "rseq.h" -static const ptrdiff_t *libc_rseq_offset_p; -static const unsigned int *libc_rseq_size_p; -static const unsigned int *libc_rseq_flags_p; +/* + * Define weak versions to play nice with binaries that are statically linked + * against a libc that doesn't support registering its own rseq. + */ +__weak ptrdiff_t __rseq_offset; +__weak unsigned int __rseq_size; +__weak unsigned int __rseq_flags; + +static const ptrdiff_t *libc_rseq_offset_p = &__rseq_offset; +static const unsigned int *libc_rseq_size_p = &__rseq_size; +static const unsigned int *libc_rseq_flags_p = &__rseq_flags; /* Offset from the thread pointer to the rseq area. */ ptrdiff_t rseq_offset; @@ -155,9 +163,17 @@ unsigned int get_rseq_feature_size(void) static __attribute__((constructor)) void rseq_init(void) { - libc_rseq_offset_p = dlsym(RTLD_NEXT, "__rseq_offset"); - libc_rseq_size_p = dlsym(RTLD_NEXT, "__rseq_size"); - libc_rseq_flags_p = dlsym(RTLD_NEXT, "__rseq_flags"); + /* + * If the libc's registered rseq size isn't already valid, it may be + * because the binary is dynamically linked and not necessarily due to + * libc not having registered a restartable sequence. Try to find the + * symbols if that's the case. + */ + if (!*libc_rseq_size_p) { + libc_rseq_offset_p = dlsym(RTLD_NEXT, "__rseq_offset"); + libc_rseq_size_p = dlsym(RTLD_NEXT, "__rseq_size"); + libc_rseq_flags_p = dlsym(RTLD_NEXT, "__rseq_flags"); + } if (libc_rseq_size_p && libc_rseq_offset_p && libc_rseq_flags_p && *libc_rseq_size_p != 0) { /* rseq registration owned by glibc */

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] io_uring: gate iowait schedule on having pending requests" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 7b72d661f1f2f950ab8c12de7e2bc48bdac8ed69 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080156-easeful-driller-8a26@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 7b72d661f1f2 ("io_uring: gate iowait schedule on having pending requests") 8a796565cec3 ("io_uring: Use io_schedule* in cqring wait") d33a39e57768 ("io_uring: keep timeout in io_wait_queue") 46ae7eef44f6 ("io_uring: optimise non-timeout waiting") 846072f16eed ("io_uring: mimimise io_cqring_wait_schedule") 3fcf19d592d5 ("io_uring: parse check_cq out of wq waiting") 12521a5d5cb7 ("io_uring: fix CQ waiting timeout handling") 52ea806ad983 ("io_uring: finish waiting before flushing overflow entries") 35d90f95cfa7 ("io_uring: include task_work run after scheduling in wait for events") 1b346e4aa8e7 ("io_uring: don't check overflow flush failures") a85381d8326d ("io_uring: skip overflow CQE posting for dying ring") c0e0d6ba25f1 ("io_uring: add IORING_SETUP_DEFER_TASKRUN") b4c98d59a787 ("io_uring: introduce io_has_work") 78a861b94959 ("io_uring: add sync cancelation API through io_uring_register()") c34398a8c018 ("io_uring: remove __io_req_task_work_add") ed5ccb3beeba ("io_uring: remove priority tw list optimisation") 4a0fef62788b ("io_uring: optimize io_uring_task layout") 253993210bd8 ("io_uring: introduce locking helpers for CQE posting") 305bef988708 ("io_uring: hide eventfd assumptions in eventfd paths") affa87db9010 ("io_uring: fix multi ctx cancellation") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7b72d661f1f2f950ab8c12de7e2bc48bdac8ed69 Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Mon, 24 Jul 2023 11:28:17 -0600 Subject: [PATCH] io_uring: gate iowait schedule on having pending requests A previous commit made all cqring waits marked as iowait, as a way to improve performance for short schedules with pending IO. However, for use cases that have a special reaper thread that does nothing but wait on events on the ring, this causes a cosmetic issue where we know have one core marked as being "busy" with 100% iowait. While this isn't a grave issue, it is confusing to users. Rather than always mark us as being in iowait, gate setting of current->in_iowait to 1 by whether or not the waiting task has pending requests. Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/io-uring/CAMEGJJ2RxopfNQ7GNLhr7X9=bHXKo+G5OOe0LUq=+… Link: https://bugzilla.kernel.org/show_bug.cgi?id=217699 Link: https://bugzilla.kernel.org/show_bug.cgi?id=217700 Reported-by: Oleksandr Natalenko <oleksandr(a)natalenko.name> Reported-by: Phil Elwell <phil(a)raspberrypi.com> Tested-by: Andres Freund <andres(a)anarazel.de> Fixes: 8a796565cec3 ("io_uring: Use io_schedule* in cqring wait") Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c index 89a611541bc4..f4591b912ea8 100644 --- a/io_uring/io_uring.c +++ b/io_uring/io_uring.c @@ -2493,11 +2493,20 @@ int io_run_task_work_sig(struct io_ring_ctx *ctx) return 0; } +static bool current_pending_io(void) +{ + struct io_uring_task *tctx = current->io_uring; + + if (!tctx) + return false; + return percpu_counter_read_positive(&tctx->inflight); +} + /* when returns >0, the caller should retry */ static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx, struct io_wait_queue *iowq) { - int token, ret; + int io_wait, ret; if (unlikely(READ_ONCE(ctx->check_cq))) return 1; @@ -2511,17 +2520,19 @@ static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx, return 0; /* - * Use io_schedule_prepare/finish, so cpufreq can take into account - * that the task is waiting for IO - turns out to be important for low - * QD IO. + * Mark us as being in io_wait if we have pending requests, so cpufreq + * can take into account that the task is waiting for IO - turns out + * to be important for low QD IO. */ - token = io_schedule_prepare(); + io_wait = current->in_iowait; + if (current_pending_io()) + current->in_iowait = 1; ret = 0; if (iowq->timeout == KTIME_MAX) schedule(); else if (!schedule_hrtimeout(&iowq->timeout, HRTIMER_MODE_ABS)) ret = -ETIME; - io_schedule_finish(token); + current->in_iowait = io_wait; return ret; }

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] net: ipa: only reset hashed tables when supported" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x e11ec2b868af2b351c6c1e2e50eb711cc5423a10 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080110-landscape-probiotic-1f99@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: e11ec2b868af ("net: ipa: only reset hashed tables when supported") 6337b147828b ("net: ipa: use ipa_table_mem() in ipa_table_reset_add()") 8defab8bdfb1 ("net: ipa: don't assume 8 modem routing table entries") 0439e6743c5c ("net: ipa: determine route table size from memory region") fc094058ce01 ("net: ipa: record the route table size in the IPA structure") 73da9cac517c ("net: ipa: check table memory regions earlier") 5444b0ea9915 ("net: ipa: verify table sizes fit in commands early") cf13919654d5 ("net: ipa: validate IPA table memory earlier") fb4014ac76b8 ("net: ipa: kill two constant symbols") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e11ec2b868af2b351c6c1e2e50eb711cc5423a10 Mon Sep 17 00:00:00 2001 From: Alex Elder <elder(a)linaro.org> Date: Mon, 24 Jul 2023 17:40:55 -0500 Subject: [PATCH] net: ipa: only reset hashed tables when supported Last year, the code that manages GSI channel transactions switched from using spinlock-protected linked lists to using indexes into the ring buffer used for a channel. Recently, Google reported seeing transaction reference count underflows occasionally during shutdown. Doug Anderson found a way to reproduce the issue reliably, and bisected the issue to the commit that eliminated the linked lists and the lock. The root cause was ultimately determined to be related to unused transactions being committed as part of the modem shutdown cleanup activity. Unused transactions are not normally expected (except in error cases). The modem uses some ranges of IPA-resident memory, and whenever it shuts down we zero those ranges. In ipa_filter_reset_table() a transaction is allocated to zero modem filter table entries. If hashing is not supported, hashed table memory should not be zeroed. But currently nothing prevents that, and the result is an unused transaction. Something similar occurs when we zero routing table entries for the modem. By preventing any attempt to clear hashed tables when hashing is not supported, the reference count underflow is avoided in this case. Note that there likely remains an issue with properly freeing unused transactions (if they occur due to errors). This patch addresses only the underflows that Google originally reported. Cc: <stable(a)vger.kernel.org> # 6.1.x Fixes: d338ae28d8a8 ("net: ipa: kill all other transaction lists") Tested-by: Douglas Anderson <dianders(a)chromium.org> Signed-off-by: Alex Elder <elder(a)linaro.org> Link: https://lore.kernel.org/r/20230724224055.1688854-1-elder@linaro.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/drivers/net/ipa/ipa_table.c b/drivers/net/ipa/ipa_table.c index f0529c31d0b6..7b637bb8b41c 100644 --- a/drivers/net/ipa/ipa_table.c +++ b/drivers/net/ipa/ipa_table.c @@ -273,16 +273,15 @@ static int ipa_filter_reset(struct ipa *ipa, bool modem) if (ret) return ret; + ret = ipa_filter_reset_table(ipa, false, true, modem); + if (ret || !ipa_table_hash_support(ipa)) + return ret; + ret = ipa_filter_reset_table(ipa, true, false, modem); if (ret) return ret; - ret = ipa_filter_reset_table(ipa, false, true, modem); - if (ret) - return ret; - ret = ipa_filter_reset_table(ipa, true, true, modem); - - return ret; + return ipa_filter_reset_table(ipa, true, true, modem); } /* The AP routes and modem routes are each contiguous within the @@ -291,12 +290,13 @@ static int ipa_filter_reset(struct ipa *ipa, bool modem) * */ static int ipa_route_reset(struct ipa *ipa, bool modem) { + bool hash_support = ipa_table_hash_support(ipa); u32 modem_route_count = ipa->modem_route_count; struct gsi_trans *trans; u16 first; u16 count; - trans = ipa_cmd_trans_alloc(ipa, 4); + trans = ipa_cmd_trans_alloc(ipa, hash_support ? 4 : 2); if (!trans) { dev_err(&ipa->pdev->dev, "no transaction for %s route reset\n", @@ -313,10 +313,12 @@ static int ipa_route_reset(struct ipa *ipa, bool modem) } ipa_table_reset_add(trans, false, false, false, first, count); - ipa_table_reset_add(trans, false, true, false, first, count); - ipa_table_reset_add(trans, false, false, true, first, count); - ipa_table_reset_add(trans, false, true, true, first, count); + + if (hash_support) { + ipa_table_reset_add(trans, false, true, false, first, count); + ipa_table_reset_add(trans, false, true, true, first, count); + } gsi_trans_commit_wait(trans);

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] virtio-net: fix race between set queues and probe" 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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x 25266128fe16d5632d43ada34c847d7b8daba539 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023080152-roundish-doornail-415a@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: 25266128fe16 ("virtio-net: fix race between set queues and probe") 50c0ada627f5 ("virtio-net: fix race between ndo_open() and virtio_device_ready()") c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.") a02e8964eaf9 ("virtio-net: ethtool configurable LRO") 0c465be183c7 ("virtio_net: ethtool tx napi configuration") ba5e4426e80e ("virtio_net: Extend virtio to use VF datapath when available") 9805069d14c1 ("virtio_net: Introduce VIRTIO_NET_F_STANDBY feature bit") cfc80d9a1163 ("net: Introduce net_failover driver") f4ee703ace84 ("virtio_net: sparse annotation fix") d7fad4c840f3 ("virtio_net: fix adding vids on big-endian") 12e571693837 ("virtio_net: split out ctrl buffer") faa9b39f0e9d ("virtio_net: propagate linkspeed/duplex settings from the hypervisor") 754b8a21a96d ("virtio_net: setup xdp_rxq_info") 83c9e13aa39a ("netdevsim: add software driver for testing offloads") e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") 186b3c998c50 ("virtio-net: support XDP_REDIRECT") 312403453532 ("virtio-net: add packet len average only when needed during XDP") 9457642a405f ("virtio-net: remove unnecessary parameter of virtnet_xdp_xmit()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 25266128fe16d5632d43ada34c847d7b8daba539 Mon Sep 17 00:00:00 2001 From: Jason Wang <jasowang(a)redhat.com> Date: Tue, 25 Jul 2023 03:20:49 -0400 Subject: [PATCH] virtio-net: fix race between set queues and probe A race were found where set_channels could be called after registering but before virtnet_set_queues() in virtnet_probe(). Fixing this by moving the virtnet_set_queues() before netdevice registering. While at it, use _virtnet_set_queues() to avoid holding rtnl as the device is not even registered at that time. Cc: stable(a)vger.kernel.org Fixes: a220871be66f ("virtio-net: correctly enable multiqueue") Signed-off-by: Jason Wang <jasowang(a)redhat.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Reviewed-by: Xuan Zhuo <xuanzhuo(a)linux.alibaba.com> Link: https://lore.kernel.org/r/20230725072049.617289-1-jasowang@redhat.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 0db14f6b87d3..1270c8d23463 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -4219,6 +4219,8 @@ static int virtnet_probe(struct virtio_device *vdev) if (vi->has_rss || vi->has_rss_hash_report) virtnet_init_default_rss(vi); + _virtnet_set_queues(vi, vi->curr_queue_pairs); + /* serialize netdev register + virtio_device_ready() with ndo_open() */ rtnl_lock(); @@ -4257,8 +4259,6 @@ static int virtnet_probe(struct virtio_device *vdev) goto free_unregister_netdev; } - virtnet_set_queues(vi, vi->curr_queue_pairs); - /* Assume link up if device can't report link status, otherwise get link status from config. */ netif_carrier_off(dev);

2 years, 2 months

1
0
0 0

[PATCH 1/4] dmaengine: xilinx: xdma: Fix interrupt vector setting

by Miquel Raynal

A couple of hardware registers need to be set to reflect which interrupts have been allocated to the device. Each register is 32-bit wide and can receive four 8-bit values. If we provide any other interrupt number than four, the irq_num variable will never be 0 within the while check and the while block will loop forever. There is an easy way to prevent this: just break the for loop when we reach "irq_num == 0", which anyway means all interrupts have been processed. Cc: stable(a)vger.kernel.org Fixes: 17ce252266c7 ("dmaengine: xilinx: xdma: Add xilinx xdma driver") Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/dma/xilinx/xdma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma/xilinx/xdma.c b/drivers/dma/xilinx/xdma.c index 93ee298d52b8..359123526dd0 100644 --- a/drivers/dma/xilinx/xdma.c +++ b/drivers/dma/xilinx/xdma.c @@ -668,6 +668,8 @@ static int xdma_set_vector_reg(struct xdma_device *xdev, u32 vec_tbl_start, val |= irq_start << shift; irq_start++; irq_num--; + if (!irq_num) + break; } /* write IRQ register */ -- 2.34.1

2 years, 2 months

2
1
0 0

Re: [PATCH 1/1] tpm: disable hwrng for fTPM on some AMD designs

by Limonciello, Mario

On 7/31/2023 5:53 AM, Jarkko Sakkinen wrote: > On Fri Jul 28, 2023 at 8:41 PM UTC, Linus Torvalds wrote: >> On Thu, 27 Jul 2023 at 10:05, Daniil Stas <daniil.stas(a)posteo.net> wrote: >>> >>> Here is the bug report I created: >>> https://bugzilla.kernel.org/show_bug.cgi?id=217719 >> >> Let's just disable the stupid fTPM hwrnd thing. >> >> Maybe use it for the boot-time "gather entropy from different >> sources", but clearly it should *not* be used at runtime. >> >> Why would anybody use that crud when any machine that has it >> supposedly fixed (which apparently didn't turn out to be true after >> all) would also have the CPU rdrand instruction that doesn't have the >> problem? >> >> If you don't trust the CPU rdrand implementation (and that has had >> bugs too - see clear_rdrand_cpuid_bit() and x86_init_rdrand()), why >> would you trust the fTPM version that has caused even *more* problems? >> >> So I don't see any downside to just saying "that fTPM thing is not >> working". Even if it ends up working in the future, there are >> alternatives that aren't any worse. >> >> Linus > > I quickly carved up a patch (attached), which is only compile tested > because I do not have any AMD hardware at hand. > > BR, Jarkko > I'll get some testing done on this patch with some AMD reference hardware, but off the cuff comments: 1) It needs to target older stable than 6.3 because 6.1-rc1 is when b006c439d58d was introduced and 6.1.19 backported f1324bbc4 as dc64dc4c8. 2) Add a Link tag for [1] 3) The fix for [2] is lost. The one that landed upstream was ecff6813d2bc ("tpm: return false from tpm_amd_is_rng_defective on non-x86 platforms"). I sent another one that checked for chip->ops [3], but this wasn't picked up. [1] https://bugzilla.kernel.org/show_bug.cgi?id=217719 [2] https://lore.kernel.org/lkml/99B81401-DB46-49B9-B321-CF832B50CAC3@linux.ibm… [3] https://lore.kernel.org/lkml/20230623030427.908-1-mario.limonciello@amd.com/

2 years, 2 months

1
0
0 0

[PATCH 1/1] scsi: storvsc: Fix handling of virtual Fibre Channel timeouts

by Michael Kelley

Hyper-V provides the ability to connect Fibre Channel LUNs to the host system and present them in a guest VM as a SCSI device. I/O to the vFC device is handled by the storvsc driver. The storvsc driver includes a partial integration with the FC transport implemented in the generic portion of the Linux SCSI subsystem so that FC attributes can be displayed in /sys. However, the partial integration means that some aspects of vFC don't work properly. Unfortunately, a full and correct integration isn't practical because of limitations in what Hyper-V provides to the guest. In particular, in the context of Hyper-V storvsc, the FC transport timeout function fc_eh_timed_out() causes a kernel panic because it can't find the rport and dereferences a NULL pointer. The original patch that added the call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this regard. In many cases a timeout is due to a transient condition, so the situation can be improved by just continuing to wait like with other I/O requests issued by storvsc, and avoiding the guaranteed panic. For a permanent failure, continuing to wait may result in a hung thread instead of a panic, which again may be better. So fix the panic by removing the storvsc call to fc_eh_timed_out(). This allows storvsc to keep waiting for a response. The change has been tested by users who experienced a panic in fc_eh_timed_out() due to transient timeouts, and it solves their problem. In the future we may want to deprecate the vFC functionality in storvsc since it can't be fully fixed. But it has current users for whom it is working well enough, so it should probably stay for a while longer. Fixes: 3930d7309807 ("scsi: storvsc: use default I/O timeout handler for FC devices") Cc: stable(a)vger.kernel.org Signed-off-by: Michael Kelley <mikelley(a)microsoft.com> --- drivers/scsi/storvsc_drv.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 659196a..6014200 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1671,10 +1671,6 @@ static int storvsc_host_reset_handler(struct scsi_cmnd *scmnd) */ static enum scsi_timeout_action storvsc_eh_timed_out(struct scsi_cmnd *scmnd) { -#if IS_ENABLED(CONFIG_SCSI_FC_ATTRS) - if (scmnd->device->host->transportt == fc_transport_template) - return fc_eh_timed_out(scmnd); -#endif return SCSI_EH_RESET_TIMER; } -- 1.8.3.1

2 years, 2 months

2
1
0 0

[PATCH v1] usb: typec: tcpm: set initial svdm version based on pd revision

by RD Babiera

When sending Discover Identity messages to a Port Partner that uses Power Delivery v2 and SVDM v1, we currently send PD v2 messages with SVDM v2.0, expecting the port partner to respond with its highest supported SVDM version as stated in Section 6.4.4.2.3 in the Power Delivery v3 specification. However, sending SVDM v2 to some Power Delivery v2 port partners results in a NAK whereas sending SVDM v1 does not. NAK messages can be handled by the initiator (PD v3 section 6.4.4.2.5.1), and one solution could be to resend Discover Identity on a lower SVDM version if possible. But, Section 6.4.4.3 of PD v2 states that "A NAK response Should be taken as an indication not to retry that particular Command." Instead, we can set the SVDM version to the maximum one supported by the negotiated PD revision. When operating in PD v2, this obeys Section 6.4.4.2.3, which states the SVDM field "Shall be set to zero to indicate Version 1.0." In PD v3, the SVDM field "Shall be set to 01b to indicate Version 2.0." Fixes: c34e85fa69b9 ("usb: typec: tcpm: Send DISCOVER_IDENTITY from dedicated work") Cc: stable(a)vger.kernel.org Signed-off-by: RD Babiera <rdbabiera(a)google.com> --- drivers/usb/typec/tcpm/tcpm.c | 35 +++++++++++++++++++++++++++++++---- 1 file changed, 31 insertions(+), 4 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 829d75ebab42..5b0a428fcf5d 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -3928,6 +3928,31 @@ static enum typec_cc_status tcpm_pwr_opmode_to_rp(enum typec_pwr_opmode opmode) } } +static void tcpm_set_initial_svdm_version(struct tcpm_port *port) +{ + switch (port->negotiated_rev) { + case PD_REV30: + break; + /* + * 6.4.4.2.3 Structured VDM Version + * 2.0 states "At this time, there is only one version (1.0) defined. + * This field Shall be set to zero to indicate Version 1.0." + * 3.0 states "This field Shall be set to 01b to indicate Version 2.0." + * To ensure that we follow the Power Delivery revision we are currently + * operating on, downgrade the SVDM version to the highest one supported + * by the Power Delivery revision. + */ + case PD_REV20: + typec_partner_set_svdm_version(port->partner, + SVDM_VER_1_0); + break; + default: + typec_partner_set_svdm_version(port->partner, + SVDM_VER_1_0); + break; + } +} + static void run_state_machine(struct tcpm_port *port) { int ret; @@ -4165,9 +4190,10 @@ static void run_state_machine(struct tcpm_port *port) * For now, this driver only supports SOP for DISCOVER_IDENTITY, thus using * port->explicit_contract to decide whether to send the command. */ - if (port->explicit_contract) + if (port->explicit_contract) { + tcpm_set_initial_svdm_version(port); mod_send_discover_delayed_work(port, 0); - else + } else port->send_discover = false; /* @@ -4455,9 +4481,10 @@ static void run_state_machine(struct tcpm_port *port) * For now, this driver only supports SOP for DISCOVER_IDENTITY, thus using * port->explicit_contract. */ - if (port->explicit_contract) + if (port->explicit_contract) { + tcpm_set_initial_svdm_version(port); mod_send_discover_delayed_work(port, 0); - else + } else port->send_discover = false; power_supply_changed(port->psy); base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c -- 2.41.0.487.g6d72f3e995-goog

2 years, 2 months

2
2
0 0

[PATCH v9 02/10] serial: sc16is7xx: mark IOCONTROL register as volatile

by Hugo Villeneuve

From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Bit SRESET (3) is cleared when a reset operation is completed. Having the IOCONTROL register as non-volatile will always read SRESET as 1, which is incorrect. Also, if IOCONTROL register is not a volatile register, the upcoming patch "serial: sc16is7xx: fix regression with GPIO configuration" doesn't work when setting some shared GPIO lines as modem control lines. Therefore mark IOCONTROL register as a volatile register. Cc: <stable(a)vger.kernel.org> # 6.1.x Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Reviewed-by: Lech Perczak <lech.perczak(a)camlingroup.com> Tested-by: Lech Perczak <lech.perczak(a)camlingroup.com> --- drivers/tty/serial/sc16is7xx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 8ae2afc76a9b..306ae512b38a 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -488,6 +488,7 @@ static bool sc16is7xx_regmap_volatile(struct device *dev, unsigned int reg) case SC16IS7XX_TXLVL_REG: case SC16IS7XX_RXLVL_REG: case SC16IS7XX_IOSTATE_REG: + case SC16IS7XX_IOCONTROL_REG: return true; default: break; -- 2.30.2

2 years, 2 months

2
2
0 0

[PATCH v3] riscv: Handle zicsr/zifencei issue between gcc and binutils

by Mingzheng Xing

Binutils-2.38 and GCC-12.1.0 bumped[0][1] the default ISA spec to the newer 20191213 version which moves some instructions from the I extension to the Zicsr and Zifencei extensions. So if one of the binutils and GCC exceeds that version, we should explicitly specifying Zicsr and Zifencei via -march to cope with the new changes. but this only occurs when binutils >= 2.36 and GCC >= 11.1.0. It's a different story when binutils < 2.36. binutils-2.36 supports the Zifencei extension[2] and splits Zifencei and Zicsr from I[3]. GCC-11.1.0 is particular[4] because it add support Zicsr and Zifencei extension for -march. binutils-2.35 does not support the Zifencei extension, and does not need to specify Zicsr and Zifencei when working with GCC >= 12.1.0. To make our lives easier, let's relax the check to binutils >= 2.36 in CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. For the other two cases, where clang < 17 or GCC < 11.1.0, we will deal with them in CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC. For more information, please refer to: commit 6df2a016c0c8 ("riscv: fix build with binutils 2.38") commit e89c2e815e76 ("riscv: Handle zicsr/zifencei issues between clang and binutils") Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae871… [0] Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51… [1] Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5a1b31e1e1cee6e9f… [2] Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=729a53530e86972d1… [3] Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b03be74bad08c382da47e048007a7… [4] Link: https://lore.kernel.org/all/20230308220842.1231003-1-conor@kernel.org Link: https://lore.kernel.org/all/20230223220546.52879-1-conor@kernel.org Signed-off-by: Mingzheng Xing <xingmingzheng(a)iscas.ac.cn> --- v3: - Relax the check to binutils >= 2.36. - Update the Kconfig help text and commit message. v2: - Update the Kconfig help text and commit message. - Add considerations for low version gcc case. arch/riscv/Kconfig | 33 ++++++++++++++++---------- arch/riscv/kernel/compat_vdso/Makefile | 8 ++++++- 2 files changed, 27 insertions(+), 14 deletions(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 4c07b9189c86..2704bd91dfb5 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -570,24 +570,31 @@ config TOOLCHAIN_HAS_ZIHINTPAUSE config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI def_bool y # https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae871… - depends on AS_IS_GNU && AS_VERSION >= 23800 - help - Newer binutils versions default to ISA spec version 20191213 which - moves some instructions from the I extension to the Zicsr and Zifencei - extensions. + # https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51… + depends on AS_IS_GNU && AS_VERSION >= 23600 + help + Binutils-2.38 and GCC-12.1.0 bumped the default ISA spec to the newer + 20191213 version, which moves some instructions from the I extension to + the Zicsr and Zifencei extensions. This requires explicitly specifying + zicsr and zifencei when binutils >= 2.38 or GCC >= 12.1.0, but this only + occurs when binutils >= 2.36 and GCC >= 11.1.0. It's a different story + when binutils < 2.36. Also, we have to consider the case of clang paired + with binutils. + To make our lives easier, we relax the check to binutils >= 2.36. For + the other two cases, where clang < 17 or GCC < 11.1.0, we will deal with + them in CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC. config TOOLCHAIN_NEEDS_OLD_ISA_SPEC def_bool y depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI # https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694… - depends on CC_IS_CLANG && CLANG_VERSION < 170000 - help - Certain versions of clang do not support zicsr and zifencei via -march - but newer versions of binutils require it for the reasons noted in the - help text of CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. This - option causes an older ISA spec compatible with these older versions - of clang to be passed to GAS, which has the same result as passing zicsr - and zifencei to -march. + # https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b03be74bad08c382da47e048007a7… + depends on (CC_IS_CLANG && CLANG_VERSION < 170000) || (CC_IS_GCC && GCC_VERSION < 110100) + help + Certain versions of clang and GCC do not support zicsr and zifencei via + -march. This option causes an older ISA spec compatible with these older + versions of clang and GCC to be passed to GAS, which has the same result + as passing zicsr and zifencei to -march. config FPU bool "FPU support" diff --git a/arch/riscv/kernel/compat_vdso/Makefile b/arch/riscv/kernel/compat_vdso/Makefile index 189345773e7e..b86e5e2c3aea 100644 --- a/arch/riscv/kernel/compat_vdso/Makefile +++ b/arch/riscv/kernel/compat_vdso/Makefile @@ -11,7 +11,13 @@ compat_vdso-syms += flush_icache COMPAT_CC := $(CC) COMPAT_LD := $(LD) -COMPAT_CC_FLAGS := -march=rv32g -mabi=ilp32 +# binutils 2.35 does not support the zifencei extension, but in the ISA +# spec 20191213, G stands for IMAFD_ZICSR_ZIFENCEI. +ifdef CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI + COMPAT_CC_FLAGS := -march=rv32g -mabi=ilp32 +else + COMPAT_CC_FLAGS := -march=rv32imafd -mabi=ilp32 +endif COMPAT_LD_FLAGS := -melf32lriscv # Disable attributes, as they're useless and break the build. -- 2.34.1

2 years, 2 months

4
4
0 0

[PATCH] dma-buf: keep the signaling time of merged fences v3

by Christian König

Some Android CTS is testing if the signaling time keeps consistent during merges. v2: use the current time if the fence is still in the signaling path and the timestamp not yet available. v3: improve comment, fix one more case to use the correct timestamp Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Luben Tuikov <luben.tuikov(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230630120041.109216-1-chris… Cc: <stable(a)vger.kernel.org> # v6.0+ --- drivers/dma-buf/dma-fence-unwrap.c | 26 ++++++++++++++++++++++---- drivers/dma-buf/dma-fence.c | 5 +++-- drivers/gpu/drm/drm_syncobj.c | 2 +- include/linux/dma-fence.h | 2 +- 4 files changed, 27 insertions(+), 8 deletions(-) diff --git a/drivers/dma-buf/dma-fence-unwrap.c b/drivers/dma-buf/dma-fence-unwrap.c index 7002bca792ff..c625bb2b5d56 100644 --- a/drivers/dma-buf/dma-fence-unwrap.c +++ b/drivers/dma-buf/dma-fence-unwrap.c @@ -66,18 +66,36 @@ struct dma_fence *__dma_fence_unwrap_merge(unsigned int num_fences, { struct dma_fence_array *result; struct dma_fence *tmp, **array; + ktime_t timestamp; unsigned int i; size_t count; count = 0; + timestamp = ns_to_ktime(0); for (i = 0; i < num_fences; ++i) { - dma_fence_unwrap_for_each(tmp, &iter[i], fences[i]) - if (!dma_fence_is_signaled(tmp)) + dma_fence_unwrap_for_each(tmp, &iter[i], fences[i]) { + if (!dma_fence_is_signaled(tmp)) { ++count; + } else if (test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, + &tmp->flags)) { + if (ktime_after(tmp->timestamp, timestamp)) + timestamp = tmp->timestamp; + } else { + /* + * Use the current time if the fence is + * currently signaling. + */ + timestamp = ktime_get(); + } + } } + /* + * If we couldn't find a pending fence just return a private signaled + * fence with the timestamp of the last signaled one. + */ if (count == 0) - return dma_fence_get_stub(); + return dma_fence_allocate_private_stub(timestamp); array = kmalloc_array(count, sizeof(*array), GFP_KERNEL); if (!array) @@ -138,7 +156,7 @@ struct dma_fence *__dma_fence_unwrap_merge(unsigned int num_fences, } while (tmp); if (count == 0) { - tmp = dma_fence_get_stub(); + tmp = dma_fence_allocate_private_stub(ktime_get()); goto return_tmp; } diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index f177c56269bb..ad076f208760 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -150,10 +150,11 @@ EXPORT_SYMBOL(dma_fence_get_stub); /** * dma_fence_allocate_private_stub - return a private, signaled fence + * @timestamp: timestamp when the fence was signaled * * Return a newly allocated and signaled stub fence. */ -struct dma_fence *dma_fence_allocate_private_stub(void) +struct dma_fence *dma_fence_allocate_private_stub(ktime_t timestamp) { struct dma_fence *fence; @@ -169,7 +170,7 @@ struct dma_fence *dma_fence_allocate_private_stub(void) set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags); - dma_fence_signal(fence); + dma_fence_signal_timestamp(fence, timestamp); return fence; } diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index 0c2be8360525..04589a35eb09 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -353,7 +353,7 @@ EXPORT_SYMBOL(drm_syncobj_replace_fence); */ static int drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj) { - struct dma_fence *fence = dma_fence_allocate_private_stub(); + struct dma_fence *fence = dma_fence_allocate_private_stub(ktime_get()); if (IS_ERR(fence)) return PTR_ERR(fence); diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index d54b595a0fe0..0d678e9a7b24 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -606,7 +606,7 @@ static inline signed long dma_fence_wait(struct dma_fence *fence, bool intr) void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline); struct dma_fence *dma_fence_get_stub(void); -struct dma_fence *dma_fence_allocate_private_stub(void); +struct dma_fence *dma_fence_allocate_private_stub(ktime_t timestamp); u64 dma_fence_context_alloc(unsigned num); extern const struct dma_fence_ops dma_fence_array_ops; -- 2.34.1

2 years, 2 months

2
1
0 0

[RESEND PATCH v5 1/3] test_firmware: prevent race conditions by a correct implementation of locking

by Mirsad Todorovac

Dan Carpenter spotted a race condition in a couple of situations like these in the test_firmware driver: static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg) { u8 val; int ret; ret = kstrtou8(buf, 10, &val); if (ret) return ret; mutex_lock(&test_fw_mutex); *(u8 *)cfg = val; mutex_unlock(&test_fw_mutex); /* Always return full write size even if we didn't consume all */ return size; } static ssize_t config_num_requests_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { int rc; mutex_lock(&test_fw_mutex); if (test_fw_config->reqs) { pr_err("Must call release_all_firmware prior to changing config\n"); rc = -EINVAL; mutex_unlock(&test_fw_mutex); goto out; } mutex_unlock(&test_fw_mutex); rc = test_dev_config_update_u8(buf, count, &test_fw_config->num_requests); out: return rc; } static ssize_t config_read_fw_idx_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { return test_dev_config_update_u8(buf, count, &test_fw_config->read_fw_idx); } The function test_dev_config_update_u8() is called from both the locked and the unlocked context, function config_num_requests_store() and config_read_fw_idx_store() which can both be called asynchronously as they are driver's methods, while test_dev_config_update_u8() and siblings change their argument pointed to by u8 *cfg or similar pointer. To avoid deadlock on test_fw_mutex, the lock is dropped before calling test_dev_config_update_u8() and re-acquired within test_dev_config_update_u8() itself, but alas this creates a race condition. Having two locks wouldn't assure a race-proof mutual exclusion. This situation is best avoided by the introduction of a new, unlocked function __test_dev_config_update_u8() which can be called from the locked context and reducing test_dev_config_update_u8() to: static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg) { int ret; mutex_lock(&test_fw_mutex); ret = __test_dev_config_update_u8(buf, size, cfg); mutex_unlock(&test_fw_mutex); return ret; } doing the locking and calling the unlocked primitive, which enables both locked and unlocked versions without duplication of code. The similar approach was applied to all functions called from the locked and the unlocked context, which safely mitigates both deadlocks and race conditions in the driver. __test_dev_config_update_bool(), __test_dev_config_update_u8() and __test_dev_config_update_size_t() unlocked versions of the functions were introduced to be called from the locked contexts as a workaround without releasing the main driver's lock and thereof causing a race condition. The test_dev_config_update_bool(), test_dev_config_update_u8() and test_dev_config_update_size_t() locked versions of the functions are being called from driver methods without the unnecessary multiplying of the locking and unlocking code for each method, and complicating the code with saving of the return value across lock. Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf") Cc: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Russ Weight <russell.h.weight(a)intel.com> Cc: Takashi Iwai <tiwai(a)suse.de> Cc: Tianfei Zhang <tianfei.zhang(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Colin Ian King <colin.i.king(a)gmail.com> Cc: Randy Dunlap <rdunlap(a)infradead.org> Cc: linux-kselftest(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v5.4 Suggested-by: Dan Carpenter <error27(a)gmail.com> Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac(a)alu.unizg.hr> --- v5.1 resending to v5.4 stable branch verbatim according to Luis Chamberlain instruction lib/test_firmware.c | 52 ++++++++++++++++++++++++++++++--------------- 1 file changed, 35 insertions(+), 17 deletions(-) diff --git a/lib/test_firmware.c b/lib/test_firmware.c index 05ed84c2fc4c..35417e0af3f4 100644 --- a/lib/test_firmware.c +++ b/lib/test_firmware.c @@ -353,16 +353,26 @@ static ssize_t config_test_show_str(char *dst, return len; } -static int test_dev_config_update_bool(const char *buf, size_t size, +static inline int __test_dev_config_update_bool(const char *buf, size_t size, bool *cfg) { int ret; - mutex_lock(&test_fw_mutex); if (kstrtobool(buf, cfg) < 0) ret = -EINVAL; else ret = size; + + return ret; +} + +static int test_dev_config_update_bool(const char *buf, size_t size, + bool *cfg) +{ + int ret; + + mutex_lock(&test_fw_mutex); + ret = __test_dev_config_update_bool(buf, size, cfg); mutex_unlock(&test_fw_mutex); return ret; @@ -373,7 +383,8 @@ static ssize_t test_dev_config_show_bool(char *buf, bool val) return snprintf(buf, PAGE_SIZE, "%d\n", val); } -static int test_dev_config_update_size_t(const char *buf, +static int __test_dev_config_update_size_t( + const char *buf, size_t size, size_t *cfg) { @@ -384,9 +395,7 @@ static int test_dev_config_update_size_t(const char *buf, if (ret) return ret; - mutex_lock(&test_fw_mutex); *(size_t *)cfg = new; - mutex_unlock(&test_fw_mutex); /* Always return full write size even if we didn't consume all */ return size; @@ -402,7 +411,7 @@ static ssize_t test_dev_config_show_int(char *buf, int val) return snprintf(buf, PAGE_SIZE, "%d\n", val); } -static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg) +static int __test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg) { u8 val; int ret; @@ -411,14 +420,23 @@ static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg) if (ret) return ret; - mutex_lock(&test_fw_mutex); *(u8 *)cfg = val; - mutex_unlock(&test_fw_mutex); /* Always return full write size even if we didn't consume all */ return size; } +static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg) +{ + int ret; + + mutex_lock(&test_fw_mutex); + ret = __test_dev_config_update_u8(buf, size, cfg); + mutex_unlock(&test_fw_mutex); + + return ret; +} + static ssize_t test_dev_config_show_u8(char *buf, u8 val) { return snprintf(buf, PAGE_SIZE, "%u\n", val); @@ -471,10 +489,10 @@ static ssize_t config_num_requests_store(struct device *dev, mutex_unlock(&test_fw_mutex); goto out; } - mutex_unlock(&test_fw_mutex); - rc = test_dev_config_update_u8(buf, count, - &test_fw_config->num_requests); + rc = __test_dev_config_update_u8(buf, count, + &test_fw_config->num_requests); + mutex_unlock(&test_fw_mutex); out: return rc; @@ -518,10 +536,10 @@ static ssize_t config_buf_size_store(struct device *dev, mutex_unlock(&test_fw_mutex); goto out; } - mutex_unlock(&test_fw_mutex); - rc = test_dev_config_update_size_t(buf, count, - &test_fw_config->buf_size); + rc = __test_dev_config_update_size_t(buf, count, + &test_fw_config->buf_size); + mutex_unlock(&test_fw_mutex); out: return rc; @@ -548,10 +566,10 @@ static ssize_t config_file_offset_store(struct device *dev, mutex_unlock(&test_fw_mutex); goto out; } - mutex_unlock(&test_fw_mutex); - rc = test_dev_config_update_size_t(buf, count, - &test_fw_config->file_offset); + rc = __test_dev_config_update_size_t(buf, count, + &test_fw_config->file_offset); + mutex_unlock(&test_fw_mutex); out: return rc; -- 2.30.2

2 years, 2 months

3
4
0 0

FAILED: patch "[PATCH] btrfs: check if the transaction was aborted at" 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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x bf7ecbe9875061bf3fce1883e3b26b77f847d1e8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073107-greedy-comrade-d289@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: bf7ecbe98750 ("btrfs: check if the transaction was aborted at btrfs_wait_for_commit()") d0c2f4fa555e ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") bf31f87f71cc ("btrfs: add wrapper for transaction abort predicate") 77745c05115f ("btrfs: migrate the dirty bg writeout code") 26ce2095e03c ("btrfs: migrate inc/dec_block_group_ro code") 8484764e8587 ("btrfs: temporarily export btrfs_get_restripe_target") 4358d9635a16 ("btrfs: migrate the block group read/creation code") e3e0520b32bc ("btrfs: migrate the block group removal code") 3b2a78f21d5c ("btrfs: temporarily export inc_block_group_ro") 9f21246d8c7e ("btrfs: migrate the block group caching code") 32a9991f15a0 ("btrfs: factor sysfs code out of link_block_group") 89439109bc2b ("btrfs: move sysfs declarations out of ctree.h") 6a9fb468f115 ("btrfs: make caching_thread use btrfs_find_next_key") caa4efafcf03 ("btrfs: temporarily export fragment_free_space") e3cb339fa5ca ("btrfs: export the caching control helpers") 6f410d1b3dbf ("btrfs: export the excluded extents helpers") 676f1f759fa3 ("btrfs: export the block group caching helpers") 3eeb3226a889 ("btrfs: migrate nocow and reservation helpers") 3cad128400c2 ("btrfs: migrate the block group ref counting stuff") 2e405ad84254 ("btrfs: migrate the block group lookup code") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From bf7ecbe9875061bf3fce1883e3b26b77f847d1e8 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Fri, 21 Jul 2023 10:49:20 +0100 Subject: [PATCH] btrfs: check if the transaction was aborted at btrfs_wait_for_commit() At btrfs_wait_for_commit() we wait for a transaction to finish and then always return 0 (success) without checking if it was aborted, in which case the transaction didn't happen due to some critical error. Fix this by checking if the transaction was aborted. Fixes: 462045928bda ("Btrfs: add START_SYNC, WAIT_SYNC ioctls") CC: stable(a)vger.kernel.org # 4.19+ Reviewed-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index cf306351b148..f11d803b2c4e 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -931,6 +931,7 @@ int btrfs_wait_for_commit(struct btrfs_fs_info *fs_info, u64 transid) } wait_for_commit(cur_trans, TRANS_STATE_COMPLETED); + ret = cur_trans->aborted; btrfs_put_transaction(cur_trans); out: return ret;

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: check if the transaction was aborted at" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x bf7ecbe9875061bf3fce1883e3b26b77f847d1e8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073106-swipe-overheat-432b@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: bf7ecbe98750 ("btrfs: check if the transaction was aborted at btrfs_wait_for_commit()") d0c2f4fa555e ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") bf31f87f71cc ("btrfs: add wrapper for transaction abort predicate") 77745c05115f ("btrfs: migrate the dirty bg writeout code") 26ce2095e03c ("btrfs: migrate inc/dec_block_group_ro code") 8484764e8587 ("btrfs: temporarily export btrfs_get_restripe_target") 4358d9635a16 ("btrfs: migrate the block group read/creation code") e3e0520b32bc ("btrfs: migrate the block group removal code") 3b2a78f21d5c ("btrfs: temporarily export inc_block_group_ro") 9f21246d8c7e ("btrfs: migrate the block group caching code") 32a9991f15a0 ("btrfs: factor sysfs code out of link_block_group") 89439109bc2b ("btrfs: move sysfs declarations out of ctree.h") 6a9fb468f115 ("btrfs: make caching_thread use btrfs_find_next_key") caa4efafcf03 ("btrfs: temporarily export fragment_free_space") e3cb339fa5ca ("btrfs: export the caching control helpers") 6f410d1b3dbf ("btrfs: export the excluded extents helpers") 676f1f759fa3 ("btrfs: export the block group caching helpers") 3eeb3226a889 ("btrfs: migrate nocow and reservation helpers") 3cad128400c2 ("btrfs: migrate the block group ref counting stuff") 2e405ad84254 ("btrfs: migrate the block group lookup code") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From bf7ecbe9875061bf3fce1883e3b26b77f847d1e8 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Fri, 21 Jul 2023 10:49:20 +0100 Subject: [PATCH] btrfs: check if the transaction was aborted at btrfs_wait_for_commit() At btrfs_wait_for_commit() we wait for a transaction to finish and then always return 0 (success) without checking if it was aborted, in which case the transaction didn't happen due to some critical error. Fix this by checking if the transaction was aborted. Fixes: 462045928bda ("Btrfs: add START_SYNC, WAIT_SYNC ioctls") CC: stable(a)vger.kernel.org # 4.19+ Reviewed-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index cf306351b148..f11d803b2c4e 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -931,6 +931,7 @@ int btrfs_wait_for_commit(struct btrfs_fs_info *fs_info, u64 transid) } wait_for_commit(cur_trans, TRANS_STATE_COMPLETED); + ret = cur_trans->aborted; btrfs_put_transaction(cur_trans); out: return ret;

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: check if the transaction was aborted at" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x bf7ecbe9875061bf3fce1883e3b26b77f847d1e8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073104-derail-catchable-a802@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: bf7ecbe98750 ("btrfs: check if the transaction was aborted at btrfs_wait_for_commit()") d0c2f4fa555e ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") bf31f87f71cc ("btrfs: add wrapper for transaction abort predicate") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From bf7ecbe9875061bf3fce1883e3b26b77f847d1e8 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Fri, 21 Jul 2023 10:49:20 +0100 Subject: [PATCH] btrfs: check if the transaction was aborted at btrfs_wait_for_commit() At btrfs_wait_for_commit() we wait for a transaction to finish and then always return 0 (success) without checking if it was aborted, in which case the transaction didn't happen due to some critical error. Fix this by checking if the transaction was aborted. Fixes: 462045928bda ("Btrfs: add START_SYNC, WAIT_SYNC ioctls") CC: stable(a)vger.kernel.org # 4.19+ Reviewed-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index cf306351b148..f11d803b2c4e 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -931,6 +931,7 @@ int btrfs_wait_for_commit(struct btrfs_fs_info *fs_info, u64 transid) } wait_for_commit(cur_trans, TRANS_STATE_COMPLETED); + ret = cur_trans->aborted; btrfs_put_transaction(cur_trans); out: return ret;

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: check if the transaction was aborted at" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x bf7ecbe9875061bf3fce1883e3b26b77f847d1e8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073103-subtly-unlearned-817b@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: bf7ecbe98750 ("btrfs: check if the transaction was aborted at btrfs_wait_for_commit()") d0c2f4fa555e ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From bf7ecbe9875061bf3fce1883e3b26b77f847d1e8 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Fri, 21 Jul 2023 10:49:20 +0100 Subject: [PATCH] btrfs: check if the transaction was aborted at btrfs_wait_for_commit() At btrfs_wait_for_commit() we wait for a transaction to finish and then always return 0 (success) without checking if it was aborted, in which case the transaction didn't happen due to some critical error. Fix this by checking if the transaction was aborted. Fixes: 462045928bda ("Btrfs: add START_SYNC, WAIT_SYNC ioctls") CC: stable(a)vger.kernel.org # 4.19+ Reviewed-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index cf306351b148..f11d803b2c4e 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -931,6 +931,7 @@ int btrfs_wait_for_commit(struct btrfs_fs_info *fs_info, u64 transid) } wait_for_commit(cur_trans, TRANS_STATE_COMPLETED); + ret = cur_trans->aborted; btrfs_put_transaction(cur_trans); out: return ret;

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] hwmon: (k10temp) Enable AMD3255 Proc to show negative" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x e146503ac68418859fb063a3a0cd9ec93bc52238 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073133-crystal-overdue-6430@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: e146503ac684 ("hwmon: (k10temp) Enable AMD3255 Proc to show negative temperature") 0e3f52bbd9eb ("hwmon: (k10temp) Rework the temperature offset calculation") 128066c88770 ("hwmon: (k10temp) Add additional missing Zen2 and Zen3 APUs") 02c9dce4df8d ("hwmon: (k10temp) support Zen3 APUs") c8d0d3fa9469 ("hwmon: (k10temp) Zen3 Ryzen Desktop CPUs support") 0a4e668b5d52 ("hwmon: (k10temp) Remove support for displaying voltage and current on Zen CPUs") 55163a1c00fc ("hwmon: (k10temp) Add support for Zen3 CPUs") d6144a40041a ("hwmon: (k10temp) Define SVI telemetry and current factors for Zen2 CPUs") 178224170423 ("hwmon: (k10temp) Create common functions and macros for Zen CPU families") 0e786f328b38 ("hwmon: (k10temp) make some symbols static") 60465245e6ce ("hwmon: (k10temp) Reorganize and simplify temperature support detection") b02c6857389d ("hwmon: (k10temp) Swap Tdie and Tctl on Family 17h CPUs") fd8bdb23b918 ("hwmon: (k10temp) Display up to eight sets of CCD temperatures") 9c4a38f19ed2 ("hwmon: (k10temp) Add debugfs support") 70831c8a9184 ("hwmon: (k10temp) Don't show temperature limits on Ryzen (Zen) CPUs") b00647c46c9d ("hwmon: (k10temp) Show core and SoC current and voltages on Ryzen CPUs") c757938929c9 ("hwmon: (k10temp) Report temperatures per CPU die") d547552a1bf1 ("hmon: (k10temp) Convert to use devm_hwmon_device_register_with_info") a6d210da1a01 ("hwmon: (k10temp) Use bitops") 12163cfbfc0f ("hwmon: (k10temp) Add support for AMD family 17h, model 70h CPUs") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e146503ac68418859fb063a3a0cd9ec93bc52238 Mon Sep 17 00:00:00 2001 From: Baskaran Kannan <Baski.Kannan(a)amd.com> Date: Thu, 27 Jul 2023 11:21:59 -0500 Subject: [PATCH] hwmon: (k10temp) Enable AMD3255 Proc to show negative temperature Industrial processor i3255 supports temperatures -40 deg celcius to 105 deg Celcius. The current implementation of k10temp_read_temp rounds off any negative temperatures to '0'. To fix this, the following changes have been made. A flag 'disp_negative' is added to struct k10temp_data to support AMD i3255 processors. Flag 'disp_negative' is set if 3255 processor is found during k10temp_probe. Flag 'disp_negative' is used to determine whether to round off negative temperatures to '0' in k10temp_read_temp. Signed-off-by: Baskaran Kannan <Baski.Kannan(a)amd.com> Link: https://lore.kernel.org/r/20230727162159.1056136-1-Baski.Kannan@amd.com Fixes: aef17ca12719 ("hwmon: (k10temp) Only apply temperature offset if result is positive") Cc: stable(a)vger.kernel.org [groeck: Fixed multi-line comment] Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c index 7b177b9fbb09..a267b11731a8 100644 --- a/drivers/hwmon/k10temp.c +++ b/drivers/hwmon/k10temp.c @@ -77,6 +77,13 @@ static DEFINE_MUTEX(nb_smu_ind_mutex); #define ZEN_CUR_TEMP_RANGE_SEL_MASK BIT(19) #define ZEN_CUR_TEMP_TJ_SEL_MASK GENMASK(17, 16) +/* + * AMD's Industrial processor 3255 supports temperature from -40 deg to 105 deg Celsius. + * Use the model name to identify 3255 CPUs and set a flag to display negative temperature. + * Do not round off to zero for negative Tctl or Tdie values if the flag is set + */ +#define AMD_I3255_STR "3255" + struct k10temp_data { struct pci_dev *pdev; void (*read_htcreg)(struct pci_dev *pdev, u32 *regval); @@ -86,6 +93,7 @@ struct k10temp_data { u32 show_temp; bool is_zen; u32 ccd_offset; + bool disp_negative; }; #define TCTL_BIT 0 @@ -204,12 +212,12 @@ static int k10temp_read_temp(struct device *dev, u32 attr, int channel, switch (channel) { case 0: /* Tctl */ *val = get_raw_temp(data); - if (*val < 0) + if (*val < 0 && !data->disp_negative) *val = 0; break; case 1: /* Tdie */ *val = get_raw_temp(data) - data->temp_offset; - if (*val < 0) + if (*val < 0 && !data->disp_negative) *val = 0; break; case 2 ... 13: /* Tccd{1-12} */ @@ -405,6 +413,11 @@ static int k10temp_probe(struct pci_dev *pdev, const struct pci_device_id *id) data->pdev = pdev; data->show_temp |= BIT(TCTL_BIT); /* Always show Tctl */ + if (boot_cpu_data.x86 == 0x17 && + strstr(boot_cpu_data.x86_model_id, AMD_I3255_STR)) { + data->disp_negative = true; + } + if (boot_cpu_data.x86 == 0x15 && ((boot_cpu_data.x86_model & 0xf0) == 0x60 || (boot_cpu_data.x86_model & 0xf0) == 0x70)) {

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] hwmon: (k10temp) Enable AMD3255 Proc to show negative" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x e146503ac68418859fb063a3a0cd9ec93bc52238 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073132-squid-chowder-7b18@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: e146503ac684 ("hwmon: (k10temp) Enable AMD3255 Proc to show negative temperature") 0e3f52bbd9eb ("hwmon: (k10temp) Rework the temperature offset calculation") 128066c88770 ("hwmon: (k10temp) Add additional missing Zen2 and Zen3 APUs") 02c9dce4df8d ("hwmon: (k10temp) support Zen3 APUs") c8d0d3fa9469 ("hwmon: (k10temp) Zen3 Ryzen Desktop CPUs support") 0a4e668b5d52 ("hwmon: (k10temp) Remove support for displaying voltage and current on Zen CPUs") 55163a1c00fc ("hwmon: (k10temp) Add support for Zen3 CPUs") d6144a40041a ("hwmon: (k10temp) Define SVI telemetry and current factors for Zen2 CPUs") 178224170423 ("hwmon: (k10temp) Create common functions and macros for Zen CPU families") 0e786f328b38 ("hwmon: (k10temp) make some symbols static") 60465245e6ce ("hwmon: (k10temp) Reorganize and simplify temperature support detection") b02c6857389d ("hwmon: (k10temp) Swap Tdie and Tctl on Family 17h CPUs") fd8bdb23b918 ("hwmon: (k10temp) Display up to eight sets of CCD temperatures") 9c4a38f19ed2 ("hwmon: (k10temp) Add debugfs support") 70831c8a9184 ("hwmon: (k10temp) Don't show temperature limits on Ryzen (Zen) CPUs") b00647c46c9d ("hwmon: (k10temp) Show core and SoC current and voltages on Ryzen CPUs") c757938929c9 ("hwmon: (k10temp) Report temperatures per CPU die") d547552a1bf1 ("hmon: (k10temp) Convert to use devm_hwmon_device_register_with_info") a6d210da1a01 ("hwmon: (k10temp) Use bitops") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e146503ac68418859fb063a3a0cd9ec93bc52238 Mon Sep 17 00:00:00 2001 From: Baskaran Kannan <Baski.Kannan(a)amd.com> Date: Thu, 27 Jul 2023 11:21:59 -0500 Subject: [PATCH] hwmon: (k10temp) Enable AMD3255 Proc to show negative temperature Industrial processor i3255 supports temperatures -40 deg celcius to 105 deg Celcius. The current implementation of k10temp_read_temp rounds off any negative temperatures to '0'. To fix this, the following changes have been made. A flag 'disp_negative' is added to struct k10temp_data to support AMD i3255 processors. Flag 'disp_negative' is set if 3255 processor is found during k10temp_probe. Flag 'disp_negative' is used to determine whether to round off negative temperatures to '0' in k10temp_read_temp. Signed-off-by: Baskaran Kannan <Baski.Kannan(a)amd.com> Link: https://lore.kernel.org/r/20230727162159.1056136-1-Baski.Kannan@amd.com Fixes: aef17ca12719 ("hwmon: (k10temp) Only apply temperature offset if result is positive") Cc: stable(a)vger.kernel.org [groeck: Fixed multi-line comment] Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c index 7b177b9fbb09..a267b11731a8 100644 --- a/drivers/hwmon/k10temp.c +++ b/drivers/hwmon/k10temp.c @@ -77,6 +77,13 @@ static DEFINE_MUTEX(nb_smu_ind_mutex); #define ZEN_CUR_TEMP_RANGE_SEL_MASK BIT(19) #define ZEN_CUR_TEMP_TJ_SEL_MASK GENMASK(17, 16) +/* + * AMD's Industrial processor 3255 supports temperature from -40 deg to 105 deg Celsius. + * Use the model name to identify 3255 CPUs and set a flag to display negative temperature. + * Do not round off to zero for negative Tctl or Tdie values if the flag is set + */ +#define AMD_I3255_STR "3255" + struct k10temp_data { struct pci_dev *pdev; void (*read_htcreg)(struct pci_dev *pdev, u32 *regval); @@ -86,6 +93,7 @@ struct k10temp_data { u32 show_temp; bool is_zen; u32 ccd_offset; + bool disp_negative; }; #define TCTL_BIT 0 @@ -204,12 +212,12 @@ static int k10temp_read_temp(struct device *dev, u32 attr, int channel, switch (channel) { case 0: /* Tctl */ *val = get_raw_temp(data); - if (*val < 0) + if (*val < 0 && !data->disp_negative) *val = 0; break; case 1: /* Tdie */ *val = get_raw_temp(data) - data->temp_offset; - if (*val < 0) + if (*val < 0 && !data->disp_negative) *val = 0; break; case 2 ... 13: /* Tccd{1-12} */ @@ -405,6 +413,11 @@ static int k10temp_probe(struct pci_dev *pdev, const struct pci_device_id *id) data->pdev = pdev; data->show_temp |= BIT(TCTL_BIT); /* Always show Tctl */ + if (boot_cpu_data.x86 == 0x17 && + strstr(boot_cpu_data.x86_model_id, AMD_I3255_STR)) { + data->disp_negative = true; + } + if (boot_cpu_data.x86 == 0x15 && ((boot_cpu_data.x86_model & 0xf0) == 0x60 || (boot_cpu_data.x86_model & 0xf0) == 0x70)) {

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] hwmon: (k10temp) Enable AMD3255 Proc to show negative" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x e146503ac68418859fb063a3a0cd9ec93bc52238 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073131-divinely-cheek-8e43@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: e146503ac684 ("hwmon: (k10temp) Enable AMD3255 Proc to show negative temperature") 0e3f52bbd9eb ("hwmon: (k10temp) Rework the temperature offset calculation") 128066c88770 ("hwmon: (k10temp) Add additional missing Zen2 and Zen3 APUs") 02c9dce4df8d ("hwmon: (k10temp) support Zen3 APUs") c8d0d3fa9469 ("hwmon: (k10temp) Zen3 Ryzen Desktop CPUs support") 0a4e668b5d52 ("hwmon: (k10temp) Remove support for displaying voltage and current on Zen CPUs") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e146503ac68418859fb063a3a0cd9ec93bc52238 Mon Sep 17 00:00:00 2001 From: Baskaran Kannan <Baski.Kannan(a)amd.com> Date: Thu, 27 Jul 2023 11:21:59 -0500 Subject: [PATCH] hwmon: (k10temp) Enable AMD3255 Proc to show negative temperature Industrial processor i3255 supports temperatures -40 deg celcius to 105 deg Celcius. The current implementation of k10temp_read_temp rounds off any negative temperatures to '0'. To fix this, the following changes have been made. A flag 'disp_negative' is added to struct k10temp_data to support AMD i3255 processors. Flag 'disp_negative' is set if 3255 processor is found during k10temp_probe. Flag 'disp_negative' is used to determine whether to round off negative temperatures to '0' in k10temp_read_temp. Signed-off-by: Baskaran Kannan <Baski.Kannan(a)amd.com> Link: https://lore.kernel.org/r/20230727162159.1056136-1-Baski.Kannan@amd.com Fixes: aef17ca12719 ("hwmon: (k10temp) Only apply temperature offset if result is positive") Cc: stable(a)vger.kernel.org [groeck: Fixed multi-line comment] Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c index 7b177b9fbb09..a267b11731a8 100644 --- a/drivers/hwmon/k10temp.c +++ b/drivers/hwmon/k10temp.c @@ -77,6 +77,13 @@ static DEFINE_MUTEX(nb_smu_ind_mutex); #define ZEN_CUR_TEMP_RANGE_SEL_MASK BIT(19) #define ZEN_CUR_TEMP_TJ_SEL_MASK GENMASK(17, 16) +/* + * AMD's Industrial processor 3255 supports temperature from -40 deg to 105 deg Celsius. + * Use the model name to identify 3255 CPUs and set a flag to display negative temperature. + * Do not round off to zero for negative Tctl or Tdie values if the flag is set + */ +#define AMD_I3255_STR "3255" + struct k10temp_data { struct pci_dev *pdev; void (*read_htcreg)(struct pci_dev *pdev, u32 *regval); @@ -86,6 +93,7 @@ struct k10temp_data { u32 show_temp; bool is_zen; u32 ccd_offset; + bool disp_negative; }; #define TCTL_BIT 0 @@ -204,12 +212,12 @@ static int k10temp_read_temp(struct device *dev, u32 attr, int channel, switch (channel) { case 0: /* Tctl */ *val = get_raw_temp(data); - if (*val < 0) + if (*val < 0 && !data->disp_negative) *val = 0; break; case 1: /* Tdie */ *val = get_raw_temp(data) - data->temp_offset; - if (*val < 0) + if (*val < 0 && !data->disp_negative) *val = 0; break; case 2 ... 13: /* Tccd{1-12} */ @@ -405,6 +413,11 @@ static int k10temp_probe(struct pci_dev *pdev, const struct pci_device_id *id) data->pdev = pdev; data->show_temp |= BIT(TCTL_BIT); /* Always show Tctl */ + if (boot_cpu_data.x86 == 0x17 && + strstr(boot_cpu_data.x86_model_id, AMD_I3255_STR)) { + data->disp_negative = true; + } + if (boot_cpu_data.x86 == 0x15 && ((boot_cpu_data.x86_model & 0xf0) == 0x60 || (boot_cpu_data.x86_model & 0xf0) == 0x70)) {

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] Revert "xhci: add quirk for host controllers that don't" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 5bef4b3cb95a5b883dfec8b3ffc0d671323d55bb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073136-reward-diner-6aeb@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 5bef4b3cb95a ("Revert "xhci: add quirk for host controllers that don't update endpoint DCS"") 5255660b208a ("xhci: add quirk for host controllers that don't update endpoint DCS") d1658268e439 ("usb: pci-quirks: disable D3cold on xhci suspend for s2idle on AMD Renoir") a4a251f8c235 ("usb: xhci: do not perform Soft Retry for some xHCI hosts") d1dbfb942c33 ("xhci: introduce a new move_dequeue_past_td() function to replace old code.") 9ebf30007858 ("xhci: Fix halted endpoint at stop endpoint command completion") 674f8438c121 ("xhci: split handling halted endpoints into two steps") 7c6c334e6fc8 ("xhci: move and rename xhci_cleanup_halted_endpoint()") 4db356924a50 ("xhci: turn cancelled td cleanup to its own function") a6ccd1fd4bd4 ("xhci: store TD status in the td struct instead of passing it along") e1a298390e98 ("xhci: use xhci_td_cleanup() helper when giving back cancelled URBs") 69eaf9e79fa7 ("xhci: move xhci_td_cleanup so it can be called by more functions") d8ac95001bea ("xhci: Add xhci_reset_halted_ep() helper function") b1adc42d440d ("xhci: add xhci_get_virt_ep() helper") a181030703df ("xhci: remove unused event parameter from completion handlers") d70f4231b81e ("xhci: adjust parameters passed to cleanup_halted_endpoint()") d4dff8043ea5 ("xhci: get isochronous ring directly from endpoint structure") ab58f3bb6aaa ("xhci: Avoid parsing transfer events several times") bac1ec551434 ("usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5bef4b3cb95a5b883dfec8b3ffc0d671323d55bb Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Thu, 13 Jul 2023 13:28:10 +0200 Subject: [PATCH] Revert "xhci: add quirk for host controllers that don't update endpoint DCS" This reverts commit 5255660b208aebfdb71d574f3952cf48392f4306. This quirk breaks at least the following hardware: 0b:00.0 0c03: 1106:3483 (rev 01) (prog-if 30 [XHCI]) Subsystem: 1106:3483 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 66 Region 0: Memory at fb400000 (64-bit, non-prefetchable) [size=4K] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] MSI: Enable+ Count=1/4 Maskable- 64bit+ Address: 00000000fee007b8 Data: 0000 Capabilities: [c4] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 89W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <2us, L1 <16us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x1 TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range B, TimeoutDis+ NROPrPrP- LTR- 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- 10BitTagReq- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Kernel driver in use: xhci_hcd Kernel modules: xhci_pci with the quirk enabled it fails early with [ 0.754373] pci 0000:0b:00.0: xHCI HW did not halt within 32000 usec status = 0x1000 [ 0.754419] pci 0000:0b:00.0: quirk_usb_early_handoff+0x0/0x7a0 took 31459 usecs [ 2.228048] xhci_hcd 0000:0b:00.0: xHCI Host Controller [ 2.228053] xhci_hcd 0000:0b:00.0: new USB bus registered, assigned bus number 7 [ 2.260073] xhci_hcd 0000:0b:00.0: Host halt failed, -110 [ 2.260079] xhci_hcd 0000:0b:00.0: can't setup: -110 [ 2.260551] xhci_hcd 0000:0b:00.0: USB bus 7 deregistered [ 2.260624] xhci_hcd 0000:0b:00.0: init 0000:0b:00.0 fail, -110 [ 2.260639] xhci_hcd: probe of 0000:0b:00.0 failed with error -110 The hardware in question is an external PCIe card. It looks to me like the quirk needs to be narrowed down. But this needs information about the hardware showing the issue this quirk is to fix. So for now a clean revert. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Fixes: 5255660b208a ("xhci: add quirk for host controllers that don't update endpoint DCS") Cc: stable <stable(a)kernel.org> Link: https://lore.kernel.org/r/20230713112830.21773-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index c6742bae41c0..b9ae5c2a2527 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -479,10 +479,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) pdev->device == 0x3432) xhci->quirks |= XHCI_BROKEN_STREAMS; - if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == 0x3483) { + if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == 0x3483) xhci->quirks |= XHCI_LPM_SUPPORT; - xhci->quirks |= XHCI_EP_CTX_BROKEN_DCS; - } if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA && pdev->device == PCI_DEVICE_ID_ASMEDIA_1042_XHCI) { diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 646ff125def5..1dde53f6eb31 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -626,11 +626,8 @@ static int xhci_move_dequeue_past_td(struct xhci_hcd *xhci, struct xhci_ring *ep_ring; struct xhci_command *cmd; struct xhci_segment *new_seg; - struct xhci_segment *halted_seg = NULL; union xhci_trb *new_deq; int new_cycle; - union xhci_trb *halted_trb; - int index = 0; dma_addr_t addr; u64 hw_dequeue; bool cycle_found = false; @@ -668,27 +665,7 @@ static int xhci_move_dequeue_past_td(struct xhci_hcd *xhci, hw_dequeue = xhci_get_hw_deq(xhci, dev, ep_index, stream_id); new_seg = ep_ring->deq_seg; new_deq = ep_ring->dequeue; - - /* - * Quirk: xHC write-back of the DCS field in the hardware dequeue - * pointer is wrong - use the cycle state of the TRB pointed to by - * the dequeue pointer. - */ - if (xhci->quirks & XHCI_EP_CTX_BROKEN_DCS && - !(ep->ep_state & EP_HAS_STREAMS)) - halted_seg = trb_in_td(xhci, td->start_seg, - td->first_trb, td->last_trb, - hw_dequeue & ~0xf, false); - if (halted_seg) { - index = ((dma_addr_t)(hw_dequeue & ~0xf) - halted_seg->dma) / - sizeof(*halted_trb); - halted_trb = &halted_seg->trbs[index]; - new_cycle = halted_trb->generic.field[3] & 0x1; - xhci_dbg(xhci, "Endpoint DCS = %d TRB index = %d cycle = %d\n", - (u8)(hw_dequeue & 0x1), index, new_cycle); - } else { - new_cycle = hw_dequeue & 0x1; - } + new_cycle = hw_dequeue & 0x1; /* * We want to find the pointer, segment and cycle state of the new trb

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] staging: r8712: Fix memory leak in _r8712_init_xmit_priv()" 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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x ac83631230f77dda94154ed0ebfd368fc81c70a3 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073116-amigo-cabbie-e3af@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: ac83631230f7 ("staging: r8712: Fix memory leak in _r8712_init_xmit_priv()") f179515da978 ("staging: rtl8712: Use constants from <linux/ieee80211.h>") 0e934ce2904e ("staging: rtl8712: clean up comparsions to NULL") bd7a168a024d ("staging: rtl8712: use common ieee80211 constants") 3ee97e220648 ("staging: rtl8712: switch to common ieee80211 headers") 15ea976a1f12 ("staging: rtl8712: Fix IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK") 2aaeaaff1ae2 ("staging: rtl8712: code improvements to make_wlanhdr") 45afa5637b85 ("staging: rtl8712: fix long-line checkpatch warning") 5979afa2c4d1 ("staging: Replace zero-length array with flexible-array member") 96b06c0a16f7 ("Revert "staging: octeon-usb: delete the octeon usb host controller driver"") 4fb8b5aa2a11 ("staging: wilc1000: refactor p2p action frames handling API's") a474df5c1484 ("staging: wilc1000: remove use of vendor specific IE for p2p handling") 034280e33ea0 ("staging: wilc1000: refactor SPI read/write commands handling API's") 7a80aa23d0f0 ("staging: wilc1000: return zero on success and non-zero on function failure") 01fbbd42d1f4 ("staging: wilc1000: remove redundant assignment to variable result") 95ace52e4036 ("staging: octeon-usb: delete the octeon usb host controller driver") 710d7fbe21ee ("staging: octeon: delete driver") 7d42b7961b91 ("staging/octeon: Mark Ethernet driver as BROKEN") 282eaa624f06 ("staging: octeon: indent with tabs instead of spaces") 6cfed5984804 ("staging: rtl*: Remove tasklet callback casts") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ac83631230f77dda94154ed0ebfd368fc81c70a3 Mon Sep 17 00:00:00 2001 From: Larry Finger <Larry.Finger(a)lwfinger.net> Date: Fri, 14 Jul 2023 12:54:17 -0500 Subject: [PATCH] staging: r8712: Fix memory leak in _r8712_init_xmit_priv() In the above mentioned routine, memory is allocated in several places. If the first succeeds and a later one fails, the routine will leak memory. This patch fixes commit 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel"). A potential memory leak in r8712_xmit_resource_alloc() is also addressed. Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel") Reported-by: syzbot+cf71097ffb6755df8251(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/x/log.txt?x=11ac3fa0a80000 Cc: stable(a)vger.kernel.org Cc: Nam Cao <namcaov(a)gmail.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Reviewed-by: Nam Cao <namcaov(a)gmail.com> Link: https://lore.kernel.org/r/20230714175417.18578-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c b/drivers/staging/rtl8712/rtl871x_xmit.c index 090345bad223..6353dbe554d3 100644 --- a/drivers/staging/rtl8712/rtl871x_xmit.c +++ b/drivers/staging/rtl8712/rtl871x_xmit.c @@ -21,6 +21,7 @@ #include "osdep_intf.h" #include "usb_ops.h" +#include <linux/usb.h> #include <linux/ieee80211.h> static const u8 P802_1H_OUI[P80211_OUI_LEN] = {0x00, 0x00, 0xf8}; @@ -55,6 +56,7 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, sint i; struct xmit_buf *pxmitbuf; struct xmit_frame *pxframe; + int j; memset((unsigned char *)pxmitpriv, 0, sizeof(struct xmit_priv)); spin_lock_init(&pxmitpriv->lock); @@ -117,11 +119,8 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, _init_queue(&pxmitpriv->pending_xmitbuf_queue); pxmitpriv->pallocated_xmitbuf = kmalloc(NR_XMITBUFF * sizeof(struct xmit_buf) + 4, GFP_ATOMIC); - if (!pxmitpriv->pallocated_xmitbuf) { - kfree(pxmitpriv->pallocated_frame_buf); - pxmitpriv->pallocated_frame_buf = NULL; - return -ENOMEM; - } + if (!pxmitpriv->pallocated_xmitbuf) + goto clean_up_frame_buf; pxmitpriv->pxmitbuf = pxmitpriv->pallocated_xmitbuf + 4 - ((addr_t)(pxmitpriv->pallocated_xmitbuf) & 3); pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmitbuf; @@ -129,13 +128,17 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, INIT_LIST_HEAD(&pxmitbuf->list); pxmitbuf->pallocated_buf = kmalloc(MAX_XMITBUF_SZ + XMITBUF_ALIGN_SZ, GFP_ATOMIC); - if (!pxmitbuf->pallocated_buf) - return -ENOMEM; + if (!pxmitbuf->pallocated_buf) { + j = 0; + goto clean_up_alloc_buf; + } pxmitbuf->pbuf = pxmitbuf->pallocated_buf + XMITBUF_ALIGN_SZ - ((addr_t) (pxmitbuf->pallocated_buf) & (XMITBUF_ALIGN_SZ - 1)); - if (r8712_xmit_resource_alloc(padapter, pxmitbuf)) - return -ENOMEM; + if (r8712_xmit_resource_alloc(padapter, pxmitbuf)) { + j = 1; + goto clean_up_alloc_buf; + } list_add_tail(&pxmitbuf->list, &(pxmitpriv->free_xmitbuf_queue.queue)); pxmitbuf++; @@ -146,6 +149,28 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, init_hwxmits(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry); tasklet_setup(&pxmitpriv->xmit_tasklet, r8712_xmit_bh); return 0; + +clean_up_alloc_buf: + if (j) { + /* failure happened in r8712_xmit_resource_alloc() + * delete extra pxmitbuf->pallocated_buf + */ + kfree(pxmitbuf->pallocated_buf); + } + for (j = 0; j < i; j++) { + int k; + + pxmitbuf--; /* reset pointer */ + kfree(pxmitbuf->pallocated_buf); + for (k = 0; k < 8; k++) /* delete xmit urb's */ + usb_free_urb(pxmitbuf->pxmit_urb[k]); + } + kfree(pxmitpriv->pallocated_xmitbuf); + pxmitpriv->pallocated_xmitbuf = NULL; +clean_up_frame_buf: + kfree(pxmitpriv->pallocated_frame_buf); + pxmitpriv->pallocated_frame_buf = NULL; + return -ENOMEM; } void _free_xmit_priv(struct xmit_priv *pxmitpriv) diff --git a/drivers/staging/rtl8712/xmit_linux.c b/drivers/staging/rtl8712/xmit_linux.c index 132afbf49dde..ceb6b590b310 100644 --- a/drivers/staging/rtl8712/xmit_linux.c +++ b/drivers/staging/rtl8712/xmit_linux.c @@ -112,6 +112,12 @@ int r8712_xmit_resource_alloc(struct _adapter *padapter, for (i = 0; i < 8; i++) { pxmitbuf->pxmit_urb[i] = usb_alloc_urb(0, GFP_KERNEL); if (!pxmitbuf->pxmit_urb[i]) { + int k; + + for (k = i - 1; k >= 0; k--) { + /* handle allocation errors part way through loop */ + usb_free_urb(pxmitbuf->pxmit_urb[k]); + } netdev_err(padapter->pnetdev, "pxmitbuf->pxmit_urb[i] == NULL\n"); return -ENOMEM; }

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] staging: r8712: Fix memory leak in _r8712_init_xmit_priv()" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x ac83631230f77dda94154ed0ebfd368fc81c70a3 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073115-depraved-mystify-ae16@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: ac83631230f7 ("staging: r8712: Fix memory leak in _r8712_init_xmit_priv()") f179515da978 ("staging: rtl8712: Use constants from <linux/ieee80211.h>") 0e934ce2904e ("staging: rtl8712: clean up comparsions to NULL") bd7a168a024d ("staging: rtl8712: use common ieee80211 constants") 3ee97e220648 ("staging: rtl8712: switch to common ieee80211 headers") 15ea976a1f12 ("staging: rtl8712: Fix IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK") 2aaeaaff1ae2 ("staging: rtl8712: code improvements to make_wlanhdr") 45afa5637b85 ("staging: rtl8712: fix long-line checkpatch warning") 5979afa2c4d1 ("staging: Replace zero-length array with flexible-array member") 96b06c0a16f7 ("Revert "staging: octeon-usb: delete the octeon usb host controller driver"") 4fb8b5aa2a11 ("staging: wilc1000: refactor p2p action frames handling API's") a474df5c1484 ("staging: wilc1000: remove use of vendor specific IE for p2p handling") 034280e33ea0 ("staging: wilc1000: refactor SPI read/write commands handling API's") 7a80aa23d0f0 ("staging: wilc1000: return zero on success and non-zero on function failure") 01fbbd42d1f4 ("staging: wilc1000: remove redundant assignment to variable result") 95ace52e4036 ("staging: octeon-usb: delete the octeon usb host controller driver") 710d7fbe21ee ("staging: octeon: delete driver") 075a1e87d1e2 ("staging/octeon: Mark Ethernet driver as BROKEN") 282eaa624f06 ("staging: octeon: indent with tabs instead of spaces") 6cfed5984804 ("staging: rtl*: Remove tasklet callback casts") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ac83631230f77dda94154ed0ebfd368fc81c70a3 Mon Sep 17 00:00:00 2001 From: Larry Finger <Larry.Finger(a)lwfinger.net> Date: Fri, 14 Jul 2023 12:54:17 -0500 Subject: [PATCH] staging: r8712: Fix memory leak in _r8712_init_xmit_priv() In the above mentioned routine, memory is allocated in several places. If the first succeeds and a later one fails, the routine will leak memory. This patch fixes commit 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel"). A potential memory leak in r8712_xmit_resource_alloc() is also addressed. Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel") Reported-by: syzbot+cf71097ffb6755df8251(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/x/log.txt?x=11ac3fa0a80000 Cc: stable(a)vger.kernel.org Cc: Nam Cao <namcaov(a)gmail.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Reviewed-by: Nam Cao <namcaov(a)gmail.com> Link: https://lore.kernel.org/r/20230714175417.18578-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c b/drivers/staging/rtl8712/rtl871x_xmit.c index 090345bad223..6353dbe554d3 100644 --- a/drivers/staging/rtl8712/rtl871x_xmit.c +++ b/drivers/staging/rtl8712/rtl871x_xmit.c @@ -21,6 +21,7 @@ #include "osdep_intf.h" #include "usb_ops.h" +#include <linux/usb.h> #include <linux/ieee80211.h> static const u8 P802_1H_OUI[P80211_OUI_LEN] = {0x00, 0x00, 0xf8}; @@ -55,6 +56,7 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, sint i; struct xmit_buf *pxmitbuf; struct xmit_frame *pxframe; + int j; memset((unsigned char *)pxmitpriv, 0, sizeof(struct xmit_priv)); spin_lock_init(&pxmitpriv->lock); @@ -117,11 +119,8 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, _init_queue(&pxmitpriv->pending_xmitbuf_queue); pxmitpriv->pallocated_xmitbuf = kmalloc(NR_XMITBUFF * sizeof(struct xmit_buf) + 4, GFP_ATOMIC); - if (!pxmitpriv->pallocated_xmitbuf) { - kfree(pxmitpriv->pallocated_frame_buf); - pxmitpriv->pallocated_frame_buf = NULL; - return -ENOMEM; - } + if (!pxmitpriv->pallocated_xmitbuf) + goto clean_up_frame_buf; pxmitpriv->pxmitbuf = pxmitpriv->pallocated_xmitbuf + 4 - ((addr_t)(pxmitpriv->pallocated_xmitbuf) & 3); pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmitbuf; @@ -129,13 +128,17 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, INIT_LIST_HEAD(&pxmitbuf->list); pxmitbuf->pallocated_buf = kmalloc(MAX_XMITBUF_SZ + XMITBUF_ALIGN_SZ, GFP_ATOMIC); - if (!pxmitbuf->pallocated_buf) - return -ENOMEM; + if (!pxmitbuf->pallocated_buf) { + j = 0; + goto clean_up_alloc_buf; + } pxmitbuf->pbuf = pxmitbuf->pallocated_buf + XMITBUF_ALIGN_SZ - ((addr_t) (pxmitbuf->pallocated_buf) & (XMITBUF_ALIGN_SZ - 1)); - if (r8712_xmit_resource_alloc(padapter, pxmitbuf)) - return -ENOMEM; + if (r8712_xmit_resource_alloc(padapter, pxmitbuf)) { + j = 1; + goto clean_up_alloc_buf; + } list_add_tail(&pxmitbuf->list, &(pxmitpriv->free_xmitbuf_queue.queue)); pxmitbuf++; @@ -146,6 +149,28 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, init_hwxmits(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry); tasklet_setup(&pxmitpriv->xmit_tasklet, r8712_xmit_bh); return 0; + +clean_up_alloc_buf: + if (j) { + /* failure happened in r8712_xmit_resource_alloc() + * delete extra pxmitbuf->pallocated_buf + */ + kfree(pxmitbuf->pallocated_buf); + } + for (j = 0; j < i; j++) { + int k; + + pxmitbuf--; /* reset pointer */ + kfree(pxmitbuf->pallocated_buf); + for (k = 0; k < 8; k++) /* delete xmit urb's */ + usb_free_urb(pxmitbuf->pxmit_urb[k]); + } + kfree(pxmitpriv->pallocated_xmitbuf); + pxmitpriv->pallocated_xmitbuf = NULL; +clean_up_frame_buf: + kfree(pxmitpriv->pallocated_frame_buf); + pxmitpriv->pallocated_frame_buf = NULL; + return -ENOMEM; } void _free_xmit_priv(struct xmit_priv *pxmitpriv) diff --git a/drivers/staging/rtl8712/xmit_linux.c b/drivers/staging/rtl8712/xmit_linux.c index 132afbf49dde..ceb6b590b310 100644 --- a/drivers/staging/rtl8712/xmit_linux.c +++ b/drivers/staging/rtl8712/xmit_linux.c @@ -112,6 +112,12 @@ int r8712_xmit_resource_alloc(struct _adapter *padapter, for (i = 0; i < 8; i++) { pxmitbuf->pxmit_urb[i] = usb_alloc_urb(0, GFP_KERNEL); if (!pxmitbuf->pxmit_urb[i]) { + int k; + + for (k = i - 1; k >= 0; k--) { + /* handle allocation errors part way through loop */ + usb_free_urb(pxmitbuf->pxmit_urb[k]); + } netdev_err(padapter->pnetdev, "pxmitbuf->pxmit_urb[i] == NULL\n"); return -ENOMEM; }

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] staging: r8712: Fix memory leak in _r8712_init_xmit_priv()" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x ac83631230f77dda94154ed0ebfd368fc81c70a3 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073114-salute-rust-a0f4@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: ac83631230f7 ("staging: r8712: Fix memory leak in _r8712_init_xmit_priv()") f179515da978 ("staging: rtl8712: Use constants from <linux/ieee80211.h>") 0e934ce2904e ("staging: rtl8712: clean up comparsions to NULL") bd7a168a024d ("staging: rtl8712: use common ieee80211 constants") 3ee97e220648 ("staging: rtl8712: switch to common ieee80211 headers") 15ea976a1f12 ("staging: rtl8712: Fix IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK") 2aaeaaff1ae2 ("staging: rtl8712: code improvements to make_wlanhdr") 45afa5637b85 ("staging: rtl8712: fix long-line checkpatch warning") 5979afa2c4d1 ("staging: Replace zero-length array with flexible-array member") 96b06c0a16f7 ("Revert "staging: octeon-usb: delete the octeon usb host controller driver"") 4fb8b5aa2a11 ("staging: wilc1000: refactor p2p action frames handling API's") a474df5c1484 ("staging: wilc1000: remove use of vendor specific IE for p2p handling") 034280e33ea0 ("staging: wilc1000: refactor SPI read/write commands handling API's") 7a80aa23d0f0 ("staging: wilc1000: return zero on success and non-zero on function failure") 01fbbd42d1f4 ("staging: wilc1000: remove redundant assignment to variable result") 95ace52e4036 ("staging: octeon-usb: delete the octeon usb host controller driver") 710d7fbe21ee ("staging: octeon: delete driver") 075a1e87d1e2 ("staging/octeon: Mark Ethernet driver as BROKEN") 282eaa624f06 ("staging: octeon: indent with tabs instead of spaces") 6cfed5984804 ("staging: rtl*: Remove tasklet callback casts") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ac83631230f77dda94154ed0ebfd368fc81c70a3 Mon Sep 17 00:00:00 2001 From: Larry Finger <Larry.Finger(a)lwfinger.net> Date: Fri, 14 Jul 2023 12:54:17 -0500 Subject: [PATCH] staging: r8712: Fix memory leak in _r8712_init_xmit_priv() In the above mentioned routine, memory is allocated in several places. If the first succeeds and a later one fails, the routine will leak memory. This patch fixes commit 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel"). A potential memory leak in r8712_xmit_resource_alloc() is also addressed. Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel") Reported-by: syzbot+cf71097ffb6755df8251(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/x/log.txt?x=11ac3fa0a80000 Cc: stable(a)vger.kernel.org Cc: Nam Cao <namcaov(a)gmail.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Reviewed-by: Nam Cao <namcaov(a)gmail.com> Link: https://lore.kernel.org/r/20230714175417.18578-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c b/drivers/staging/rtl8712/rtl871x_xmit.c index 090345bad223..6353dbe554d3 100644 --- a/drivers/staging/rtl8712/rtl871x_xmit.c +++ b/drivers/staging/rtl8712/rtl871x_xmit.c @@ -21,6 +21,7 @@ #include "osdep_intf.h" #include "usb_ops.h" +#include <linux/usb.h> #include <linux/ieee80211.h> static const u8 P802_1H_OUI[P80211_OUI_LEN] = {0x00, 0x00, 0xf8}; @@ -55,6 +56,7 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, sint i; struct xmit_buf *pxmitbuf; struct xmit_frame *pxframe; + int j; memset((unsigned char *)pxmitpriv, 0, sizeof(struct xmit_priv)); spin_lock_init(&pxmitpriv->lock); @@ -117,11 +119,8 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, _init_queue(&pxmitpriv->pending_xmitbuf_queue); pxmitpriv->pallocated_xmitbuf = kmalloc(NR_XMITBUFF * sizeof(struct xmit_buf) + 4, GFP_ATOMIC); - if (!pxmitpriv->pallocated_xmitbuf) { - kfree(pxmitpriv->pallocated_frame_buf); - pxmitpriv->pallocated_frame_buf = NULL; - return -ENOMEM; - } + if (!pxmitpriv->pallocated_xmitbuf) + goto clean_up_frame_buf; pxmitpriv->pxmitbuf = pxmitpriv->pallocated_xmitbuf + 4 - ((addr_t)(pxmitpriv->pallocated_xmitbuf) & 3); pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmitbuf; @@ -129,13 +128,17 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, INIT_LIST_HEAD(&pxmitbuf->list); pxmitbuf->pallocated_buf = kmalloc(MAX_XMITBUF_SZ + XMITBUF_ALIGN_SZ, GFP_ATOMIC); - if (!pxmitbuf->pallocated_buf) - return -ENOMEM; + if (!pxmitbuf->pallocated_buf) { + j = 0; + goto clean_up_alloc_buf; + } pxmitbuf->pbuf = pxmitbuf->pallocated_buf + XMITBUF_ALIGN_SZ - ((addr_t) (pxmitbuf->pallocated_buf) & (XMITBUF_ALIGN_SZ - 1)); - if (r8712_xmit_resource_alloc(padapter, pxmitbuf)) - return -ENOMEM; + if (r8712_xmit_resource_alloc(padapter, pxmitbuf)) { + j = 1; + goto clean_up_alloc_buf; + } list_add_tail(&pxmitbuf->list, &(pxmitpriv->free_xmitbuf_queue.queue)); pxmitbuf++; @@ -146,6 +149,28 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, init_hwxmits(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry); tasklet_setup(&pxmitpriv->xmit_tasklet, r8712_xmit_bh); return 0; + +clean_up_alloc_buf: + if (j) { + /* failure happened in r8712_xmit_resource_alloc() + * delete extra pxmitbuf->pallocated_buf + */ + kfree(pxmitbuf->pallocated_buf); + } + for (j = 0; j < i; j++) { + int k; + + pxmitbuf--; /* reset pointer */ + kfree(pxmitbuf->pallocated_buf); + for (k = 0; k < 8; k++) /* delete xmit urb's */ + usb_free_urb(pxmitbuf->pxmit_urb[k]); + } + kfree(pxmitpriv->pallocated_xmitbuf); + pxmitpriv->pallocated_xmitbuf = NULL; +clean_up_frame_buf: + kfree(pxmitpriv->pallocated_frame_buf); + pxmitpriv->pallocated_frame_buf = NULL; + return -ENOMEM; } void _free_xmit_priv(struct xmit_priv *pxmitpriv) diff --git a/drivers/staging/rtl8712/xmit_linux.c b/drivers/staging/rtl8712/xmit_linux.c index 132afbf49dde..ceb6b590b310 100644 --- a/drivers/staging/rtl8712/xmit_linux.c +++ b/drivers/staging/rtl8712/xmit_linux.c @@ -112,6 +112,12 @@ int r8712_xmit_resource_alloc(struct _adapter *padapter, for (i = 0; i < 8; i++) { pxmitbuf->pxmit_urb[i] = usb_alloc_urb(0, GFP_KERNEL); if (!pxmitbuf->pxmit_urb[i]) { + int k; + + for (k = i - 1; k >= 0; k--) { + /* handle allocation errors part way through loop */ + usb_free_urb(pxmitbuf->pxmit_urb[k]); + } netdev_err(padapter->pnetdev, "pxmitbuf->pxmit_urb[i] == NULL\n"); return -ENOMEM; }

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] staging: r8712: Fix memory leak in _r8712_init_xmit_priv()" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x ac83631230f77dda94154ed0ebfd368fc81c70a3 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073112-ice-reselect-6391@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: ac83631230f7 ("staging: r8712: Fix memory leak in _r8712_init_xmit_priv()") f179515da978 ("staging: rtl8712: Use constants from <linux/ieee80211.h>") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ac83631230f77dda94154ed0ebfd368fc81c70a3 Mon Sep 17 00:00:00 2001 From: Larry Finger <Larry.Finger(a)lwfinger.net> Date: Fri, 14 Jul 2023 12:54:17 -0500 Subject: [PATCH] staging: r8712: Fix memory leak in _r8712_init_xmit_priv() In the above mentioned routine, memory is allocated in several places. If the first succeeds and a later one fails, the routine will leak memory. This patch fixes commit 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel"). A potential memory leak in r8712_xmit_resource_alloc() is also addressed. Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel") Reported-by: syzbot+cf71097ffb6755df8251(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/x/log.txt?x=11ac3fa0a80000 Cc: stable(a)vger.kernel.org Cc: Nam Cao <namcaov(a)gmail.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Reviewed-by: Nam Cao <namcaov(a)gmail.com> Link: https://lore.kernel.org/r/20230714175417.18578-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c b/drivers/staging/rtl8712/rtl871x_xmit.c index 090345bad223..6353dbe554d3 100644 --- a/drivers/staging/rtl8712/rtl871x_xmit.c +++ b/drivers/staging/rtl8712/rtl871x_xmit.c @@ -21,6 +21,7 @@ #include "osdep_intf.h" #include "usb_ops.h" +#include <linux/usb.h> #include <linux/ieee80211.h> static const u8 P802_1H_OUI[P80211_OUI_LEN] = {0x00, 0x00, 0xf8}; @@ -55,6 +56,7 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, sint i; struct xmit_buf *pxmitbuf; struct xmit_frame *pxframe; + int j; memset((unsigned char *)pxmitpriv, 0, sizeof(struct xmit_priv)); spin_lock_init(&pxmitpriv->lock); @@ -117,11 +119,8 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, _init_queue(&pxmitpriv->pending_xmitbuf_queue); pxmitpriv->pallocated_xmitbuf = kmalloc(NR_XMITBUFF * sizeof(struct xmit_buf) + 4, GFP_ATOMIC); - if (!pxmitpriv->pallocated_xmitbuf) { - kfree(pxmitpriv->pallocated_frame_buf); - pxmitpriv->pallocated_frame_buf = NULL; - return -ENOMEM; - } + if (!pxmitpriv->pallocated_xmitbuf) + goto clean_up_frame_buf; pxmitpriv->pxmitbuf = pxmitpriv->pallocated_xmitbuf + 4 - ((addr_t)(pxmitpriv->pallocated_xmitbuf) & 3); pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmitbuf; @@ -129,13 +128,17 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, INIT_LIST_HEAD(&pxmitbuf->list); pxmitbuf->pallocated_buf = kmalloc(MAX_XMITBUF_SZ + XMITBUF_ALIGN_SZ, GFP_ATOMIC); - if (!pxmitbuf->pallocated_buf) - return -ENOMEM; + if (!pxmitbuf->pallocated_buf) { + j = 0; + goto clean_up_alloc_buf; + } pxmitbuf->pbuf = pxmitbuf->pallocated_buf + XMITBUF_ALIGN_SZ - ((addr_t) (pxmitbuf->pallocated_buf) & (XMITBUF_ALIGN_SZ - 1)); - if (r8712_xmit_resource_alloc(padapter, pxmitbuf)) - return -ENOMEM; + if (r8712_xmit_resource_alloc(padapter, pxmitbuf)) { + j = 1; + goto clean_up_alloc_buf; + } list_add_tail(&pxmitbuf->list, &(pxmitpriv->free_xmitbuf_queue.queue)); pxmitbuf++; @@ -146,6 +149,28 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv, init_hwxmits(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry); tasklet_setup(&pxmitpriv->xmit_tasklet, r8712_xmit_bh); return 0; + +clean_up_alloc_buf: + if (j) { + /* failure happened in r8712_xmit_resource_alloc() + * delete extra pxmitbuf->pallocated_buf + */ + kfree(pxmitbuf->pallocated_buf); + } + for (j = 0; j < i; j++) { + int k; + + pxmitbuf--; /* reset pointer */ + kfree(pxmitbuf->pallocated_buf); + for (k = 0; k < 8; k++) /* delete xmit urb's */ + usb_free_urb(pxmitbuf->pxmit_urb[k]); + } + kfree(pxmitpriv->pallocated_xmitbuf); + pxmitpriv->pallocated_xmitbuf = NULL; +clean_up_frame_buf: + kfree(pxmitpriv->pallocated_frame_buf); + pxmitpriv->pallocated_frame_buf = NULL; + return -ENOMEM; } void _free_xmit_priv(struct xmit_priv *pxmitpriv) diff --git a/drivers/staging/rtl8712/xmit_linux.c b/drivers/staging/rtl8712/xmit_linux.c index 132afbf49dde..ceb6b590b310 100644 --- a/drivers/staging/rtl8712/xmit_linux.c +++ b/drivers/staging/rtl8712/xmit_linux.c @@ -112,6 +112,12 @@ int r8712_xmit_resource_alloc(struct _adapter *padapter, for (i = 0; i < 8; i++) { pxmitbuf->pxmit_urb[i] = usb_alloc_urb(0, GFP_KERNEL); if (!pxmitbuf->pxmit_urb[i]) { + int k; + + for (k = i - 1; k >= 0; k--) { + /* handle allocation errors part way through loop */ + usb_free_urb(pxmitbuf->pxmit_urb[k]); + } netdev_err(padapter->pnetdev, "pxmitbuf->pxmit_urb[i] == NULL\n"); return -ENOMEM; }

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] serial: 8250_dw: Preserve original value of DLF register" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 748c5ea8b8796ae8ee80b8d3a3d940570b588d59 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073141-suspend-gloss-a42a@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 748c5ea8b879 ("serial: 8250_dw: Preserve original value of DLF register") 136e0ab99b22 ("serial: 8250_dw: split Synopsys DesignWare 8250 common functions") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 748c5ea8b8796ae8ee80b8d3a3d940570b588d59 Mon Sep 17 00:00:00 2001 From: Ruihong Luo <colorsu1922(a)gmail.com> Date: Thu, 13 Jul 2023 08:42:36 +0800 Subject: [PATCH] serial: 8250_dw: Preserve original value of DLF register MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Preserve the original value of the Divisor Latch Fraction (DLF) register. When the DLF register is modified without preservation, it can disrupt the baudrate settings established by firmware or bootloader, leading to data corruption and the generation of unreadable or distorted characters. Fixes: 701c5e73b296 ("serial: 8250_dw: add fractional divisor support") Cc: stable <stable(a)kernel.org> Signed-off-by: Ruihong Luo <colorsu1922(a)gmail.com> Link: https://lore.kernel.org/stable/20230713004235.35904-1-colorsu1922%40gmail.c… Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Link: https://lore.kernel.org/r/20230713004235.35904-1-colorsu1922@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/8250/8250_dwlib.c b/drivers/tty/serial/8250/8250_dwlib.c index 75f32f054ebb..84843e204a5e 100644 --- a/drivers/tty/serial/8250/8250_dwlib.c +++ b/drivers/tty/serial/8250/8250_dwlib.c @@ -244,7 +244,7 @@ void dw8250_setup_port(struct uart_port *p) struct dw8250_port_data *pd = p->private_data; struct dw8250_data *data = to_dw8250_data(pd); struct uart_8250_port *up = up_to_u8250p(p); - u32 reg; + u32 reg, old_dlf; pd->hw_rs485_support = dw8250_detect_rs485_hw(p); if (pd->hw_rs485_support) { @@ -270,9 +270,11 @@ void dw8250_setup_port(struct uart_port *p) dev_dbg(p->dev, "Designware UART version %c.%c%c\n", (reg >> 24) & 0xff, (reg >> 16) & 0xff, (reg >> 8) & 0xff); + /* Preserve value written by firmware or bootloader */ + old_dlf = dw8250_readl_ext(p, DW_UART_DLF); dw8250_writel_ext(p, DW_UART_DLF, ~0U); reg = dw8250_readl_ext(p, DW_UART_DLF); - dw8250_writel_ext(p, DW_UART_DLF, 0); + dw8250_writel_ext(p, DW_UART_DLF, old_dlf); if (reg) { pd->dlf_size = fls(reg);

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] KVM: x86: Disallow KVM_SET_SREGS{2} if incoming CR0 is" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 26a0652cb453c72f6aab0974bc4939e9b14f886b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073143-juggle-brussels-4fcc@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 26a0652cb453 ("KVM: x86: Disallow KVM_SET_SREGS{2} if incoming CR0 is invalid") e4fc23bad813 ("KVM: x86: remove KVM_X86_OP_NULL and mark optional kvm_x86_ops") 8a2897853c53 ("KVM: x86: return 1 unconditionally for availability of KVM_CAP_VAPIC") 03d004cd0715 ("KVM: x86: Use more verbose names for mem encrypt kvm_x86_ops hooks") 872e0c5308d1 ("KVM: x86: Move get_cs_db_l_bits() helper to SVM") 58fccda47e4b ("KVM: VMX: Rename VMX functions to conform to kvm_x86_ops names") 7ad02ef0da25 ("KVM: x86: Use static_call() for copy/move encryption context ioctls()") a0941a64a97d ("KVM: x86: Use static_call() for .vcpu_deliver_sipi_vector()") e27bc0440ebd ("KVM: x86: Rename kvm_x86_ops pointers to align w/ preferred vendor names") 57dfd7b53dec ("KVM: x86: Move delivery of non-APICv interrupt into vendor code") dd6e63122018 ("KVM: x86: add system attribute to retrieve full set of supported xsave states") c3e8abf0f353 ("KVM: x86: Remove defunct pre_block/post_block kvm_x86_ops hooks") 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86") d76fb40637fc ("KVM: VMX: Handle PI descriptor updates during vcpu_put/load") 4f5a884fc212 ("Merge branch 'kvm-pi-raw-spinlock' into HEAD") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 26a0652cb453c72f6aab0974bc4939e9b14f886b Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc(a)google.com> Date: Tue, 13 Jun 2023 13:30:35 -0700 Subject: [PATCH] KVM: x86: Disallow KVM_SET_SREGS{2} if incoming CR0 is invalid Reject KVM_SET_SREGS{2} with -EINVAL if the incoming CR0 is invalid, e.g. due to setting bits 63:32, illegal combinations, or to a value that isn't allowed in VMX (non-)root mode. The VMX checks in particular are "fun" as failure to disallow Real Mode for an L2 that is configured with unrestricted guest disabled, when KVM itself has unrestricted guest enabled, will result in KVM forcing VM86 mode to virtual Real Mode for L2, but then fail to unwind the related metadata when synthesizing a nested VM-Exit back to L1 (which has unrestricted guest enabled). Opportunistically fix a benign typo in the prototype for is_valid_cr4(). Cc: stable(a)vger.kernel.org Reported-by: syzbot+5feef0b9ee9c8e9e5689(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000f316b705fdf6e2b4@google.com Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20230613203037.1968489-2-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/include/asm/kvm-x86-ops.h b/arch/x86/include/asm/kvm-x86-ops.h index 13bc212cd4bc..e3054e3e46d5 100644 --- a/arch/x86/include/asm/kvm-x86-ops.h +++ b/arch/x86/include/asm/kvm-x86-ops.h @@ -37,6 +37,7 @@ KVM_X86_OP(get_segment) KVM_X86_OP(get_cpl) KVM_X86_OP(set_segment) KVM_X86_OP(get_cs_db_l_bits) +KVM_X86_OP(is_valid_cr0) KVM_X86_OP(set_cr0) KVM_X86_OP_OPTIONAL(post_set_cr3) KVM_X86_OP(is_valid_cr4) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 28bd38303d70..3bc146dfd38d 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1566,9 +1566,10 @@ struct kvm_x86_ops { void (*set_segment)(struct kvm_vcpu *vcpu, struct kvm_segment *var, int seg); void (*get_cs_db_l_bits)(struct kvm_vcpu *vcpu, int *db, int *l); + bool (*is_valid_cr0)(struct kvm_vcpu *vcpu, unsigned long cr0); void (*set_cr0)(struct kvm_vcpu *vcpu, unsigned long cr0); void (*post_set_cr3)(struct kvm_vcpu *vcpu, unsigned long cr3); - bool (*is_valid_cr4)(struct kvm_vcpu *vcpu, unsigned long cr0); + bool (*is_valid_cr4)(struct kvm_vcpu *vcpu, unsigned long cr4); void (*set_cr4)(struct kvm_vcpu *vcpu, unsigned long cr4); int (*set_efer)(struct kvm_vcpu *vcpu, u64 efer); void (*get_idt)(struct kvm_vcpu *vcpu, struct desc_ptr *dt); diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index cea08e5fa69b..956726d867aa 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -1786,6 +1786,11 @@ static void sev_post_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3) } } +static bool svm_is_valid_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) +{ + return true; +} + void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) { struct vcpu_svm *svm = to_svm(vcpu); @@ -4809,6 +4814,7 @@ static struct kvm_x86_ops svm_x86_ops __initdata = { .set_segment = svm_set_segment, .get_cpl = svm_get_cpl, .get_cs_db_l_bits = svm_get_cs_db_l_bits, + .is_valid_cr0 = svm_is_valid_cr0, .set_cr0 = svm_set_cr0, .post_set_cr3 = sev_post_set_cr3, .is_valid_cr4 = svm_is_valid_cr4, diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 0dd4612b0ca2..3d011d62d969 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -3047,6 +3047,15 @@ static void enter_rmode(struct kvm_vcpu *vcpu) struct vcpu_vmx *vmx = to_vmx(vcpu); struct kvm_vmx *kvm_vmx = to_kvm_vmx(vcpu->kvm); + /* + * KVM should never use VM86 to virtualize Real Mode when L2 is active, + * as using VM86 is unnecessary if unrestricted guest is enabled, and + * if unrestricted guest is disabled, VM-Enter (from L1) with CR0.PG=0 + * should VM-Fail and KVM should reject userspace attempts to stuff + * CR0.PG=0 when L2 is active. + */ + WARN_ON_ONCE(is_guest_mode(vcpu)); + vmx_get_segment(vcpu, &vmx->rmode.segs[VCPU_SREG_TR], VCPU_SREG_TR); vmx_get_segment(vcpu, &vmx->rmode.segs[VCPU_SREG_ES], VCPU_SREG_ES); vmx_get_segment(vcpu, &vmx->rmode.segs[VCPU_SREG_DS], VCPU_SREG_DS); @@ -3236,6 +3245,17 @@ void ept_save_pdptrs(struct kvm_vcpu *vcpu) #define CR3_EXITING_BITS (CPU_BASED_CR3_LOAD_EXITING | \ CPU_BASED_CR3_STORE_EXITING) +static bool vmx_is_valid_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) +{ + if (is_guest_mode(vcpu)) + return nested_guest_cr0_valid(vcpu, cr0); + + if (to_vmx(vcpu)->nested.vmxon) + return nested_host_cr0_valid(vcpu, cr0); + + return true; +} + void vmx_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) { struct vcpu_vmx *vmx = to_vmx(vcpu); @@ -5375,18 +5395,11 @@ static int handle_set_cr0(struct kvm_vcpu *vcpu, unsigned long val) val = (val & ~vmcs12->cr0_guest_host_mask) | (vmcs12->guest_cr0 & vmcs12->cr0_guest_host_mask); - if (!nested_guest_cr0_valid(vcpu, val)) - return 1; - if (kvm_set_cr0(vcpu, val)) return 1; vmcs_writel(CR0_READ_SHADOW, orig_val); return 0; } else { - if (to_vmx(vcpu)->nested.vmxon && - !nested_host_cr0_valid(vcpu, val)) - return 1; - return kvm_set_cr0(vcpu, val); } } @@ -8214,6 +8227,7 @@ static struct kvm_x86_ops vmx_x86_ops __initdata = { .set_segment = vmx_set_segment, .get_cpl = vmx_get_cpl, .get_cs_db_l_bits = vmx_get_cs_db_l_bits, + .is_valid_cr0 = vmx_is_valid_cr0, .set_cr0 = vmx_set_cr0, .is_valid_cr4 = vmx_is_valid_cr4, .set_cr4 = vmx_set_cr4, diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 27080bd986b5..278dbd37dab2 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -906,6 +906,22 @@ int load_pdptrs(struct kvm_vcpu *vcpu, unsigned long cr3) } EXPORT_SYMBOL_GPL(load_pdptrs); +static bool kvm_is_valid_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) +{ +#ifdef CONFIG_X86_64 + if (cr0 & 0xffffffff00000000UL) + return false; +#endif + + if ((cr0 & X86_CR0_NW) && !(cr0 & X86_CR0_CD)) + return false; + + if ((cr0 & X86_CR0_PG) && !(cr0 & X86_CR0_PE)) + return false; + + return static_call(kvm_x86_is_valid_cr0)(vcpu, cr0); +} + void kvm_post_set_cr0(struct kvm_vcpu *vcpu, unsigned long old_cr0, unsigned long cr0) { /* @@ -952,20 +968,13 @@ int kvm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) { unsigned long old_cr0 = kvm_read_cr0(vcpu); - cr0 |= X86_CR0_ET; - -#ifdef CONFIG_X86_64 - if (cr0 & 0xffffffff00000000UL) + if (!kvm_is_valid_cr0(vcpu, cr0)) return 1; -#endif - - cr0 &= ~CR0_RESERVED_BITS; - if ((cr0 & X86_CR0_NW) && !(cr0 & X86_CR0_CD)) - return 1; + cr0 |= X86_CR0_ET; - if ((cr0 & X86_CR0_PG) && !(cr0 & X86_CR0_PE)) - return 1; + /* Write to CR0 reserved bits are ignored, even on Intel. */ + cr0 &= ~CR0_RESERVED_BITS; #ifdef CONFIG_X86_64 if ((vcpu->arch.efer & EFER_LME) && !is_paging(vcpu) && @@ -11468,7 +11477,8 @@ static bool kvm_is_valid_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs) return false; } - return kvm_is_valid_cr4(vcpu, sregs->cr4); + return kvm_is_valid_cr4(vcpu, sregs->cr4) && + kvm_is_valid_cr0(vcpu, sregs->cr0); } static int __set_sregs_common(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs,

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] KVM: x86: Disallow KVM_SET_SREGS{2} if incoming CR0 is" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 26a0652cb453c72f6aab0974bc4939e9b14f886b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073105-jumbo-rug-5246@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 26a0652cb453 ("KVM: x86: Disallow KVM_SET_SREGS{2} if incoming CR0 is invalid") e4fc23bad813 ("KVM: x86: remove KVM_X86_OP_NULL and mark optional kvm_x86_ops") 8a2897853c53 ("KVM: x86: return 1 unconditionally for availability of KVM_CAP_VAPIC") 03d004cd0715 ("KVM: x86: Use more verbose names for mem encrypt kvm_x86_ops hooks") 872e0c5308d1 ("KVM: x86: Move get_cs_db_l_bits() helper to SVM") 58fccda47e4b ("KVM: VMX: Rename VMX functions to conform to kvm_x86_ops names") 7ad02ef0da25 ("KVM: x86: Use static_call() for copy/move encryption context ioctls()") a0941a64a97d ("KVM: x86: Use static_call() for .vcpu_deliver_sipi_vector()") e27bc0440ebd ("KVM: x86: Rename kvm_x86_ops pointers to align w/ preferred vendor names") 57dfd7b53dec ("KVM: x86: Move delivery of non-APICv interrupt into vendor code") dd6e63122018 ("KVM: x86: add system attribute to retrieve full set of supported xsave states") c3e8abf0f353 ("KVM: x86: Remove defunct pre_block/post_block kvm_x86_ops hooks") 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86") d76fb40637fc ("KVM: VMX: Handle PI descriptor updates during vcpu_put/load") 4f5a884fc212 ("Merge branch 'kvm-pi-raw-spinlock' into HEAD") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 26a0652cb453c72f6aab0974bc4939e9b14f886b Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc(a)google.com> Date: Tue, 13 Jun 2023 13:30:35 -0700 Subject: [PATCH] KVM: x86: Disallow KVM_SET_SREGS{2} if incoming CR0 is invalid Reject KVM_SET_SREGS{2} with -EINVAL if the incoming CR0 is invalid, e.g. due to setting bits 63:32, illegal combinations, or to a value that isn't allowed in VMX (non-)root mode. The VMX checks in particular are "fun" as failure to disallow Real Mode for an L2 that is configured with unrestricted guest disabled, when KVM itself has unrestricted guest enabled, will result in KVM forcing VM86 mode to virtual Real Mode for L2, but then fail to unwind the related metadata when synthesizing a nested VM-Exit back to L1 (which has unrestricted guest enabled). Opportunistically fix a benign typo in the prototype for is_valid_cr4(). Cc: stable(a)vger.kernel.org Reported-by: syzbot+5feef0b9ee9c8e9e5689(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000f316b705fdf6e2b4@google.com Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20230613203037.1968489-2-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/include/asm/kvm-x86-ops.h b/arch/x86/include/asm/kvm-x86-ops.h index 13bc212cd4bc..e3054e3e46d5 100644 --- a/arch/x86/include/asm/kvm-x86-ops.h +++ b/arch/x86/include/asm/kvm-x86-ops.h @@ -37,6 +37,7 @@ KVM_X86_OP(get_segment) KVM_X86_OP(get_cpl) KVM_X86_OP(set_segment) KVM_X86_OP(get_cs_db_l_bits) +KVM_X86_OP(is_valid_cr0) KVM_X86_OP(set_cr0) KVM_X86_OP_OPTIONAL(post_set_cr3) KVM_X86_OP(is_valid_cr4) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 28bd38303d70..3bc146dfd38d 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1566,9 +1566,10 @@ struct kvm_x86_ops { void (*set_segment)(struct kvm_vcpu *vcpu, struct kvm_segment *var, int seg); void (*get_cs_db_l_bits)(struct kvm_vcpu *vcpu, int *db, int *l); + bool (*is_valid_cr0)(struct kvm_vcpu *vcpu, unsigned long cr0); void (*set_cr0)(struct kvm_vcpu *vcpu, unsigned long cr0); void (*post_set_cr3)(struct kvm_vcpu *vcpu, unsigned long cr3); - bool (*is_valid_cr4)(struct kvm_vcpu *vcpu, unsigned long cr0); + bool (*is_valid_cr4)(struct kvm_vcpu *vcpu, unsigned long cr4); void (*set_cr4)(struct kvm_vcpu *vcpu, unsigned long cr4); int (*set_efer)(struct kvm_vcpu *vcpu, u64 efer); void (*get_idt)(struct kvm_vcpu *vcpu, struct desc_ptr *dt); diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index cea08e5fa69b..956726d867aa 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -1786,6 +1786,11 @@ static void sev_post_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3) } } +static bool svm_is_valid_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) +{ + return true; +} + void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) { struct vcpu_svm *svm = to_svm(vcpu); @@ -4809,6 +4814,7 @@ static struct kvm_x86_ops svm_x86_ops __initdata = { .set_segment = svm_set_segment, .get_cpl = svm_get_cpl, .get_cs_db_l_bits = svm_get_cs_db_l_bits, + .is_valid_cr0 = svm_is_valid_cr0, .set_cr0 = svm_set_cr0, .post_set_cr3 = sev_post_set_cr3, .is_valid_cr4 = svm_is_valid_cr4, diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 0dd4612b0ca2..3d011d62d969 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -3047,6 +3047,15 @@ static void enter_rmode(struct kvm_vcpu *vcpu) struct vcpu_vmx *vmx = to_vmx(vcpu); struct kvm_vmx *kvm_vmx = to_kvm_vmx(vcpu->kvm); + /* + * KVM should never use VM86 to virtualize Real Mode when L2 is active, + * as using VM86 is unnecessary if unrestricted guest is enabled, and + * if unrestricted guest is disabled, VM-Enter (from L1) with CR0.PG=0 + * should VM-Fail and KVM should reject userspace attempts to stuff + * CR0.PG=0 when L2 is active. + */ + WARN_ON_ONCE(is_guest_mode(vcpu)); + vmx_get_segment(vcpu, &vmx->rmode.segs[VCPU_SREG_TR], VCPU_SREG_TR); vmx_get_segment(vcpu, &vmx->rmode.segs[VCPU_SREG_ES], VCPU_SREG_ES); vmx_get_segment(vcpu, &vmx->rmode.segs[VCPU_SREG_DS], VCPU_SREG_DS); @@ -3236,6 +3245,17 @@ void ept_save_pdptrs(struct kvm_vcpu *vcpu) #define CR3_EXITING_BITS (CPU_BASED_CR3_LOAD_EXITING | \ CPU_BASED_CR3_STORE_EXITING) +static bool vmx_is_valid_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) +{ + if (is_guest_mode(vcpu)) + return nested_guest_cr0_valid(vcpu, cr0); + + if (to_vmx(vcpu)->nested.vmxon) + return nested_host_cr0_valid(vcpu, cr0); + + return true; +} + void vmx_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) { struct vcpu_vmx *vmx = to_vmx(vcpu); @@ -5375,18 +5395,11 @@ static int handle_set_cr0(struct kvm_vcpu *vcpu, unsigned long val) val = (val & ~vmcs12->cr0_guest_host_mask) | (vmcs12->guest_cr0 & vmcs12->cr0_guest_host_mask); - if (!nested_guest_cr0_valid(vcpu, val)) - return 1; - if (kvm_set_cr0(vcpu, val)) return 1; vmcs_writel(CR0_READ_SHADOW, orig_val); return 0; } else { - if (to_vmx(vcpu)->nested.vmxon && - !nested_host_cr0_valid(vcpu, val)) - return 1; - return kvm_set_cr0(vcpu, val); } } @@ -8214,6 +8227,7 @@ static struct kvm_x86_ops vmx_x86_ops __initdata = { .set_segment = vmx_set_segment, .get_cpl = vmx_get_cpl, .get_cs_db_l_bits = vmx_get_cs_db_l_bits, + .is_valid_cr0 = vmx_is_valid_cr0, .set_cr0 = vmx_set_cr0, .is_valid_cr4 = vmx_is_valid_cr4, .set_cr4 = vmx_set_cr4, diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 27080bd986b5..278dbd37dab2 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -906,6 +906,22 @@ int load_pdptrs(struct kvm_vcpu *vcpu, unsigned long cr3) } EXPORT_SYMBOL_GPL(load_pdptrs); +static bool kvm_is_valid_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) +{ +#ifdef CONFIG_X86_64 + if (cr0 & 0xffffffff00000000UL) + return false; +#endif + + if ((cr0 & X86_CR0_NW) && !(cr0 & X86_CR0_CD)) + return false; + + if ((cr0 & X86_CR0_PG) && !(cr0 & X86_CR0_PE)) + return false; + + return static_call(kvm_x86_is_valid_cr0)(vcpu, cr0); +} + void kvm_post_set_cr0(struct kvm_vcpu *vcpu, unsigned long old_cr0, unsigned long cr0) { /* @@ -952,20 +968,13 @@ int kvm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) { unsigned long old_cr0 = kvm_read_cr0(vcpu); - cr0 |= X86_CR0_ET; - -#ifdef CONFIG_X86_64 - if (cr0 & 0xffffffff00000000UL) + if (!kvm_is_valid_cr0(vcpu, cr0)) return 1; -#endif - - cr0 &= ~CR0_RESERVED_BITS; - if ((cr0 & X86_CR0_NW) && !(cr0 & X86_CR0_CD)) - return 1; + cr0 |= X86_CR0_ET; - if ((cr0 & X86_CR0_PG) && !(cr0 & X86_CR0_PE)) - return 1; + /* Write to CR0 reserved bits are ignored, even on Intel. */ + cr0 &= ~CR0_RESERVED_BITS; #ifdef CONFIG_X86_64 if ((vcpu->arch.efer & EFER_LME) && !is_paging(vcpu) && @@ -11468,7 +11477,8 @@ static bool kvm_is_valid_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs) return false; } - return kvm_is_valid_cr4(vcpu, sregs->cr4); + return kvm_is_valid_cr4(vcpu, sregs->cr4) && + kvm_is_valid_cr0(vcpu, sregs->cr0); } static int __set_sregs_common(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs,

2 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] KVM: VMX: Don't fudge CR0 and CR4 for restricted L2 guest" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x c4abd7352023aa96114915a0bb2b88016a425cda # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023073138-mortify-prozac-63fc@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: c4abd7352023 ("KVM: VMX: Don't fudge CR0 and CR4 for restricted L2 guest") 470750b34255 ("KVM: nVMX: Do not clear CR3 load/store exiting bits if L1 wants 'em") c834fd7fc130 ("KVM: VMX: Fold ept_update_paging_mode_cr0() back into vmx_set_cr0()") ee5a5584cba3 ("KVM: VMX: Invert handling of CR0.WP for EPT without unrestricted guest") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From c4abd7352023aa96114915a0bb2b88016a425cda Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc(a)google.com> Date: Tue, 13 Jun 2023 13:30:36 -0700 Subject: [PATCH] KVM: VMX: Don't fudge CR0 and CR4 for restricted L2 guest Stuff CR0 and/or CR4 to be compliant with a restricted guest if and only if KVM itself is not configured to utilize unrestricted guests, i.e. don't stuff CR0/CR4 for a restricted L2 that is running as the guest of an unrestricted L1. Any attempt to VM-Enter a restricted guest with invalid CR0/CR4 values should fail, i.e. in a nested scenario, KVM (as L0) should never observe a restricted L2 with incompatible CR0/CR4, since nested VM-Enter from L1 should have failed. And if KVM does observe an active, restricted L2 with incompatible state, e.g. due to a KVM bug, fudging CR0/CR4 instead of letting VM-Enter fail does more harm than good, as KVM will often neglect to undo the side effects, e.g. won't clear rmode.vm86_active on nested VM-Exit, and thus the damage can easily spill over to L1. On the other hand, letting VM-Enter fail due to bad guest state is more likely to contain the damage to L2 as KVM relies on hardware to perform most guest state consistency checks, i.e. KVM needs to be able to reflect a failed nested VM-Enter into L1 irrespective of (un)restricted guest behavior. Cc: Jim Mattson <jmattson(a)google.com> Cc: stable(a)vger.kernel.org Fixes: bddd82d19e2e ("KVM: nVMX: KVM needs to unset "unrestricted guest" VM-execution control in vmcs02 if vmcs12 doesn't set it") Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20230613203037.1968489-3-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 3d011d62d969..df461f387e20 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -1513,6 +1513,11 @@ void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags) struct vcpu_vmx *vmx = to_vmx(vcpu); unsigned long old_rflags; + /* + * Unlike CR0 and CR4, RFLAGS handling requires checking if the vCPU + * is an unrestricted guest in order to mark L2 as needing emulation + * if L1 runs L2 as a restricted guest. + */ if (is_unrestricted_guest(vcpu)) { kvm_register_mark_available(vcpu, VCPU_EXREG_RFLAGS); vmx->rflags = rflags; @@ -3265,7 +3270,7 @@ void vmx_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) old_cr0_pg = kvm_read_cr0_bits(vcpu, X86_CR0_PG); hw_cr0 = (cr0 & ~KVM_VM_CR0_ALWAYS_OFF); - if (is_unrestricted_guest(vcpu)) + if (enable_unrestricted_guest) hw_cr0 |= KVM_VM_CR0_ALWAYS_ON_UNRESTRICTED_GUEST; else { hw_cr0 |= KVM_VM_CR0_ALWAYS_ON; @@ -3293,7 +3298,7 @@ void vmx_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) } #endif - if (enable_ept && !is_unrestricted_guest(vcpu)) { + if (enable_ept && !enable_unrestricted_guest) { /* * Ensure KVM has an up-to-date snapshot of the guest's CR3. If * the below code _enables_ CR3 exiting, vmx_cache_reg() will @@ -3424,7 +3429,7 @@ void vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4) * this bit, even if host CR4.MCE == 0. */ hw_cr4 = (cr4_read_shadow() & X86_CR4_MCE) | (cr4 & ~X86_CR4_MCE); - if (is_unrestricted_guest(vcpu)) + if (enable_unrestricted_guest) hw_cr4 |= KVM_VM_CR4_ALWAYS_ON_UNRESTRICTED_GUEST; else if (vmx->rmode.vm86_active) hw_cr4 |= KVM_RMODE_VM_CR4_ALWAYS_ON; @@ -3444,7 +3449,7 @@ void vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4) vcpu->arch.cr4 = cr4; kvm_register_mark_available(vcpu, VCPU_EXREG_CR4); - if (!is_unrestricted_guest(vcpu)) { + if (!enable_unrestricted_guest) { if (enable_ept) { if (!is_paging(vcpu)) { hw_cr4 &= ~X86_CR4_PAE;

2 years, 2 months

1
0
0 0

[PATCH 0/3] Fix alignment issue and prepare for rust 1.71

by Boqun Feng

Hi Miguel, I end up with this series: (background: https://lore.kernel.org/rust-for-linux/CANiq72=pb18B6NOcXF03d0ctOP8kv2dqnUe…) Patch #1: introduces the core helper function that help calculate the correct size for krealloc(), and also use the helper function to fix `__rust_*` ones, this should be backported to stable kernels hence the Cc. Patch #2: use the helper function in KernelAllocator Patch #3: Bjorn's patch with correct use of the helper function. I have to add a few more SAFETY comments in these `__rust_*` functions, which may cause conflict with your 1.71 series. Since all previous patches get refactored a bit, I dropped all the Reviewed-bys, appreciate anyone to take a look, thanks! Regards, Boqun Björn Roy Baron (1): rust: alloc: Add realloc and alloc_zeroed to the GlobalAlloc impl Boqun Feng (2): rust: allocator: Prevent mis-aligned allocation rust: allocator: Use krealloc_aligned() in KernelAllocator::alloc rust/bindings/bindings_helper.h | 1 + rust/kernel/allocator.rs | 107 ++++++++++++++++++++++++++------ 2 files changed, 90 insertions(+), 18 deletions(-) -- 2.41.0

2 years, 2 months

6
12
0 0

[PATCH v1] usb: typec: tcpm: Fix response to vsafe0V event

by Badhri Jagan Sridharan

Do not transition to SNK_UNATTACHED state when receiving vsafe0v event while in SNK_HARD_RESET_WAIT_VBUS. Ignore VBUS off events as well as in some platforms VBUS off can be signalled more than once. [143515.364753] Requesting mux state 1, usb-role 2, orientation 2 [143515.365520] pending state change SNK_HARD_RESET_SINK_OFF -> SNK_HARD_RESET_SINK_ON @ 650 ms [rev3 HARD_RESET] [143515.632281] CC1: 0 -> 0, CC2: 3 -> 0 [state SNK_HARD_RESET_SINK_OFF, polarity 1, disconnected] [143515.637214] VBUS on [143515.664985] VBUS off [143515.664992] state change SNK_HARD_RESET_SINK_OFF -> SNK_HARD_RESET_WAIT_VBUS [rev3 HARD_RESET] [143515.665564] VBUS VSAFE0V [143515.665566] state change SNK_HARD_RESET_WAIT_VBUS -> SNK_UNATTACHED [rev3 HARD_RESET] Fixes: 28b43d3d746b ("usb: typec: tcpm: Introduce vsafe0v for vbus") Cc: <stable(a)vger.kernel.org> Signed-off-by: Badhri Jagan Sridharan <badhri(a)google.com> --- drivers/usb/typec/tcpm/tcpm.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 829d75ebab42..cc1d83926497 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -5349,6 +5349,10 @@ static void _tcpm_pd_vbus_off(struct tcpm_port *port) /* Do nothing, vbus drop expected */ break; + case SNK_HARD_RESET_WAIT_VBUS: + /* Do nothing, its OK to receive vbus off events */ + break; + default: if (port->pwr_role == TYPEC_SINK && port->attached) tcpm_set_state(port, SNK_UNATTACHED, tcpm_wait_for_discharge(port)); @@ -5395,6 +5399,9 @@ static void _tcpm_pd_vbus_vsafe0v(struct tcpm_port *port) case SNK_DEBOUNCED: /*Do nothing, still waiting for VSAFE5V for connect */ break; + case SNK_HARD_RESET_WAIT_VBUS: + /* Do nothing, its OK to receive vbus off events */ + break; default: if (port->pwr_role == TYPEC_SINK && port->auto_vbus_discharge_enabled) tcpm_set_state(port, SNK_UNATTACHED, 0); base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5 -- 2.41.0.255.g8b1d071c50-goog

2 years, 2 months

2
1
0 0

[PATCH 1/1] tpm: disable hwrng for fTPM on some AMD designs

by Mario Limonciello

AMD has issued an advisory indicating that having fTPM enabled in BIOS can cause "stuttering" in the OS. This issue has been fixed in newer versions of the fTPM firmware, but it's up to system designers to decide whether to distribute it. This issue has existed for a while, but is more prevalent starting with kernel 6.1 because commit b006c439d58db ("hwrng: core - start hwrng kthread also for untrusted sources") started to use the fTPM for hwrng by default. However, all uses of /dev/hwrng result in unacceptable stuttering. So, simply disable registration of the defective hwrng when detecting these faulty fTPM versions. Link: https://www.amd.com/en/support/kb/faq/pa-410 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216989 Link: https://lore.kernel.org/all/20230209153120.261904-1-Jason@zx2c4.com/ Fixes: b006c439d58d ("hwrng: core - start hwrng kthread also for untrusted sources") Cc: stable(a)vger.kernel.org Cc: Jarkko Sakkinen <jarkko(a)kernel.org> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Cc: James Bottomley <James.Bottomley(a)hansenpartnership.com> Co-developed-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> --- drivers/char/tpm/tpm-chip.c | 62 ++++++++++++++++++++++++++++++- drivers/char/tpm/tpm.h | 73 +++++++++++++++++++++++++++++++++++++ 2 files changed, 134 insertions(+), 1 deletion(-) diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c index 741d8f3e8fb3a..348dd5705fbb6 100644 --- a/drivers/char/tpm/tpm-chip.c +++ b/drivers/char/tpm/tpm-chip.c @@ -512,6 +512,65 @@ static int tpm_add_legacy_sysfs(struct tpm_chip *chip) return 0; } +static bool tpm_is_rng_defective(struct tpm_chip *chip) +{ + int ret; + u64 version; + u32 val1, val2; + + /* No known-broken TPM1 chips. */ + if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) + return false; + + ret = tpm_request_locality(chip); + if (ret) + return false; + + /* Some AMD fTPM versions may cause stutter */ + ret = tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val1, NULL); + if (ret) + goto release; + if (val1 != 0x414D4400U /* AMD */) { + ret = -ENODEV; + goto release; + } + ret = tpm2_get_tpm_pt(chip, TPM2_PT_FIRMWARE_VERSION_1, &val1, NULL); + if (ret) + goto release; + ret = tpm2_get_tpm_pt(chip, TPM2_PT_FIRMWARE_VERSION_2, &val2, NULL); + if (ret) + goto release; + +release: + tpm_relinquish_locality(chip); + + if (ret) + return false; + + version = ((u64)val1 << 32) | val2; + /* + * Fixes for stutter as described in + * https://www.amd.com/en/support/kb/faq/pa-410 + * are available in two series of fTPM firmware: + * 6.x.y.z series: 6.0.18.6 + + * 3.x.y.z series: 3.57.x.5 + + */ + if ((version >> 48) == 6) { + if (version >= 0x0006000000180006ULL) + return false; + } else if ((version >> 48) == 3) { + if (version >= 0x0003005700000005ULL) + return false; + } else { + return false; + } + dev_warn(&chip->dev, + "AMD fTPM version 0x%llx causes system stutter; hwrng disabled\n", + version); + + return true; +} + static int tpm_hwrng_read(struct hwrng *rng, void *data, size_t max, bool wait) { struct tpm_chip *chip = container_of(rng, struct tpm_chip, hwrng); @@ -521,7 +580,8 @@ static int tpm_hwrng_read(struct hwrng *rng, void *data, size_t max, bool wait) static int tpm_add_hwrng(struct tpm_chip *chip) { - if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM) || tpm_is_firmware_upgrade(chip)) + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM) || tpm_is_firmware_upgrade(chip) || + tpm_is_rng_defective(chip)) return 0; snprintf(chip->hwrng_name, sizeof(chip->hwrng_name), diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index 24ee4e1cc452a..830014a266090 100644 --- a/drivers/char/tpm/tpm.h +++ b/drivers/char/tpm/tpm.h @@ -150,6 +150,79 @@ enum tpm_sub_capabilities { TPM_CAP_PROP_TIS_DURATION = 0x120, }; +enum tpm2_pt_props { + TPM2_PT_NONE = 0x00000000, + TPM2_PT_GROUP = 0x00000100, + TPM2_PT_FIXED = TPM2_PT_GROUP * 1, + TPM2_PT_FAMILY_INDICATOR = TPM2_PT_FIXED + 0, + TPM2_PT_LEVEL = TPM2_PT_FIXED + 1, + TPM2_PT_REVISION = TPM2_PT_FIXED + 2, + TPM2_PT_DAY_OF_YEAR = TPM2_PT_FIXED + 3, + TPM2_PT_YEAR = TPM2_PT_FIXED + 4, + TPM2_PT_MANUFACTURER = TPM2_PT_FIXED + 5, + TPM2_PT_VENDOR_STRING_1 = TPM2_PT_FIXED + 6, + TPM2_PT_VENDOR_STRING_2 = TPM2_PT_FIXED + 7, + TPM2_PT_VENDOR_STRING_3 = TPM2_PT_FIXED + 8, + TPM2_PT_VENDOR_STRING_4 = TPM2_PT_FIXED + 9, + TPM2_PT_VENDOR_TPM_TYPE = TPM2_PT_FIXED + 10, + TPM2_PT_FIRMWARE_VERSION_1 = TPM2_PT_FIXED + 11, + TPM2_PT_FIRMWARE_VERSION_2 = TPM2_PT_FIXED + 12, + TPM2_PT_INPUT_BUFFER = TPM2_PT_FIXED + 13, + TPM2_PT_HR_TRANSIENT_MIN = TPM2_PT_FIXED + 14, + TPM2_PT_HR_PERSISTENT_MIN = TPM2_PT_FIXED + 15, + TPM2_PT_HR_LOADED_MIN = TPM2_PT_FIXED + 16, + TPM2_PT_ACTIVE_SESSIONS_MAX = TPM2_PT_FIXED + 17, + TPM2_PT_PCR_COUNT = TPM2_PT_FIXED + 18, + TPM2_PT_PCR_SELECT_MIN = TPM2_PT_FIXED + 19, + TPM2_PT_CONTEXT_GAP_MAX = TPM2_PT_FIXED + 20, + TPM2_PT_NV_COUNTERS_MAX = TPM2_PT_FIXED + 22, + TPM2_PT_NV_INDEX_MAX = TPM2_PT_FIXED + 23, + TPM2_PT_MEMORY = TPM2_PT_FIXED + 24, + TPM2_PT_CLOCK_UPDATE = TPM2_PT_FIXED + 25, + TPM2_PT_CONTEXT_HASH = TPM2_PT_FIXED + 26, + TPM2_PT_CONTEXT_SYM = TPM2_PT_FIXED + 27, + TPM2_PT_CONTEXT_SYM_SIZE = TPM2_PT_FIXED + 28, + TPM2_PT_ORDERLY_COUNT = TPM2_PT_FIXED + 29, + TPM2_PT_MAX_COMMAND_SIZE = TPM2_PT_FIXED + 30, + TPM2_PT_MAX_RESPONSE_SIZE = TPM2_PT_FIXED + 31, + TPM2_PT_MAX_DIGEST = TPM2_PT_FIXED + 32, + TPM2_PT_MAX_OBJECT_CONTEXT = TPM2_PT_FIXED + 33, + TPM2_PT_MAX_SESSION_CONTEXT = TPM2_PT_FIXED + 34, + TPM2_PT_PS_FAMILY_INDICATOR = TPM2_PT_FIXED + 35, + TPM2_PT_PS_LEVEL = TPM2_PT_FIXED + 36, + TPM2_PT_PS_REVISION = TPM2_PT_FIXED + 37, + TPM2_PT_PS_DAY_OF_YEAR = TPM2_PT_FIXED + 38, + TPM2_PT_PS_YEAR = TPM2_PT_FIXED + 39, + TPM2_PT_SPLIT_MAX = TPM2_PT_FIXED + 40, + TPM2_PT_TOTAL_COMMANDS = TPM2_PT_FIXED + 41, + TPM2_PT_LIBRARY_COMMANDS = TPM2_PT_FIXED + 42, + TPM2_PT_VENDOR_COMMANDS = TPM2_PT_FIXED + 43, + TPM2_PT_NV_BUFFER_MAX = TPM2_PT_FIXED + 44, + TPM2_PT_MODES = TPM2_PT_FIXED + 45, + TPM2_PT_MAX_CAP_BUFFER = TPM2_PT_FIXED + 46, + TPM2_PT_VAR = TPM2_PT_GROUP * 2, + TPM2_PT_PERMANENT = TPM2_PT_VAR + 0, + TPM2_PT_STARTUP_CLEAR = TPM2_PT_VAR + 1, + TPM2_PT_HR_NV_INDEX = TPM2_PT_VAR + 2, + TPM2_PT_HR_LOADED = TPM2_PT_VAR + 3, + TPM2_PT_HR_LOADED_AVAIL = TPM2_PT_VAR + 4, + TPM2_PT_HR_ACTIVE = TPM2_PT_VAR + 5, + TPM2_PT_HR_ACTIVE_AVAIL = TPM2_PT_VAR + 6, + TPM2_PT_HR_TRANSIENT_AVAIL = TPM2_PT_VAR + 7, + TPM2_PT_HR_PERSISTENT = TPM2_PT_VAR + 8, + TPM2_PT_HR_PERSISTENT_AVAIL = TPM2_PT_VAR + 9, + TPM2_PT_NV_COUNTERS = TPM2_PT_VAR + 10, + TPM2_PT_NV_COUNTERS_AVAIL = TPM2_PT_VAR + 11, + TPM2_PT_ALGORITHM_SET = TPM2_PT_VAR + 12, + TPM2_PT_LOADED_CURVES = TPM2_PT_VAR + 13, + TPM2_PT_LOCKOUT_COUNTER = TPM2_PT_VAR + 14, + TPM2_PT_MAX_AUTH_FAIL = TPM2_PT_VAR + 15, + TPM2_PT_LOCKOUT_INTERVAL = TPM2_PT_VAR + 16, + TPM2_PT_LOCKOUT_RECOVERY = TPM2_PT_VAR + 17, + TPM2_PT_NV_WRITE_RECOVERY = TPM2_PT_VAR + 18, + TPM2_PT_AUDIT_COUNTER_0 = TPM2_PT_VAR + 19, + TPM2_PT_AUDIT_COUNTER_1 = TPM2_PT_VAR + 20, +}; /* 128 bytes is an arbitrary cap. This could be as large as TPM_BUFSIZE - 18 * bytes, but 128 is still a relatively large number of random bytes and -- 2.25.1

2 years, 2 months

7
25
0 0

[PATCH] staging: rtl8712: fix race condition

by Nam Cao

In probe function, request_firmware_nowait() is called to load firmware asynchronously. At completion of firmware loading, register_netdev() is called. However, a mutex needed by netdev is initialized after the call to request_firmware_nowait(). Consequently, it can happen that register_netdev() is called before the driver is ready. Move the mutex initialization into r8712_init_drv_sw(), which is called before request_firmware_nowait(). Reported-by: syzbot+b08315e8cf5a78eed03c(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-staging/000000000000d9d4560601b8e0d7@google.c… Fixes: 8c213fa59199 ("staging: r8712u: Use asynchronous firmware loading") Cc: stable(a)vger.kernel.org Signed-off-by: Nam Cao <namcaov(a)gmail.com> --- drivers/staging/rtl8712/os_intfs.c | 1 + drivers/staging/rtl8712/usb_intf.c | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8712/os_intfs.c b/drivers/staging/rtl8712/os_intfs.c index a2f3645be0cc..b18e6d9c832b 100644 --- a/drivers/staging/rtl8712/os_intfs.c +++ b/drivers/staging/rtl8712/os_intfs.c @@ -327,6 +327,7 @@ int r8712_init_drv_sw(struct _adapter *padapter) mp871xinit(padapter); init_default_value(padapter); r8712_InitSwLeds(padapter); + mutex_init(&padapter->mutex_start); return 0; diff --git a/drivers/staging/rtl8712/usb_intf.c b/drivers/staging/rtl8712/usb_intf.c index 37364d3101e2..df05213f922f 100644 --- a/drivers/staging/rtl8712/usb_intf.c +++ b/drivers/staging/rtl8712/usb_intf.c @@ -567,7 +567,6 @@ static int r871xu_drv_init(struct usb_interface *pusb_intf, if (rtl871x_load_fw(padapter)) goto deinit_drv_sw; init_completion(&padapter->rx_filter_ready); - mutex_init(&padapter->mutex_start); return 0; deinit_drv_sw: -- 2.34.1

2 years, 2 months

1
0
0 0

[PATCH v2] riscv: Handle zicsr/zifencei issue between gcc and binutils

by Mingzheng Xing

Binutils-2.38 and GCC-12.1.0 bump[0] default ISA spec to newer version 20191213 which moves some instructions from the I extension to the Zicsr and Zifencei extensions. So if one of the binutils and GCC exceeds that version, we should turn on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI to cope with the new changes. The case of clang is special[1][2], where older clang versions (<17) need to be rolled back to old ISA spec to fix it. And the less common case, since older GCC versions (<11.1.0) did not support zicsr and zifencei extension for -march, also requires a fallback to cope with it. For more information, please refer to: commit 6df2a016c0c8 ("riscv: fix build with binutils 2.38") commit e89c2e815e76 ("riscv: Handle zicsr/zifencei issues between clang and binutils") Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51… [0] Link: https://lore.kernel.org/all/20230308220842.1231003-1-conor@kernel.org [1] Link: https://lore.kernel.org/all/20230223220546.52879-1-conor@kernel.org [2] Link: https://lore.kernel.org/all/20230725170405.251011-1-xingmingzheng@iscas.ac.… Signed-off-by: Mingzheng Xing <xingmingzheng(a)iscas.ac.cn> --- v2: - Update the Kconfig help text and commit message. - Add considerations for low version gcc case. Sorry for the formatting error on my mailing list reply. arch/riscv/Kconfig | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 4c07b9189c86..08afd47de157 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -570,24 +570,27 @@ config TOOLCHAIN_HAS_ZIHINTPAUSE config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI def_bool y # https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae871… - depends on AS_IS_GNU && AS_VERSION >= 23800 + # https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51… + depends on GCC_VERSION >= 120100 || (AS_IS_GNU && AS_VERSION >= 23800) help - Newer binutils versions default to ISA spec version 20191213 which - moves some instructions from the I extension to the Zicsr and Zifencei - extensions. + Binutils-2.38 and GCC-12.1.0 bump default ISA spec to newer version + 20191213 which moves some instructions from the I extension to the + Zicsr and Zifencei extensions. config TOOLCHAIN_NEEDS_OLD_ISA_SPEC def_bool y depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI # https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694… - depends on CC_IS_CLANG && CLANG_VERSION < 170000 + # https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b03be74bad08c382da47e048007a7… + depends on (CC_IS_CLANG && CLANG_VERSION < 170000) || \ + (CC_IS_GCC && GCC_VERSION < 110100) help - Certain versions of clang do not support zicsr and zifencei via -march - but newer versions of binutils require it for the reasons noted in the - help text of CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. This + Certain versions of clang (or GCC) do not support zicsr and zifencei via + -march but newer versions of binutils require it for the reasons noted + in the help text of CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. This option causes an older ISA spec compatible with these older versions - of clang to be passed to GAS, which has the same result as passing zicsr - and zifencei to -march. + of clang (or GCC) to be passed to GAS, which has the same result as + passing zicsr and zifencei to -march. config FPU bool "FPU support" -- 2.34.1

2 years, 2 months

3
8
0 0

[PATCH V5] PCI: qcom: Fixing broken pcie enumeration for 2_3_3 configs ops

by Sricharan Ramabadhran

PARF_SLV_ADDR_SPACE_SIZE_2_3_3 macro is used for IPQ8074 2_3_3 post_init. PCIe slave addr register offset is 0x358, but was wrongly changed to 0x168 as a part of commit 39171b33f652 ("PCI: qcom: Remove PCIE20_ prefix from register definitions"). Fixing it, by using the right macro and remove the unused PARF_SLV_ADDR_SPACE_SIZE_2_3_3. Without this access to the registers of slave addr space like iATU etc are broken leading to pcie enumeration failure. Fixes: 39171b33f652 ("PCI: qcom: Remove PCIE20_ prefix from register definitions") Cc: <Stable(a)vger.kernel.org> Reviewed-by: Manivannan Sadhasivam <mani(a)kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio(a)linaro.org> Signed-off-by: Sricharan Ramabadhran <quic_srichara(a)quicinc.com> --- [v5] Fixed subject, commit log [v4] Fix commit sub and added '<mani(a)kernel.org>' reviewed-by tag [v3] Added reviewed-by tag, fixed subject, commit text [v2] Fixed the 'fixes tag' correctly, subject, right macro usage drivers/pci/controller/dwc/pcie-qcom.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c index 4ab30892f6ef..8418894b3de7 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -43,7 +43,6 @@ #define PARF_PHY_REFCLK 0x4c #define PARF_CONFIG_BITS 0x50 #define PARF_DBI_BASE_ADDR 0x168 -#define PARF_SLV_ADDR_SPACE_SIZE_2_3_3 0x16c /* Register offset specific to IP ver 2.3.3 */ #define PARF_MHI_CLOCK_RESET_CTRL 0x174 #define PARF_AXI_MSTR_WR_ADDR_HALT 0x178 #define PARF_AXI_MSTR_WR_ADDR_HALT_V2 0x1a8 @@ -810,8 +809,7 @@ static int qcom_pcie_post_init_2_3_3(struct qcom_pcie *pcie) u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP); u32 val; - writel(SLV_ADDR_SPACE_SZ, - pcie->parf + PARF_SLV_ADDR_SPACE_SIZE_2_3_3); + writel(SLV_ADDR_SPACE_SZ, pcie->parf + PARF_SLV_ADDR_SPACE_SIZE); val = readl(pcie->parf + PARF_PHY_CTRL); val &= ~PHY_TEST_PWR_DOWN; -- 2.34.1

2 years, 2 months

3
2
0 0

Scsi_bus_resume+0x0/0x90 returns -5 when resuming from s3 sleep

by TW

I have been having issues with the 6.x series of kernels resuming from suspend with one of my drives. Far as I can tell it has trouble with the cache on the drive when coming out of s3 sleep. Tried a few different distros (Manjaro, OpenMandriva Rome, EndeavourOS) all that give the same error message. It appears to work fine on the 5.15 kernel just fine however. This is the error or errors that I have been getting and assume has been holding up the system from resuming from suspend. Jul 20 04:13:41 rageworks kernel: ata10.00: device reported invalid CHS sector 0 Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: [sdc] Start/Stop Unit failed: Result: hostbyte=DID_OK driverbyte=DRIVER_OK Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: [sdc] Sense Key : Illegal Request [current] Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: [sdc] Add. Sense: Unaligned write command Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: PM: dpm_run_callback(): scsi_bus_resume+0x0/0x90 returns -5 Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: PM: failed to resume async: error -5 The full suspend log. Jul 20 04:12:50 rageworks systemd-logind[869]: The system will suspend now! Jul 20 04:12:50 rageworks ModemManager[902]: <info> [sleep-monitor-systemd] system is about to suspend Jul 20 04:12:50 rageworks NetworkManager[894]: <info> [1689847970.4923] manager: sleep: sleep requested (sleeping: no enabled: yes) Jul 20 04:12:50 rageworks NetworkManager[894]: <info> [1689847970.4924] manager: NetworkManager state is now ASLEEP Jul 20 04:12:50 rageworks NetworkManager[894]: <info> [1689847970.4926] device (enp9s0): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed') Jul 20 04:12:50 rageworks dbus-daemon[866]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.6' (uid=0 pid=894 comm="/usr/bin/NetworkManager --no-daemon") Jul 20 04:12:50 rageworks systemd[1]: Starting Network Manager Script Dispatcher Service... Jul 20 04:12:50 rageworks dbus-daemon[866]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jul 20 04:12:50 rageworks systemd[1]: Started Network Manager Script Dispatcher Service. Jul 20 04:12:50 rageworks NetworkManager[894]: <info> [1689847970.6544] device (enp9s0): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'managed') Jul 20 04:12:50 rageworks avahi-daemon[864]: Withdrawing address record for fe80::881:c55d:1583:20f5 on enp9s0. Jul 20 04:12:50 rageworks avahi-daemon[864]: Leaving mDNS multicast group on interface enp9s0.IPv6 with address fe80::881:c55d:1583:20f5. Jul 20 04:12:50 rageworks avahi-daemon[864]: Interface enp9s0.IPv6 no longer relevant for mDNS. Jul 20 04:12:50 rageworks NetworkManager[894]: <info> [1689847970.6726] dhcp4 (enp9s0): canceled DHCP transaction Jul 20 04:12:50 rageworks NetworkManager[894]: <info> [1689847970.6726] dhcp4 (enp9s0): activation: beginning transaction (timeout in 45 seconds) Jul 20 04:12:50 rageworks NetworkManager[894]: <info> [1689847970.6727] dhcp4 (enp9s0): state changed no lease Jul 20 04:12:50 rageworks avahi-daemon[864]: Withdrawing address record for 192.168.1.3 on enp9s0. Jul 20 04:12:50 rageworks avahi-daemon[864]: Leaving mDNS multicast group on interface enp9s0.IPv4 with address 192.168.1.3. Jul 20 04:12:50 rageworks avahi-daemon[864]: Interface enp9s0.IPv4 no longer relevant for mDNS. Jul 20 04:12:50 rageworks NetworkManager[894]: <info> [1689847970.7576] device (enp9s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') Jul 20 04:12:50 rageworks kernel: r8169 0000:09:00.0 enp9s0: Link is Down Jul 20 04:12:50 rageworks systemd[1]: Reached target Sleep. Jul 20 04:12:50 rageworks systemd[1]: Starting NVIDIA system suspend actions... Jul 20 04:12:50 rageworks suspend[2051]: nvidia-suspend.service Jul 20 04:12:50 rageworks logger[2051]: <13>Jul 20 04:12:50 suspend: nvidia-suspend.service Jul 20 04:12:51 rageworks systemd[1]: nvidia-suspend.service: Deactivated successfully. Jul 20 04:12:51 rageworks systemd[1]: Finished NVIDIA system suspend actions. Jul 20 04:12:51 rageworks systemd[1]: Starting System Suspend... Jul 20 04:12:51 rageworks systemd-sleep[2059]: Entering sleep state 'suspend'... Jul 20 04:12:51 rageworks kernel: PM: suspend entry (deep) Jul 20 04:13:41 rageworks kernel: Filesystems sync: 0.284 seconds Jul 20 04:13:41 rageworks kernel: Freezing user space processes Jul 20 04:13:41 rageworks kernel: Freezing user space processes completed (elapsed 0.001 seconds) Jul 20 04:13:41 rageworks kernel: OOM killer disabled. Jul 20 04:13:41 rageworks kernel: Freezing remaining freezable tasks Jul 20 04:13:41 rageworks kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds) Jul 20 04:13:41 rageworks kernel: printk: Suspending console(s) (use no_console_suspend to debug) Jul 20 04:13:41 rageworks kernel: serial 00:05: disabled Jul 20 04:13:41 rageworks kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache Jul 20 04:13:41 rageworks kernel: sd 1:0:0:0: [sdb] Synchronizing SCSI cache Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: [sdc] Synchronizing SCSI cache Jul 20 04:13:41 rageworks kernel: sd 1:0:0:0: [sdb] Stopping disk Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: [sdc] Stopping disk Jul 20 04:13:41 rageworks kernel: sd 0:0:0:0: [sda] Stopping disk Jul 20 04:13:41 rageworks kernel: ACPI: PM: Preparing to enter system sleep state S3 Jul 20 04:13:41 rageworks kernel: ACPI: PM: Saving platform NVS memory Jul 20 04:13:41 rageworks kernel: Disabling non-boot CPUs ... Jul 20 04:13:41 rageworks kernel: smpboot: CPU 1 is now offline Jul 20 04:13:41 rageworks kernel: smpboot: CPU 2 is now offline Jul 20 04:13:41 rageworks kernel: smpboot: CPU 3 is now offline Jul 20 04:13:41 rageworks kernel: ACPI: PM: Low-level resume complete Jul 20 04:13:41 rageworks kernel: ACPI: PM: Restoring platform NVS memory Jul 20 04:13:41 rageworks kernel: Enabling non-boot CPUs ... Jul 20 04:13:41 rageworks kernel: x86: Booting SMP configuration: Jul 20 04:13:41 rageworks kernel: smpboot: Booting Node 0 Processor 1 APIC 0x1 Jul 20 04:13:41 rageworks kernel: microcode: CPU1: patch_level=0x08101016 Jul 20 04:13:41 rageworks kernel: CPU1 is up Jul 20 04:13:41 rageworks kernel: smpboot: Booting Node 0 Processor 2 APIC 0x2 Jul 20 04:13:41 rageworks kernel: microcode: CPU2: patch_level=0x08101016 Jul 20 04:13:41 rageworks kernel: CPU2 is up Jul 20 04:13:41 rageworks kernel: smpboot: Booting Node 0 Processor 3 APIC 0x3 Jul 20 04:13:41 rageworks kernel: microcode: CPU3: patch_level=0x08101016 Jul 20 04:13:41 rageworks kernel: CPU3 is up Jul 20 04:13:41 rageworks kernel: ACPI: PM: Waking up from system sleep state S3 Jul 20 04:13:41 rageworks kernel: xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit Jul 20 04:13:41 rageworks kernel: usb usb1: root hub lost power or was reset Jul 20 04:13:41 rageworks kernel: usb usb2: root hub lost power or was reset Jul 20 04:13:41 rageworks kernel: serial 00:05: activated Jul 20 04:13:41 rageworks kernel: sd 0:0:0:0: [sda] Starting disk Jul 20 04:13:41 rageworks kernel: sd 1:0:0:0: [sdb] Starting disk Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: [sdc] Starting disk Jul 20 04:13:41 rageworks kernel: ata5: SATA link down (SStatus 0 SControl 330) Jul 20 04:13:41 rageworks kernel: ata9: SATA link down (SStatus 0 SControl 300) Jul 20 04:13:41 rageworks kernel: ata6: SATA link down (SStatus 0 SControl 330) Jul 20 04:13:41 rageworks kernel: usb 1-7: reset full-speed USB device number 2 using xhci_hcd Jul 20 04:13:41 rageworks kernel: usb 1-10: reset full-speed USB device number 4 using xhci_hcd Jul 20 04:13:41 rageworks kernel: usb 1-8: reset full-speed USB device number 3 using xhci_hcd Jul 20 04:13:41 rageworks kernel: ata2: found unknown device (class 0) Jul 20 04:13:41 rageworks kernel: ata1: found unknown device (class 0) Jul 20 04:13:41 rageworks kernel: ata10: found unknown device (class 0) Jul 20 04:13:41 rageworks kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 20 04:13:41 rageworks kernel: ata2.00: configured for UDMA/133 Jul 20 04:13:41 rageworks kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 20 04:13:41 rageworks kernel: ata1.00: configured for UDMA/133 Jul 20 04:13:41 rageworks kernel: ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 20 04:13:41 rageworks kernel: ata10.00: configured for UDMA/133 Jul 20 04:13:41 rageworks kernel: ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 20 04:13:41 rageworks kernel: ata10.00: configured for UDMA/133 Jul 20 04:13:41 rageworks kernel: ata10.00: device reported invalid CHS sector 0 Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: [sdc] Start/Stop Unit failed: Result: hostbyte=DID_OK driverbyte=DRIVER_OK Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: [sdc] Sense Key : Illegal Request [current] Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: [sdc] Add. Sense: Unaligned write command Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: PM: dpm_run_callback(): scsi_bus_resume+0x0/0x90 returns -5 Jul 20 04:13:41 rageworks kernel: sd 9:0:0:0: PM: failed to resume async: error -5 Jul 20 04:13:41 rageworks kernel: OOM killer enabled. Jul 20 04:13:41 rageworks kernel: Restarting tasks ... done. Jul 20 04:13:41 rageworks kernel: random: crng reseeded on system resumption Jul 20 04:13:41 rageworks kernel: PM: suspend exit Jul 20 04:13:41 rageworks rtkit-daemon[1349]: The canary thread is apparently starving. Taking action. Jul 20 04:13:41 rageworks systemd-sleep[2059]: System returned from sleep state. Jul 20 04:13:41 rageworks rtkit-daemon[1349]: Demoting known real-time threads. Jul 20 04:13:41 rageworks systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully. Jul 20 04:13:41 rageworks rtkit-daemon[1349]: Successfully demoted thread 1597 of process 1342. Jul 20 04:13:41 rageworks rtkit-daemon[1349]: Successfully demoted thread 1342 of process 1342. Jul 20 04:13:41 rageworks rtkit-daemon[1349]: Demoted 2 threads. Jul 20 04:13:42 rageworks systemd[1]: systemd-suspend.service: Deactivated successfully. Jul 20 04:13:42 rageworks systemd[1]: Finished System Suspend. Jul 20 04:13:42 rageworks systemd[1]: Stopped target Sleep. Jul 20 04:13:42 rageworks systemd[1]: Reached target Suspend. Jul 20 04:13:42 rageworks systemd[1]: Stopped target Suspend. Jul 20 04:13:42 rageworks systemd-logind[869]: Operation 'sleep' finished. Thanks

2 years, 3 months

3
13
0 0

[PATCH] virtio-vdpa: Fix cpumask memory leak in virtio_vdpa_find_vqs()

by Dragos Tatulea

From: Gal Pressman <gal(a)nvidia.com> Free the cpumask allocated by create_affinity_masks() before returning from the function. Fixes: 3dad56823b53 ("virtio-vdpa: Support interrupt affinity spreading mechanism") Signed-off-by: Gal Pressman <gal(a)nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea(a)nvidia.com> --- drivers/virtio/virtio_vdpa.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/virtio/virtio_vdpa.c b/drivers/virtio/virtio_vdpa.c index 989e2d7184ce..961161da5900 100644 --- a/drivers/virtio/virtio_vdpa.c +++ b/drivers/virtio/virtio_vdpa.c @@ -393,11 +393,13 @@ static int virtio_vdpa_find_vqs(struct virtio_device *vdev, unsigned int nvqs, cb.callback = virtio_vdpa_config_cb; cb.private = vd_dev; ops->set_config_cb(vdpa, &cb); + kfree(masks); return 0; err_setup_vq: virtio_vdpa_del_vqs(vdev); + kfree(masks); return err; } -- 2.41.0

2 years, 3 months

4
3
0 0

Asus Laptop wont resume by timer (timerfd_settime)

by Alexey Kuznetsov

Hello! I'm using Asus Vivobook Laptop. Which fails to resume by timer set by timerfd_settime function call. It simply ignores the timer and keeps sleeping until I press any key. When key pressed notebook wakes up and treating key resume event as timer event. I tested this using systemd and its HibernateDelaySec option, which allows to wake system during the sleep by timer to switch to hibernate state replacing suspend mode. During suspend notebook simply do nothing when timer hits, and when I press any key it wakes, and went to hibernate (treating key pressing wake event as timer event). Systemd has checks which should prevent hibernating if system wakes by key press, but those checks does not fails. I tested the same suspend / hibernate software on desktop - everything working fine. This systemd code responsible for suspend / timer / hibernate logic: tfd = timerfd_create(CLOCK_BOOTTIME_ALARM, TFD_NONBLOCK|TFD_CLOEXEC); timerfd_settime(tfd, 0, &ts, NULL) execute(sleep_config, SLEEP_HYBRID_SLEEP, NULL) fd_wait_for_event(tfd, POLLIN, 0) woken_by_timer = FLAGS_SET(r, POLLIN) check_wakeup_type() Basically it is POSIX calls responsible for setting timer alarms set and reading timer status. I've tested on recent debian kernel Linux 6.1.0-10-amd64 and stable release from kernel.org Linux 6.4.7 - same behavior. It most likely hardware/EFI or kernel issue. Full logs: https://linux-hardware.org/?probe=d1a4b2769a https://bugzilla.kernel.org/show_bug.cgi?id=217728 -- AK

2 years, 3 months

1
0
0 0

[PATCH v3 1/3] ARM: dts: imx6sx: Remove LDB endpoint

by Fabio Estevam

From: Fabio Estevam <festevam(a)denx.de> Remove the LDB endpoint description from the common imx6sx.dtsi as it causes regression for boards that has the LCDIF connected directly to a parallel display. Let the LDB endpoint be described in the board devicetree file instead. Cc: stable(a)vger.kernel.org Fixes: b74edf626c4f ("ARM: dts: imx6sx: Add LDB support") Signed-off-by: Fabio Estevam <festevam(a)denx.de> --- Changes since v2: - Rebased against 6.5-rc1. arch/arm/boot/dts/nxp/imx/imx6sx.dtsi | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi b/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi index 3a4308666552..41c900929758 100644 --- a/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi +++ b/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi @@ -863,7 +863,6 @@ port@0 { reg = <0>; ldb_from_lcdif1: endpoint { - remote-endpoint = <&lcdif1_to_ldb>; }; }; @@ -1309,11 +1308,8 @@ lcdif1: lcdif@2220000 { power-domains = <&pd_disp>; status = "disabled"; - ports { - port { - lcdif1_to_ldb: endpoint { - remote-endpoint = <&ldb_from_lcdif1>; - }; + port { + lcdif1_to_ldb: endpoint { }; }; }; -- 2.34.1

2 years, 3 months

2
2
0 0

[PATCH] rust: allocator: Prevents mis-aligned allocation

by Boqun Feng

Currently the KernelAllocator simply passes the size of the type Layout to krealloc(), and in theory the alignment requirement from the type Layout may be larger than the guarantee provided by SLAB, which means the allocated object is mis-aligned. Fixes this by adjusting the allocation size to the nearest power of two, which SLAB always guarantees a size-aligned allocation. And because Rust guarantees that original size must be a multiple of alignment and the alignment must be a power of two, then the alignment requirement is satisfied. Suggested-by: Vlastimil Babka <vbabka(a)suse.cz> Co-developed-by: Andreas Hindborg (Samsung) <nmi(a)metaspace.dk> Signed-off-by: Andreas Hindborg (Samsung) <nmi(a)metaspace.dk> Signed-off-by: Boqun Feng <boqun.feng(a)gmail.com> Cc: stable(a)vger.kernel.org # v6.1+ --- Some more explanation: * Layout is a data structure describing a particular memory layout, conceptionally it has two fields: align and size. * align is guaranteed to be a power of two. * size can be smaller than align (only when the Layout is created via Layout::from_align_size()) * After pad_to_align(), the size is guaranteed to be a multiple of align For more information, please see: https://doc.rust-lang.org/stable/std/alloc/struct.Layout.html rust/bindings/bindings_helper.h | 1 + rust/kernel/allocator.rs | 17 ++++++++++++++++- 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h index 3e601ce2548d..6619ce95dd37 100644 --- a/rust/bindings/bindings_helper.h +++ b/rust/bindings/bindings_helper.h @@ -15,3 +15,4 @@ /* `bindgen` gets confused at certain things. */ const gfp_t BINDINGS_GFP_KERNEL = GFP_KERNEL; const gfp_t BINDINGS___GFP_ZERO = __GFP_ZERO; +const size_t BINDINGS_ARCH_SLAB_MINALIGN = ARCH_SLAB_MINALIGN; diff --git a/rust/kernel/allocator.rs b/rust/kernel/allocator.rs index 397a3dd57a9b..66575cf87ce2 100644 --- a/rust/kernel/allocator.rs +++ b/rust/kernel/allocator.rs @@ -11,9 +11,24 @@ unsafe impl GlobalAlloc for KernelAllocator { unsafe fn alloc(&self, layout: Layout) -> *mut u8 { + // Customized layouts from `Layout::from_size_align()` can have size < align, so pads first. + let layout = layout.pad_to_align(); + + let mut size = layout.size(); + + if layout.align() > bindings::BINDINGS_ARCH_SLAB_MINALIGN { + // The alignment requirement exceeds the slab guarantee, then tries to enlarges the size + // to use the "power-of-two" size/alignment guarantee (see comments in kmalloc() for + // more information). + // + // Note that `layout.size()` (after padding) is guaranteed to be muliples of + // `layout.align()`, so `next_power_of_two` gives enough alignment guarantee. + size = size.next_power_of_two(); + } + // `krealloc()` is used instead of `kmalloc()` because the latter is // an inline function and cannot be bound to as a result. - unsafe { bindings::krealloc(ptr::null(), layout.size(), bindings::GFP_KERNEL) as *mut u8 } + unsafe { bindings::krealloc(ptr::null(), size, bindings::GFP_KERNEL) as *mut u8 } } unsafe fn dealloc(&self, ptr: *mut u8, _layout: Layout) { -- 2.39.2

2 years, 3 months

6
6
0 0

[PATCH 0/2] mm/damon/core: fix unitialized memory error from

by SeongJae Park

damos_new_filter() is returning a damos_filter struct without initializing its ->list field. And the users of the function uses the struct without initializing the field. As a result, uninitialized memory access error is possible. Actually, a kernel NULL pointer dereference BUG can be triggered using DAMON user-space tool, like below. # damo start --damos_action stat --damos_filter anon matching # damo tune --damos_action stat --damos_filter anon matching --damos_filter anon nomatching # dmesg [...] [ 36.908136] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 36.910483] #PF: supervisor write access in kernel mode [ 36.912238] #PF: error_code(0x0002) - not-present page [ 36.913415] PGD 0 P4D 0 [ 36.913978] Oops: 0002 [#1] PREEMPT SMP PTI [ 36.914878] CPU: 32 PID: 1335 Comm: kdamond.0 Not tainted 6.5.0-rc3-mm-unstable-damon+ #1 [ 36.916621] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 36.919051] RIP: 0010:damos_destroy_filter (include/linux/list.h:114 include/linux/list.h:137 include/linux/list.h:148 mm/damon/core.c:345 mm/damon/core.c:355) [...] [ 36.938247] Call Trace: [ 36.938721] <TASK> [...] [ 36.950064] ? damos_destroy_filter (include/linux/list.h:114 include/linux/list.h:137 include/linux/list.h:148 mm/damon/core.c:345 mm/damon/core.c:355) [ 36.950883] ? damon_sysfs_set_scheme_filters.isra.0 (mm/damon/sysfs-schemes.c:1573) [ 36.952019] damon_sysfs_set_schemes (mm/damon/sysfs-schemes.c:1674 mm/damon/sysfs-schemes.c:1686) [ 36.952875] damon_sysfs_apply_inputs (mm/damon/sysfs.c:1312 mm/damon/sysfs.c:1298) [ 36.953757] ? damon_pa_check_accesses (mm/damon/paddr.c:168 mm/damon/paddr.c:179) [ 36.954648] damon_sysfs_cmd_request_callback (mm/damon/sysfs.c:1329 mm/damon/sysfs.c:1359) [...] The first patch of this patchset fixes the bug by initializing the field in damos_new_filter(). The second patch adds a unit test for the problem. Note that the second patch Cc stable@ without Fixes: tag, since it would be better to be ingested together for avoiding any future regression. SeongJae Park (2): mm/damon/core: initialize damo_filter->list from damos_new_filter() mm/damon/core-test: add a test for damos_new_filter() mm/damon/core-test.h | 13 +++++++++++++ mm/damon/core.c | 1 + 2 files changed, 14 insertions(+) -- 2.25.1

2 years, 3 months

1
2
0 0

[PATCH v2 1/5] rcutorture: Fix stuttering races and other issues

by Joel Fernandes (Google)

The stuttering code isn't functioning as expected. Ideally, it should pause the torture threads for a designated period before resuming. Yet, it fails to halt the test for the correct duration. Additionally, a race condition exists, potentially causing the stuttering code to pause for an extended period if the 'spt' variable is non-zero due to the stutter orchestration thread's inadequate CPU time. Moreover, over-stuttering can hinder RCU's progress on TREE07 kernels. This happens as the stuttering code may run within a softirq due to RCU callbacks. Consequently, ksoftirqd keeps a CPU busy for several seconds, thus obstructing RCU's progress. This situation triggers a warning message in the logs: [ 2169.481783] rcu_torture_writer: rtort_pipe_count: 9 This warning suggests that an RCU torture object, although invisible to RCU readers, couldn't make it past the pipe array and be freed -- a strong indication that there weren't enough grace periods during the stutter interval. To address these issues, this patch sets the "stutter end" time to an absolute point in the future set by the main stutter thread. This is then used for waiting in stutter_wait(). While the stutter thread still defines this absolute time, the waiters' waiting logic doesn't rely on the stutter thread receiving sufficient CPU time to halt the stuttering as the halting is now self-controlled. Cc: stable(a)vger.kernel.org Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> --- kernel/torture.c | 45 ++++++++++++--------------------------------- 1 file changed, 12 insertions(+), 33 deletions(-) diff --git a/kernel/torture.c b/kernel/torture.c index 6ba62e5993e7..fd353f98162f 100644 --- a/kernel/torture.c +++ b/kernel/torture.c @@ -720,7 +720,7 @@ static void torture_shutdown_cleanup(void) * suddenly applied to or removed from the system. */ static struct task_struct *stutter_task; -static int stutter_pause_test; +static ktime_t stutter_till_abs_time; static int stutter; static int stutter_gap; @@ -730,30 +730,16 @@ static int stutter_gap; */ bool stutter_wait(const char *title) { - unsigned int i = 0; bool ret = false; - int spt; + ktime_t till_ns; cond_resched_tasks_rcu_qs(); - spt = READ_ONCE(stutter_pause_test); - for (; spt; spt = READ_ONCE(stutter_pause_test)) { - if (!ret && !rt_task(current)) { - sched_set_normal(current, MAX_NICE); - ret = true; - } - if (spt == 1) { - torture_hrtimeout_jiffies(1, NULL); - } else if (spt == 2) { - while (READ_ONCE(stutter_pause_test)) { - if (!(i++ & 0xffff)) - torture_hrtimeout_us(10, 0, NULL); - cond_resched(); - } - } else { - torture_hrtimeout_jiffies(round_jiffies_relative(HZ), NULL); - } - torture_shutdown_absorb(title); + till_ns = READ_ONCE(stutter_till_abs_time); + if (till_ns && ktime_before(ktime_get(), till_ns)) { + torture_hrtimeout_ns(till_ns, 0, HRTIMER_MODE_ABS, NULL); + ret = true; } + torture_shutdown_absorb(title); return ret; } EXPORT_SYMBOL_GPL(stutter_wait); @@ -764,23 +750,16 @@ EXPORT_SYMBOL_GPL(stutter_wait); */ static int torture_stutter(void *arg) { - DEFINE_TORTURE_RANDOM(rand); - int wtime; + ktime_t till_ns; VERBOSE_TOROUT_STRING("torture_stutter task started"); do { if (!torture_must_stop() && stutter > 1) { - wtime = stutter; - if (stutter > 2) { - WRITE_ONCE(stutter_pause_test, 1); - wtime = stutter - 3; - torture_hrtimeout_jiffies(wtime, &rand); - wtime = 2; - } - WRITE_ONCE(stutter_pause_test, 2); - torture_hrtimeout_jiffies(wtime, NULL); + till_ns = ktime_add_ns(ktime_get(), + jiffies_to_nsecs(stutter)); + WRITE_ONCE(stutter_till_abs_time, till_ns); + torture_hrtimeout_jiffies(stutter - 1, NULL); } - WRITE_ONCE(stutter_pause_test, 0); if (!torture_must_stop()) torture_hrtimeout_jiffies(stutter_gap, NULL); torture_shutdown_absorb("torture_stutter"); -- 2.41.0.487.g6d72f3e995-goog

2 years, 3 months

1
0
0 0

[PATCH] hwmon: (aquacomputer_d5next) Add selective 200ms delay after sending ctrl report

by Aleksa Savic

Add a 200ms delay after sending a ctrl report to Quadro, Octo, D5 Next and Aquaero to give them enough time to process the request and save the data to memory. Otherwise, under heavier userspace loads where multiple sysfs entries are usually set in quick succession, a new ctrl report could be requested from the device while it's still processing the previous one and fail with -EPIPE. Reported by a user on Github [1] and tested by both of us. [1] https://github.com/aleksamagicka/aquacomputer_d5next-hwmon/issues/82 Cc: stable(a)vger.kernel.org Signed-off-by: Aleksa Savic <savicaleksa83(a)gmail.com> --- drivers/hwmon/aquacomputer_d5next.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c index a997dbcb563f..9cb55d51185a 100644 --- a/drivers/hwmon/aquacomputer_d5next.c +++ b/drivers/hwmon/aquacomputer_d5next.c @@ -652,6 +652,31 @@ static int aqc_send_ctrl_data(struct aqc_data *priv) ret = hid_hw_raw_request(priv->hdev, priv->secondary_ctrl_report_id, priv->secondary_ctrl_report, priv->secondary_ctrl_report_size, HID_FEATURE_REPORT, HID_REQ_SET_REPORT); + if (ret < 0) + return ret; + + /* + * Wait 200ms before returning to make sure that the device actually processed both reports + * and saved ctrl data to memory. Otherwise, an aqc_get_ctrl_data() call made shortly after + * may fail with -EPIPE because the device is still busy and can't provide data. This can + * happen when userspace tools, such as fancontrol or liquidctl, write to sysfs entries in + * quick succession. + * + * 200ms was found to be the sweet spot between fixing the issue and not significantly + * prolonging the call. Quadro, Octo, D5 Next and Aquaero are currently known to be + * affected. + */ + switch (priv->kind) { + case quadro: + case octo: + case d5next: + case aquaero: + msleep(200); + break; + default: + break; + } + return ret; } -- 2.41.0

2 years, 3 months

3
3
0 0

[PATCH RESEND v4 1/1] test_firmware: fix some memory leaks and racing conditions

by Mirsad Todorovac

Some functions were called both from locked and unlocked context, so the lock was dropped prematurely, introducing a race condition when deadlock was avoided. Having two locks wouldn't assure a race-proof mutual exclusion. __test_dev_config_update_bool(), __test_dev_config_update_u8() and __test_dev_config_update_size_t() unlocked versions of the functions were introduced to be called from the locked contexts as a workaround without releasing the main driver's lock and causing a race condition. This should guarantee mutual exclusion and prevent any race conditions. Locked versions simply allow for mutual exclusion and call the unlocked counterparts, to avoid duplication of code. trigger_batched_requests_store() and trigger_batched_requests_async_store() now return -EBUSY if called with test_fw_config->reqs already allocated, so the memory leak is prevented. The same functions now keep track of the allocated buf for firmware in req->fw_buf as release_firmware() will not deallocate this storage for us. Additionally, in __test_release_all_firmware(), req->fw_buf is released before calling release_firmware(req->fw), foreach test_fw_config->reqs[i], i = 0 .. test_fw_config->num_requests-1 Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Russ Weight <russell.h.weight(a)intel.com> Cc: Tianfei zhang <tianfei.zhang(a)intel.com> Cc: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: Zhengchao Shao <shaozhengchao(a)huawei.com> Cc: Colin Ian King <colin.i.king(a)gmail.com> Cc: linux-kernel(a)vger.kernel.org Cc: Takashi Iwai <tiwai(a)suse.de> Cc: Kees Cook <keescook(a)chromium.org> Cc: Scott Branden <sbranden(a)broadcom.com> Cc: Luis R. Rodriguez <mcgrof(a)kernel.org> Suggested-by: Dan Carpenter <error27(a)gmail.com> Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac(a)alu.unizg.hr> --- v3 -> v4 - fix additional memory leaks of the allocated firmware buffers - fix noticed racing conditions in conformance with the existing code - make it a single patch lib/test_firmware.c | 81 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 63 insertions(+), 18 deletions(-) diff --git a/lib/test_firmware.c b/lib/test_firmware.c index 05ed84c2fc4c..1d7d480b8eeb 100644 --- a/lib/test_firmware.c +++ b/lib/test_firmware.c @@ -45,6 +45,7 @@ struct test_batched_req { bool sent; const struct firmware *fw; const char *name; + const char *fw_buf; struct completion completion; struct task_struct *task; struct device *dev; @@ -175,8 +176,14 @@ static void __test_release_all_firmware(void) for (i = 0; i < test_fw_config->num_requests; i++) { req = &test_fw_config->reqs[i]; - if (req->fw) + if (req->fw) { + if (req->fw_buf) { + kfree_const(req->fw_buf); + req->fw_buf = NULL; + } release_firmware(req->fw); + req->fw = NULL; + } } vfree(test_fw_config->reqs); @@ -353,16 +360,26 @@ static ssize_t config_test_show_str(char *dst, return len; } -static int test_dev_config_update_bool(const char *buf, size_t size, +static inline int __test_dev_config_update_bool(const char *buf, size_t size, bool *cfg) { int ret; - mutex_lock(&test_fw_mutex); if (kstrtobool(buf, cfg) < 0) ret = -EINVAL; else ret = size; + + return ret; +} + +static int test_dev_config_update_bool(const char *buf, size_t size, + bool *cfg) +{ + int ret; + + mutex_lock(&test_fw_mutex); + ret = __test_dev_config_update_bool(buf, size, cfg); mutex_unlock(&test_fw_mutex); return ret; @@ -373,7 +390,8 @@ static ssize_t test_dev_config_show_bool(char *buf, bool val) return snprintf(buf, PAGE_SIZE, "%d\n", val); } -static int test_dev_config_update_size_t(const char *buf, +static int __test_dev_config_update_size_t( + const char *buf, size_t size, size_t *cfg) { @@ -384,9 +402,7 @@ static int test_dev_config_update_size_t(const char *buf, if (ret) return ret; - mutex_lock(&test_fw_mutex); *(size_t *)cfg = new; - mutex_unlock(&test_fw_mutex); /* Always return full write size even if we didn't consume all */ return size; @@ -402,7 +418,7 @@ static ssize_t test_dev_config_show_int(char *buf, int val) return snprintf(buf, PAGE_SIZE, "%d\n", val); } -static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg) +static int __test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg) { u8 val; int ret; @@ -411,14 +427,23 @@ static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg) if (ret) return ret; - mutex_lock(&test_fw_mutex); *(u8 *)cfg = val; - mutex_unlock(&test_fw_mutex); /* Always return full write size even if we didn't consume all */ return size; } +static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg) +{ + int ret; + + mutex_lock(&test_fw_mutex); + ret = __test_dev_config_update_u8(buf, size, cfg); + mutex_unlock(&test_fw_mutex); + + return ret; +} + static ssize_t test_dev_config_show_u8(char *buf, u8 val) { return snprintf(buf, PAGE_SIZE, "%u\n", val); @@ -471,10 +496,10 @@ static ssize_t config_num_requests_store(struct device *dev, mutex_unlock(&test_fw_mutex); goto out; } - mutex_unlock(&test_fw_mutex); - rc = test_dev_config_update_u8(buf, count, - &test_fw_config->num_requests); + rc = __test_dev_config_update_u8(buf, count, + &test_fw_config->num_requests); + mutex_unlock(&test_fw_mutex); out: return rc; @@ -518,10 +543,10 @@ static ssize_t config_buf_size_store(struct device *dev, mutex_unlock(&test_fw_mutex); goto out; } - mutex_unlock(&test_fw_mutex); - rc = test_dev_config_update_size_t(buf, count, - &test_fw_config->buf_size); + rc = __test_dev_config_update_size_t(buf, count, + &test_fw_config->buf_size); + mutex_unlock(&test_fw_mutex); out: return rc; @@ -548,10 +573,10 @@ static ssize_t config_file_offset_store(struct device *dev, mutex_unlock(&test_fw_mutex); goto out; } - mutex_unlock(&test_fw_mutex); - rc = test_dev_config_update_size_t(buf, count, - &test_fw_config->file_offset); + rc = __test_dev_config_update_size_t(buf, count, + &test_fw_config->file_offset); + mutex_unlock(&test_fw_mutex); out: return rc; @@ -652,6 +677,8 @@ static ssize_t trigger_request_store(struct device *dev, mutex_lock(&test_fw_mutex); release_firmware(test_firmware); + if (test_fw_config->reqs) + __test_release_all_firmware(); test_firmware = NULL; rc = request_firmware(&test_firmware, name, dev); if (rc) { @@ -752,6 +779,8 @@ static ssize_t trigger_async_request_store(struct device *dev, mutex_lock(&test_fw_mutex); release_firmware(test_firmware); test_firmware = NULL; + if (test_fw_config->reqs) + __test_release_all_firmware(); rc = request_firmware_nowait(THIS_MODULE, 1, name, dev, GFP_KERNEL, NULL, trigger_async_request_cb); if (rc) { @@ -794,6 +823,8 @@ static ssize_t trigger_custom_fallback_store(struct device *dev, mutex_lock(&test_fw_mutex); release_firmware(test_firmware); + if (test_fw_config->reqs) + __test_release_all_firmware(); test_firmware = NULL; rc = request_firmware_nowait(THIS_MODULE, FW_ACTION_NOUEVENT, name, dev, GFP_KERNEL, NULL, @@ -856,6 +887,8 @@ static int test_fw_run_batch_request(void *data) test_fw_config->buf_size); if (!req->fw) kfree(test_buf); + else + req->fw_buf = test_buf; } else { req->rc = test_fw_config->req_firmware(&req->fw, req->name, @@ -895,6 +928,11 @@ static ssize_t trigger_batched_requests_store(struct device *dev, mutex_lock(&test_fw_mutex); + if (test_fw_config->reqs) { + rc = -EBUSY; + goto out_bail; + } + test_fw_config->reqs = vzalloc(array3_size(sizeof(struct test_batched_req), test_fw_config->num_requests, 2)); @@ -911,6 +949,7 @@ static ssize_t trigger_batched_requests_store(struct device *dev, req->fw = NULL; req->idx = i; req->name = test_fw_config->name; + req->fw_buf = NULL; req->dev = dev; init_completion(&req->completion); req->task = kthread_run(test_fw_run_batch_request, req, @@ -993,6 +1032,11 @@ ssize_t trigger_batched_requests_async_store(struct device *dev, mutex_lock(&test_fw_mutex); + if (test_fw_config->reqs) { + rc = -EBUSY; + goto out_bail; + } + test_fw_config->reqs = vzalloc(array3_size(sizeof(struct test_batched_req), test_fw_config->num_requests, 2)); @@ -1010,6 +1054,7 @@ ssize_t trigger_batched_requests_async_store(struct device *dev, for (i = 0; i < test_fw_config->num_requests; i++) { req = &test_fw_config->reqs[i]; req->name = test_fw_config->name; + req->fw_buf = NULL; req->fw = NULL; req->idx = i; init_completion(&req->completion); -- 2.30.2

2 years, 3 months

2
3
0 0

[PATCH net 0/6] There are some bugfix for the HNS3 ethernet driver

by Jijie Shao

There are some bugfix for the HNS3 ethernet driver Jian Shen (1): net: hns3: restore user pause configure when disable autoneg Jie Wang (2): net: hns3: refactor hclge_mac_link_status_wait for interface reuse net: hns3: add wait until mac link down Peiyang Wang (1): net: hns3: fix wrong print link down up Yonglong Liu (2): net: hns3: fix side effects passed to min_t() net: hns3: fix deadlock issue when externel_lb and reset are executed together .../net/ethernet/hisilicon/hns3/hns3_enet.c | 17 ++++++++-- .../hisilicon/hns3/hns3pf/hclge_main.c | 32 ++++++++++++++----- .../ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 2 +- .../ethernet/hisilicon/hns3/hns3pf/hclge_tm.h | 1 + 4 files changed, 41 insertions(+), 11 deletions(-) -- 2.30.0

2 years, 3 months

4
12
0 0

Re: [PATCH 6.4 000/227] 6.4.7-rc1 review

by Paul E. McKenney

> On Fri, Jul 28, 2023 at 05:17:59PM -0400, Joel Fernandes wrote: > > On Jul 27, 2023, at 7:18 PM, Joel Fernandes <joel(a)joelfernandes.org> > wrote: > > > > On Jul 27, 2023, at 4:33 PM, Paul E. McKenney <paulmck(a)kernel.org> > wrote: > > On Thu, Jul 27, 2023 at 10:39:17AM -0700, Guenter Roeck wrote: > > On 7/27/23 09:07, Paul E. McKenney wrote: > > ...] > > No. However, (unrelated) in linux-next, rcu tests sometimes result > in apparent hangs > > or long runtime. > > [ 0.778841] Mount-cache hash table entries: 512 (order: 0, 4096 > bytes, linear) > > [ 0.779011] Mountpoint-cache hash table entries: 512 (order: 0, > 4096 bytes, linear) > > [ 0.797998] Running RCU synchronous self tests > > [ 0.798209] Running RCU synchronous self tests > > [ 0.912368] smpboot: CPU0: AMD Opteron 63xx class CPU (family: > 0x15, model: 0x2, stepping: 0x0) > > [ 0.923398] RCU Tasks: Setting shift to 2 and lim to 1 > rcu_task_cb_adjust=1. > > [ 0.925419] Running RCU-tasks wait API self tests > > (hangs until aborted). This is primarily with Opteron CPUs, but also > with others such as Haswell, > > Icelake-Server, and pentium3. It is all but impossible to bisect > because it doesn't happen > > all the time. All I was able to figure out was that it has to do > with rcu changes in linux-next. > > I'd be much more concerned about that. > > First I have heard of this, so thank you for letting me know. > > About what fraction of the time does this happen? > > Here is a sample test log from yesterday's -next. This is with > x86_64. > > Today's -next always crashes, so no data. > > Building > x86_64:q35:Broadwell-noTSX:defconfig:smp:net,e1000:mem256:ata:hd ... > running ....... passed > > Building > x86_64:q35:Cascadelake-Server:defconfig:smp:net,e1000e:mem256:ata:cd > ... running .................R....... passed > > Building > x86_64:q35:IvyBridge:defconfig:smp2:net,i82801:efi:mem512:nvme:hd > ... running ...... passed > > Building > x86_64:q35:SandyBridge:defconfig:smp4:net,ne2k_pci:efi32:mem1G:usb:h > d ... running ......... passed > > Building > x86_64:q35:SandyBridge:defconfig:smp8:net,ne2k_pci:mem1G:usb-hub:hd > ... running ....... passed > > Building > x86_64:q35:Haswell:defconfig:smp:tpm-tis:net,pcnet:mem2G:usb-uas:hd > ... running .................R.... passed > > Building > x86_64:q35:Skylake-Client:defconfig:smp2:tpm-tis:net,rtl8139:efi:mem > 4G:sdhci:mmc:hd ... running ....... passed > > Building > x86_64:q35:Conroe:defconfig:smp4:net,tulip:efi32:mem256:scsi[DC395]: > hd ... running ....... passed > > Building > x86_64:q35:Denverton:defconfig:smp2:net,tulip:efi:mem256:scsi[DC395] > :hd ... running ....... passed > > Building > x86_64:q35:EPYC-Milan:defconfig:smp:tpm-crb:net,tulip:mem256:scsi[DC > 395]:hd ... running ....... passed > > Building > x86_64:q35:Nehalem:defconfig:smp:net,virtio-net:mem512:scsi[AM53C974 > ]:hd ... running ....... passed > > Building > x86_64:q35:Nehalem:defconfig:smp:net,virtio-net-old:mem512:scsi[AM53 > C974]:hd ... running ....... passed > > Building > x86_64:q35:Westmere-IBRS:defconfig:smp2:tpm-crb:net,usb-ohci:efi:mem > 1G:scsi[53C810]:cd ... running .................R........... passed > > Building > x86_64:q35:Skylake-Server:defconfig:smp4:tpm-tis:net,e1000-82544gc:e > fi32:mem2G:scsi[53C895A]:hd ... running ............. passed > > Building > x86_64:pc:EPYC:defconfig:smp:pci-bridge:net,usb-uhci:mem4G:scsi[FUSI > ON]:hd ... running ..................R.......... passed > > Building > x86_64:q35:EPYC-IBPB:defconfig:smp2:net,e1000-82545em:efi:mem8G:scsi > [MEGASAS]:hd ... running ....... passed > > Building > x86_64:q35:Opteron_G5:defconfig:smp4:net,i82559c:efi32:mem256:scsi[M > EGASAS2]:hd ... running ...... passed > > Building > x86_64:q35:Opteron_G5:defconfig:smp4:net,i82559c:mem256:scsi[MEGASAS > 2]:hd ... running .................R.............. failed (silent) > > Building > x86_64:pc:Opteron_G5:defconfig:smp4:net,i82559c:mem256:scsi[MEGASAS2 > ]:hd ... running .......... passed > > Building x86_64:pc:phenom:defconfig:smp:net,i82559er:mem512:initrd > ... running ........ passed > > Building > x86_64:q35:Opteron_G1:defconfig:smp2:net,i82562:efi:mem1G:initrd ... > running ...... passed > > Building > x86_64:pc:Opteron_G2:defconfig:smp:net,usb:efi32:mem2G:scsi[virtio-p > ci]:hd ... running .................R................. passed > > Building > x86_64:pc:Opteron_G2:defconfig:smp:net,usb:efi32:mem2G:scsi[virtio-p > ci-old]:hd ... running ................... passed > > Building > x86_64:q35:core2duo:defconfig:smp2:net,i82559a:mem4G:virtio-pci:hd > ... running ......... passed > > Building > x86_64:q35:Broadwell:defconfig:smp4:net,i82558b:efi:mem8G:virtio:hd > ... running ....... passed > > Building > x86_64:q35:Nehalem:defconfig:smp2:net,i82558a:efi32:mem1G:virtio:hd > ... running .................R... passed > > Building > x86_64:q35:Icelake-Server:defconfig:preempt:smp4:net,ne2k_pci:efi:me > m2G:virtio:cd ... running ......... passed > > Building > x86_64:q35:Icelake-Server:defconfig:preempt:smp8:net,i82557a:mem4G:n > vme:hd ... running ...... passed > > Building > x86_64:q35:Skylake-Client-IBRS:defconfig:preempt:smp2:net,i82558b:ef > i32:mem1G:sdhci:mmc:hd ... running ...... passed > > Building > x86_64:q35:KnightsMill:defconfig:preempt:smp6:net,i82550:mem512:init > rd ... running ...... passed > > Building > x86_64:q35:Cooperlake:defconfig:smp2:net,usb-ohci:efi:mem1G:scsi[53C > 810]:hd ... running ....... passed > > Building > x86_64:q35:EPYC-Rome:defconfig:smp4:net,igb:mem2G:scsi[53C895A]:hd > ... running ......... passed > > Building x86_64:pc:Opteron_G3:defconfig:nosmp:net,e1000:mem1G:usb:hd > ... running ....................R................. failed (silent) > > Building > x86_64:q35:Opteron_G4:defconfig:nosmp:net,ne2k_pci:efi:mem512:ata:hd > ... running .....................R....... passed > > Building > x86_64:q35:Haswell-noTSX-IBRS:defconfig:nosmp:net,pcnet:efi32:mem2G: > ata:hd ... running .................R.............. failed (silent) > > An earlier test run: > > Building > x86_64:q35:Broadwell-noTSX:defconfig:smp:net,e1000:mem256:ata:hd ... > running ....... passed > > Building > x86_64:q35:Cascadelake-Server:defconfig:smp:net,e1000e:mem256:ata:cd > ... running .................R....... passed > > Building > x86_64:q35:IvyBridge:defconfig:smp2:net,i82801:efi:mem512:nvme:hd > ... running ........ passed > > Building > x86_64:q35:SandyBridge:defconfig:smp4:net,ne2k_pci:efi32:mem1G:usb:h > d ... running .......... passed > > Building > x86_64:q35:SandyBridge:defconfig:smp8:net,ne2k_pci:mem1G:usb-hub:hd > ... running ....... passed > > Building > x86_64:q35:Haswell:defconfig:smp:tpm-tis:net,pcnet:mem2G:usb-uas:hd > ... running .................R.... passed > > Building > x86_64:q35:Skylake-Client:defconfig:smp2:tpm-tis:net,rtl8139:efi:mem > 4G:sdhci:mmc:hd ... running ....... passed > > Building > x86_64:q35:Conroe:defconfig:smp4:net,tulip:efi32:mem256:scsi[DC395]: > hd ... running ......... passed > > Building > x86_64:q35:Denverton:defconfig:smp2:net,tulip:efi:mem256:scsi[DC395] > :hd ... running ....... passed > > Building > x86_64:q35:EPYC-Milan:defconfig:smp:tpm-crb:net,tulip:mem256:scsi[DC > 395]:hd ... running ....... passed > > Building > x86_64:q35:Nehalem:defconfig:smp:net,virtio-net:mem512:scsi[AM53C974 > ]:hd ... running ....... passed > > Building > x86_64:q35:Nehalem:defconfig:smp:net,virtio-net-old:mem512:scsi[AM53 > C974]:hd ... running ........ passed > > Building > x86_64:q35:Westmere-IBRS:defconfig:smp2:tpm-crb:net,usb-ohci:efi:mem > 1G:scsi[53C810]:cd ... running .......... passed > > Building > x86_64:q35:Skylake-Server:defconfig:smp4:tpm-tis:net,e1000-82544gc:e > fi32:mem2G:scsi[53C895A]:hd ... running .................R..... > passed > > Building > x86_64:pc:EPYC:defconfig:smp:pci-bridge:net,usb-uhci:mem4G:scsi[FUSI > ON]:hd ... running .................R.............. failed (silent) > > Building > x86_64:q35:EPYC-IBPB:defconfig:smp2:net,e1000-82545em:efi:mem8G:scsi > [MEGASAS]:hd ... running ....... passed > > Building > x86_64:q35:Opteron_G5:defconfig:smp4:net,i82559c:efi32:mem256:scsi[M > EGASAS2]:hd ... running ....... passed > > Building > x86_64:q35:Opteron_G5:defconfig:smp4:net,i82559c:mem256:scsi[MEGASAS > 2]:hd ... running ....... passed > > Building > x86_64:pc:Opteron_G5:defconfig:smp4:net,i82559c:mem256:scsi[MEGASAS2 > ]:hd ... running .......... passed > > Building x86_64:pc:phenom:defconfig:smp:net,i82559er:mem512:initrd > ... running ........ passed > > Building > x86_64:q35:Opteron_G1:defconfig:smp2:net,i82562:efi:mem1G:initrd ... > running ...... passed > > Building > x86_64:pc:Opteron_G2:defconfig:smp:net,usb:efi32:mem2G:scsi[virtio-p > ci]:hd ... running .......... passed > > Building > x86_64:pc:Opteron_G2:defconfig:smp:net,usb:efi32:mem2G:scsi[virtio-p > ci-old]:hd ... running .......... passed > > Building > x86_64:q35:core2duo:defconfig:smp2:net,i82559a:mem4G:virtio-pci:hd > ... running ...... passed > > Building > x86_64:q35:Broadwell:defconfig:smp4:net,i82558b:efi:mem8G:virtio:hd > ... running ....... passed > > Building > x86_64:q35:Nehalem:defconfig:smp2:net,i82558a:efi32:mem1G:virtio:hd > ... running ...... passed > > Building > x86_64:q35:Icelake-Server:defconfig:preempt:smp4:net,ne2k_pci:efi:me > m2G:virtio:cd ... running ......... passed > > Building > x86_64:q35:Icelake-Server:defconfig:preempt:smp8:net,i82557a:mem4G:n > vme:hd ... running ....... passed > > Building > x86_64:q35:Skylake-Client-IBRS:defconfig:preempt:smp2:net,i82558b:ef > i32:mem1G:sdhci:mmc:hd ... running ....... passed > > Building > x86_64:q35:KnightsMill:defconfig:preempt:smp6:net,i82550:mem512:init > rd ... running ....... passed > > Building > x86_64:q35:Cooperlake:defconfig:smp2:net,usb-ohci:efi:mem1G:scsi[53C > 810]:hd ... running ........ passed > > Building > x86_64:q35:EPYC-Rome:defconfig:smp4:net,igb:mem2G:scsi[53C895A]:hd > ... running ......... passed > > Building x86_64:pc:Opteron_G3:defconfig:nosmp:net,e1000:mem1G:usb:hd > ... running ....................R................. failed (silent) > > Building > x86_64:q35:Opteron_G4:defconfig:nosmp:net,ne2k_pci:efi:mem512:ata:hd > ... running ....... passed > > Building > x86_64:q35:Haswell-noTSX-IBRS:defconfig:nosmp:net,pcnet:efi32:mem2G: > ata:hd ... running ....... passed > > "R" means retry, and the dots reflect time expired. It looks like it > happens most of the time, > > but not always, on affected CPUs. I don't have specific data for > non-Intel CPUs. I don't think > > I see the problem there, but there is too much interference from > other problems to be sure. > > For comparison, here is the result from the latest mainline: > > Building > x86_64:q35:Broadwell-noTSX:defconfig:smp:net,e1000:mem256:ata:hd ... > running ....... passed > > Building > x86_64:q35:Cascadelake-Server:defconfig:smp:net,e1000e:mem256:ata:cd > ... running .......... passed > > Building > x86_64:q35:IvyBridge:defconfig:smp2:net,i82801:efi:mem512:nvme:hd > ... running ...... passed > > Building > x86_64:q35:SandyBridge:defconfig:smp4:net,ne2k_pci:efi32:mem1G:usb:h > d ... running ......... passed > > Building > x86_64:q35:SandyBridge:defconfig:smp8:net,ne2k_pci:mem1G:usb-hub:hd > ... running ........... passed > > Building > x86_64:q35:Haswell:defconfig:smp:tpm-tis:net,pcnet:mem2G:usb-uas:hd > ... running ........ passed > > Building > x86_64:q35:Skylake-Client:defconfig:smp2:tpm-tis:net,rtl8139:efi:mem > 4G:sdhci:mmc:hd ... running ....... passed > > Building > x86_64:q35:Conroe:defconfig:smp4:net,tulip:efi32:mem256:scsi[DC395]: > hd ... running ....... passed > > Building > x86_64:q35:Denverton:defconfig:smp2:net,tulip:efi:mem256:scsi[DC395] > :hd ... running ....... passed > > Building > x86_64:q35:EPYC-Milan:defconfig:smp:tpm-crb:net,tulip:mem256:scsi[DC > 395]:hd ... running ....... passed > > Building > x86_64:q35:Nehalem:defconfig:smp:net,virtio-net:mem512:scsi[AM53C974 > ]:hd ... running ....... passed > > Building > x86_64:q35:Nehalem:defconfig:smp:net,virtio-net-old:mem512:scsi[AM53 > C974]:hd ... running ....... passed > > Building > x86_64:q35:Westmere-IBRS:defconfig:smp2:tpm-crb:net,usb-ohci:efi:mem > 1G:scsi[53C810]:cd ... running .......... passed > > Building > x86_64:q35:Skylake-Server:defconfig:smp4:tpm-tis:net,e1000-82544gc:e > fi32:mem2G:scsi[53C895A]:hd ... running ....... passed > > Building > x86_64:pc:EPYC:defconfig:smp:pci-bridge:net,usb-uhci:mem4G:scsi[FUSI > ON]:hd ... running ............. passed > > Building > x86_64:q35:EPYC-IBPB:defconfig:smp2:net,e1000-82545em:efi:mem8G:scsi > [MEGASAS]:hd ... running ....... passed > > Building > x86_64:q35:Opteron_G5:defconfig:smp4:net,i82559c:efi32:mem256:scsi[M > EGASAS2]:hd ... running ....... passed > > Building > x86_64:q35:Opteron_G5:defconfig:smp4:net,i82559c:mem256:scsi[MEGASAS > 2]:hd ... running ...... passed > > Building > x86_64:pc:Opteron_G5:defconfig:smp4:net,i82559c:mem256:scsi[MEGASAS2 > ]:hd ... running ......... passed > > Building x86_64:pc:phenom:defconfig:smp:net,i82559er:mem512:initrd > ... running ......... passed > > Building > x86_64:q35:Opteron_G1:defconfig:smp2:net,i82562:efi:mem1G:initrd ... > running ......... passed > > Building > x86_64:pc:Opteron_G2:defconfig:smp:net,usb:efi32:mem2G:scsi[virtio-p > ci]:hd ... running ......... passed > > Building > x86_64:pc:Opteron_G2:defconfig:smp:net,usb:efi32:mem2G:scsi[virtio-p > ci-old]:hd ... running ......... passed > > Building > x86_64:q35:core2duo:defconfig:smp2:net,i82559a:mem4G:virtio-pci:hd > ... running ...... passed > > Building > x86_64:q35:Broadwell:defconfig:smp4:net,i82558b:efi:mem8G:virtio:hd > ... running ....... passed > > Building > x86_64:q35:Nehalem:defconfig:smp2:net,i82558a:efi32:mem1G:virtio:hd > ... running ...... passed > > Building > x86_64:q35:Icelake-Server:defconfig:preempt:smp4:net,ne2k_pci:efi:me > m2G:virtio:cd ... running ............ passed > > Building > x86_64:q35:Icelake-Server:defconfig:preempt:smp8:net,i82557a:mem4G:n > vme:hd ... running ....... passed > > Building > x86_64:q35:Skylake-Client-IBRS:defconfig:preempt:smp2:net,i82558b:ef > i32:mem1G:sdhci:mmc:hd ... running ...... passed > > Building > x86_64:q35:KnightsMill:defconfig:preempt:smp6:net,i82550:mem512:init > rd ... running ...... passed > > Building > x86_64:q35:Cooperlake:defconfig:smp2:net,usb-ohci:efi:mem1G:scsi[53C > 810]:hd ... running ....... passed > > Building > x86_64:q35:EPYC-Rome:defconfig:smp4:net,igb:mem2G:scsi[53C895A]:hd > ... running .......... passed > > Building x86_64:pc:Opteron_G3:defconfig:nosmp:net,e1000:mem1G:usb:hd > ... running .......... passed > > Building > x86_64:q35:Opteron_G4:defconfig:nosmp:net,ne2k_pci:efi:mem512:ata:hd > ... running ...... passed > > Building > x86_64:q35:Haswell-noTSX-IBRS:defconfig:nosmp:net,pcnet:efi32:mem2G: > ata:hd ... running ...... passed > > I freely confess that I am having a hard time imagining what would > > be CPU dependent in that code. Timing, maybe? Whatever the reason, > > I am not seeing these failures in my testing. > > So which of the following Kconfig options is defined in your > .config? > > CONFIG_TASKS_RCU, CONFIG_TASKS_RUDE_RCU, and CONFIG_TASKS_TRACE_RCU. > > If you have more than one of them, could you please apply this patch > > and show me the corresponding console output from the resulting > hang? > > FWIW, I am not able to repro this issue either. If a .config can be > shared of the problem system, I can try it out to see if it can be > reproduced on my side. > > I do see this now on 5.15 stable: > >TASKS03 ------- 3089 GPs (0.858056/s) >QEMU killed >TASKS03 no success message, 64 successful version messages >!!! PID 3309783 hung at 3781 vs. 3600 seconds > > I have not looked too closely yet. The full test artifacts are here: > > [1]Artifacts of linux-5.15.y 5.15.123 : > /tools/testing/selftests/rcutorture/res/2023.07.28-04.00.44 [Jenkins] > [2]box.joelfernandes.org > [3]apple-touch-icon.png > > Thanks, > > - Joel > > (Apologies if the email is html, I am sending from phone). Heh. I have a script that runs lynx. Which isn't perfect, but usually makes things at least somewhat legible. This looks like the prototypical hard hang with interrupts disabled, which could be anywhere in the kernel, including RCU. I am not seeing this. but the usual cause when I have seen it in the past was deadlock of irq-disabled locks. In one spectacular case, it was a timekeeping failure that messed up a CPU-hotplug operation. If this is reproducible, one trick would be to have a script look at the console.log file, and have it do something (NMI? sysrq? something else?) to qemu if output ceased for too long. One way to do this without messing with the rcutorture scripting is to grab the qemu-cmd file from this run, and then invoke that file from your own script, possibly with suitable modifications to qemu's parameters. Thoughts? Thanx, Paul > Cheers, > - Joel > > Thanx, Paul > > -------------------------------------------------------------------- > ---- > > commit 709a917710dc01798e01750ea628ece4bfc42b7b > > Author: Paul E. McKenney <paulmck(a)kernel.org> > > Date: Thu Jul 27 13:13:46 2023 -0700 > > rcu-tasks: Add printk()s to localize boot-time self-test hang > > Currently, rcu_tasks_initiate_self_tests() prints a message and > then > > initiates self tests on up to three different RCU Tasks flavors. > If one > > of the flavors has a grace-period hang, it is not easy to work out > which > > of the three hung. This commit therefore prints a message prior > to each > > individual test. > > Reported-by: Guenter Roeck <linux(a)roeck-us.net> > > Signed-off-by: Paul E. McKenney <paulmck(a)kernel.org> > > diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h > > index 56c470a489c8..427433c90935 100644 > > --- a/kernel/rcu/tasks.h > > +++ b/kernel/rcu/tasks.h > > @@ -1981,20 +1981,22 @@ static void test_rcu_tasks_callback(struct > rcu_head *rhp) > > static void rcu_tasks_initiate_self_tests(void) > > { > > - pr_info("Running RCU-tasks wait API self tests\n"); > > #ifdef CONFIG_TASKS_RCU > > + pr_info("Running RCU Tasks wait API self tests\n"); > > tests[0].runstart = jiffies; > > synchronize_rcu_tasks(); > > call_rcu_tasks(&tests[0].rh, test_rcu_tasks_callback); > > #endif > > #ifdef CONFIG_TASKS_RUDE_RCU > > + pr_info("Running RCU Tasks Rude wait API self tests\n"); > > tests[1].runstart = jiffies; > > synchronize_rcu_tasks_rude(); > > call_rcu_tasks_rude(&tests[1].rh, test_rcu_tasks_callback); > > #endif > > #ifdef CONFIG_TASKS_TRACE_RCU > > + pr_info("Running RCU Tasks Trace wait API self tests\n"); > > tests[2].runstart = jiffies; > > synchronize_rcu_tasks_trace(); > > call_rcu_tasks_trace(&tests[2].rh, test_rcu_tasks_callback); > >References > > Visible links: > 1. http://box.joelfernandes.org:9080/job/rcutorture_stable/job/linux-5.15.y/la… > 2. http://box.joelfernandes.org:9080/job/rcutorture_stable/job/linux-5.15.y/la… > 3. http://box.joelfernandes.org:9080/job/rcutorture_stable/job/linux-5.15.y/la… > > Hidden links: > 5. http://box.joelfernandes.org:9080/job/rcutorture_stable/job/linux-5.15.y/la…

2 years, 3 months

2
2
0 0

[PATCH 0/4] Venus driver fixes to avoid possible OOB accesses

by Vikash Garodia

This series primarily adds check at relevant places in venus driver where there are possible OOB accesses due to unexpected payload from venus firmware. The patches describes the specific OOB possibility. Please review and share your feedback. Vikash Garodia (4): venus: hfi: add checks to perform sanity on queue pointers venus: hfi: fix the check to handle session buffer requirement venus: hfi: add checks to handle capabilities from firmware venus: hfi_parser: Add check to keep the number of codecs within range drivers/media/platform/qcom/venus/hfi_msgs.c | 2 +- drivers/media/platform/qcom/venus/hfi_parser.c | 27 ++++++++++++++++++++++++++ drivers/media/platform/qcom/venus/hfi_venus.c | 8 ++++++++ 3 files changed, 36 insertions(+), 1 deletion(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 years, 3 months

3
9
0 0

+ nilfs2-fix-use-after-free-of-nilfs_root-in-dirtying-inodes-via-iput.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput has been added to the -mm mm-hotfixes-unstable branch. Its filename is nilfs2-fix-use-after-free-of-nilfs_root-in-dirtying-inodes-via-iput.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Subject: nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput Date: Sat, 29 Jul 2023 04:13:18 +0900 During unmount process of nilfs2, nothing holds nilfs_root structure after nilfs2 detaches its writer in nilfs_detach_log_writer(). Previously, nilfs_evict_inode() could cause use-after-free read for nilfs_root if inodes are left in "garbage_list" and released by nilfs_dispose_list at the end of nilfs_detach_log_writer(), and this bug was fixed by commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()"). However, it turned out that there is another possibility of UAF in the call path where mark_inode_dirty_sync() is called from iput(): nilfs_detach_log_writer() nilfs_dispose_list() iput() mark_inode_dirty_sync() __mark_inode_dirty() nilfs_dirty_inode() __nilfs_mark_inode_dirty() nilfs_load_inode_block() --> causes UAF of nilfs_root struct This can happen after commit 0ae45f63d4ef ("vfs: add support for a lazytime mount option"), which changed iput() to call mark_inode_dirty_sync() on its final reference if i_state has I_DIRTY_TIME flag and i_nlink is non-zero. This issue appears after commit 28a65b49eb53 ("nilfs2: do not write dirty data after degenerating to read-only") when using the syzbot reproducer, but the issue has potentially existed before. Fix this issue by adding a "purging flag" to the nilfs structure, setting that flag while disposing the "garbage_list" and checking it in __nilfs_mark_inode_dirty(). Unlike commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()"), this patch does not rely on ns_writer to determine whether to skip operations, so as not to break recovery on mount. The nilfs_salvage_orphan_logs routine dirties the buffer of salvaged data before attaching the log writer, so changing __nilfs_mark_inode_dirty() to skip the operation when ns_writer is NULL will cause recovery write to fail. The purpose of using the cleanup-only flag is to allow for narrowing of such conditions. Link: https://lkml.kernel.org/r/20230728191318.33047-1-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Reported-by: syzbot+74db8b3087f293d3a13a(a)syzkaller.appspotmail.com Closes: https://lkml.kernel.org/r/000000000000b4e906060113fd63@google.com Fixes: 0ae45f63d4ef ("vfs: add support for a lazytime mount option") Tested-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: <stable(a)vger.kernel.org> # 4.0+ Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/nilfs2/inode.c | 8 ++++++++ fs/nilfs2/segment.c | 2 ++ fs/nilfs2/the_nilfs.h | 2 ++ 3 files changed, 12 insertions(+) --- a/fs/nilfs2/inode.c~nilfs2-fix-use-after-free-of-nilfs_root-in-dirtying-inodes-via-iput +++ a/fs/nilfs2/inode.c @@ -1101,9 +1101,17 @@ int nilfs_set_file_dirty(struct inode *i int __nilfs_mark_inode_dirty(struct inode *inode, int flags) { + struct the_nilfs *nilfs = inode->i_sb->s_fs_info; struct buffer_head *ibh; int err; + /* + * Do not dirty inodes after the log writer has been detached + * and its nilfs_root struct has been freed. + */ + if (unlikely(nilfs_purging(nilfs))) + return 0; + err = nilfs_load_inode_block(inode, &ibh); if (unlikely(err)) { nilfs_warn(inode->i_sb, --- a/fs/nilfs2/segment.c~nilfs2-fix-use-after-free-of-nilfs_root-in-dirtying-inodes-via-iput +++ a/fs/nilfs2/segment.c @@ -2845,6 +2845,7 @@ void nilfs_detach_log_writer(struct supe nilfs_segctor_destroy(nilfs->ns_writer); nilfs->ns_writer = NULL; } + set_nilfs_purging(nilfs); /* Force to free the list of dirty files */ spin_lock(&nilfs->ns_inode_lock); @@ -2857,4 +2858,5 @@ void nilfs_detach_log_writer(struct supe up_write(&nilfs->ns_segctor_sem); nilfs_dispose_list(nilfs, &garbage_list, 1); + clear_nilfs_purging(nilfs); } --- a/fs/nilfs2/the_nilfs.h~nilfs2-fix-use-after-free-of-nilfs_root-in-dirtying-inodes-via-iput +++ a/fs/nilfs2/the_nilfs.h @@ -29,6 +29,7 @@ enum { THE_NILFS_DISCONTINUED, /* 'next' pointer chain has broken */ THE_NILFS_GC_RUNNING, /* gc process is running */ THE_NILFS_SB_DIRTY, /* super block is dirty */ + THE_NILFS_PURGING, /* disposing dirty files for cleanup */ }; /** @@ -208,6 +209,7 @@ THE_NILFS_FNS(INIT, init) THE_NILFS_FNS(DISCONTINUED, discontinued) THE_NILFS_FNS(GC_RUNNING, gc_running) THE_NILFS_FNS(SB_DIRTY, sb_dirty) +THE_NILFS_FNS(PURGING, purging) /* * Mount option operations _ Patches currently in -mm which might be from konishi.ryusuke(a)gmail.com are nilfs2-fix-use-after-free-of-nilfs_root-in-dirtying-inodes-via-iput.patch

2 years, 3 months

1
0
0 0

+ selftests-mm-ksm-fix-incorrect-evaluation-of-parameter.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: selftests: mm: ksm: fix incorrect evaluation of parameter has been added to the -mm mm-hotfixes-unstable branch. Its filename is selftests-mm-ksm-fix-incorrect-evaluation-of-parameter.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Ayush Jain <ayush.jain3(a)amd.com> Subject: selftests: mm: ksm: fix incorrect evaluation of parameter Date: Fri, 28 Jul 2023 22:09:51 +0530 A missing break in kms_tests leads to kselftest hang when the parameter -s is used. In current code flow because of missing break in -s, -t parses args spilled from -s and as -t accepts only valid values as 0,1 so any arg in -s >1 or <0, gets in ksm_test failure This went undetected since, before the addition of option -t, the next case -M would immediately break out of the switch statement but that is no longer the case Add the missing break statement. ----Before---- ./ksm_tests -H -s 100 Invalid merge type ----After---- ./ksm_tests -H -s 100 Number of normal pages: 0 Number of huge pages: 50 Total size: 100 MiB Total time: 0.401732682 s Average speed: 248.922 MiB/s Link: https://lkml.kernel.org/r/20230728163952.4634-1-ayush.jain3@amd.com Fixes: 07115fcc15b4 ("selftests/mm: add new selftests for KSM") Signed-off-by: Ayush Jain <ayush.jain3(a)amd.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Stefan Roesch <shr(a)devkernel.io> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/ksm_tests.c | 1 + 1 file changed, 1 insertion(+) --- a/tools/testing/selftests/mm/ksm_tests.c~selftests-mm-ksm-fix-incorrect-evaluation-of-parameter +++ a/tools/testing/selftests/mm/ksm_tests.c @@ -831,6 +831,7 @@ int main(int argc, char *argv[]) printf("Size must be greater than 0\n"); return KSFT_FAIL; } + break; case 't': { int tmp = atoi(optarg); _ Patches currently in -mm which might be from ayush.jain3(a)amd.com are selftests-mm-ksm-fix-incorrect-evaluation-of-parameter.patch

2 years, 3 months

1
0
0 0

FAILED: patch "[PATCH] keys: Fix linking a duplicate key to a keyring's assoc_array" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x d55901522f96082a43b9842d34867363c0cdbac5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023072356-confirm-embezzle-c962@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: d55901522f96 ("keys: Fix linking a duplicate key to a keyring's assoc_array") f7e47677e39a ("watch_queue: Add a key/keyring notification facility") 0858caa419e6 ("uapi: General notification queue definitions") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d55901522f96082a43b9842d34867363c0cdbac5 Mon Sep 17 00:00:00 2001 From: Petr Pavlu <petr.pavlu(a)suse.com> Date: Thu, 23 Mar 2023 14:04:12 +0100 Subject: [PATCH] keys: Fix linking a duplicate key to a keyring's assoc_array When making a DNS query inside the kernel using dns_query(), the request code can in rare cases end up creating a duplicate index key in the assoc_array of the destination keyring. It is eventually found by a BUG_ON() check in the assoc_array implementation and results in a crash. Example report: [2158499.700025] kernel BUG at ../lib/assoc_array.c:652! [2158499.700039] invalid opcode: 0000 [#1] SMP PTI [2158499.700065] CPU: 3 PID: 31985 Comm: kworker/3:1 Kdump: loaded Not tainted 5.3.18-150300.59.90-default #1 SLE15-SP3 [2158499.700096] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 [2158499.700351] Workqueue: cifsiod cifs_resolve_server [cifs] [2158499.700380] RIP: 0010:assoc_array_insert+0x85f/0xa40 [2158499.700401] Code: ff 74 2b 48 8b 3b 49 8b 45 18 4c 89 e6 48 83 e7 fe e8 95 ec 74 00 3b 45 88 7d db 85 c0 79 d4 0f 0b 0f 0b 0f 0b e8 41 f2 be ff <0f> 0b 0f 0b 81 7d 88 ff ff ff 7f 4c 89 eb 4c 8b ad 58 ff ff ff 0f [2158499.700448] RSP: 0018:ffffc0bd6187faf0 EFLAGS: 00010282 [2158499.700470] RAX: ffff9f1ea7da2fe8 RBX: ffff9f1ea7da2fc1 RCX: 0000000000000005 [2158499.700492] RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000000 [2158499.700515] RBP: ffffc0bd6187fbb0 R08: ffff9f185faf1100 R09: 0000000000000000 [2158499.700538] R10: ffff9f1ea7da2cc0 R11: 000000005ed8cec8 R12: ffffc0bd6187fc28 [2158499.700561] R13: ffff9f15feb8d000 R14: ffff9f1ea7da2fc0 R15: ffff9f168dc0d740 [2158499.700585] FS: 0000000000000000(0000) GS:ffff9f185fac0000(0000) knlGS:0000000000000000 [2158499.700610] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2158499.700630] CR2: 00007fdd94fca238 CR3: 0000000809d8c006 CR4: 00000000003706e0 [2158499.700702] Call Trace: [2158499.700741] ? key_alloc+0x447/0x4b0 [2158499.700768] ? __key_link_begin+0x43/0xa0 [2158499.700790] __key_link_begin+0x43/0xa0 [2158499.700814] request_key_and_link+0x2c7/0x730 [2158499.700847] ? dns_resolver_read+0x20/0x20 [dns_resolver] [2158499.700873] ? key_default_cmp+0x20/0x20 [2158499.700898] request_key_tag+0x43/0xa0 [2158499.700926] dns_query+0x114/0x2ca [dns_resolver] [2158499.701127] dns_resolve_server_name_to_ip+0x194/0x310 [cifs] [2158499.701164] ? scnprintf+0x49/0x90 [2158499.701190] ? __switch_to_asm+0x40/0x70 [2158499.701211] ? __switch_to_asm+0x34/0x70 [2158499.701405] reconn_set_ipaddr_from_hostname+0x81/0x2a0 [cifs] [2158499.701603] cifs_resolve_server+0x4b/0xd0 [cifs] [2158499.701632] process_one_work+0x1f8/0x3e0 [2158499.701658] worker_thread+0x2d/0x3f0 [2158499.701682] ? process_one_work+0x3e0/0x3e0 [2158499.701703] kthread+0x10d/0x130 [2158499.701723] ? kthread_park+0xb0/0xb0 [2158499.701746] ret_from_fork+0x1f/0x40 The situation occurs as follows: * Some kernel facility invokes dns_query() to resolve a hostname, for example, "abcdef". The function registers its global DNS resolver cache as current->cred.thread_keyring and passes the query to request_key_net() -> request_key_tag() -> request_key_and_link(). * Function request_key_and_link() creates a keyring_search_context object. Its match_data.cmp method gets set via a call to type->match_preparse() (resolves to dns_resolver_match_preparse()) to dns_resolver_cmp(). * Function request_key_and_link() continues and invokes search_process_keyrings_rcu() which returns that a given key was not found. The control is then passed to request_key_and_link() -> construct_alloc_key(). * Concurrently to that, a second task similarly makes a DNS query for "abcdef." and its result gets inserted into the DNS resolver cache. * Back on the first task, function construct_alloc_key() first runs __key_link_begin() to determine an assoc_array_edit operation to insert a new key. Index keys in the array are compared exactly as-is, using keyring_compare_object(). The operation finds that "abcdef" is not yet present in the destination keyring. * Function construct_alloc_key() continues and checks if a given key is already present on some keyring by again calling search_process_keyrings_rcu(). This search is done using dns_resolver_cmp() and "abcdef" gets matched with now present key "abcdef.". * The found key is linked on the destination keyring by calling __key_link() and using the previously calculated assoc_array_edit operation. This inserts the "abcdef." key in the array but creates a duplicity because the same index key is already present. Fix the problem by postponing __key_link_begin() in construct_alloc_key() until an actual key which should be linked into the destination keyring is determined. [jarkko(a)kernel.org: added a fixes tag and cc to stable] Cc: stable(a)vger.kernel.org # v5.3+ Fixes: df593ee23e05 ("keys: Hoist locking out of __key_link_begin()") Signed-off-by: Petr Pavlu <petr.pavlu(a)suse.com> Reviewed-by: Joey Lee <jlee(a)suse.com> Reviewed-by: Jarkko Sakkinen <jarkko(a)kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> diff --git a/security/keys/request_key.c b/security/keys/request_key.c index 07a0ef2baacd..a7673ad86d18 100644 --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -401,17 +401,21 @@ static int construct_alloc_key(struct keyring_search_context *ctx, set_bit(KEY_FLAG_USER_CONSTRUCT, &key->flags); if (dest_keyring) { - ret = __key_link_lock(dest_keyring, &ctx->index_key); + ret = __key_link_lock(dest_keyring, &key->index_key); if (ret < 0) goto link_lock_failed; - ret = __key_link_begin(dest_keyring, &ctx->index_key, &edit); - if (ret < 0) - goto link_prealloc_failed; } - /* attach the key to the destination keyring under lock, but we do need + /* + * Attach the key to the destination keyring under lock, but we do need * to do another check just in case someone beat us to it whilst we - * waited for locks */ + * waited for locks. + * + * The caller might specify a comparison function which looks for keys + * that do not exactly match but are still equivalent from the caller's + * perspective. The __key_link_begin() operation must be done only after + * an actual key is determined. + */ mutex_lock(&key_construction_mutex); rcu_read_lock(); @@ -420,12 +424,16 @@ static int construct_alloc_key(struct keyring_search_context *ctx, if (!IS_ERR(key_ref)) goto key_already_present; - if (dest_keyring) + if (dest_keyring) { + ret = __key_link_begin(dest_keyring, &key->index_key, &edit); + if (ret < 0) + goto link_alloc_failed; __key_link(dest_keyring, key, &edit); + } mutex_unlock(&key_construction_mutex); if (dest_keyring) - __key_link_end(dest_keyring, &ctx->index_key, edit); + __key_link_end(dest_keyring, &key->index_key, edit); mutex_unlock(&user->cons_lock); *_key = key; kleave(" = 0 [%d]", key_serial(key)); @@ -438,10 +446,13 @@ static int construct_alloc_key(struct keyring_search_context *ctx, mutex_unlock(&key_construction_mutex); key = key_ref_to_ptr(key_ref); if (dest_keyring) { + ret = __key_link_begin(dest_keyring, &key->index_key, &edit); + if (ret < 0) + goto link_alloc_failed_unlocked; ret = __key_link_check_live_key(dest_keyring, key); if (ret == 0) __key_link(dest_keyring, key, &edit); - __key_link_end(dest_keyring, &ctx->index_key, edit); + __key_link_end(dest_keyring, &key->index_key, edit); if (ret < 0) goto link_check_failed; } @@ -456,8 +467,10 @@ static int construct_alloc_key(struct keyring_search_context *ctx, kleave(" = %d [linkcheck]", ret); return ret; -link_prealloc_failed: - __key_link_end(dest_keyring, &ctx->index_key, edit); +link_alloc_failed: + mutex_unlock(&key_construction_mutex); +link_alloc_failed_unlocked: + __key_link_end(dest_keyring, &key->index_key, edit); link_lock_failed: mutex_unlock(&user->cons_lock); key_put(key);

2 years, 3 months

2
1
0 0

FAILED: patch "[PATCH] mptcp: do not rely on implicit state check in mptcp_listen()" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 0226436acf2495cde4b93e7400e5a87305c26054 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023072119-skipping-penalize-15f0@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 0226436acf24 ("mptcp: do not rely on implicit state check in mptcp_listen()") cfdcfeed6449 ("mptcp: introduce 'sk' to replace 'sock->sk' in mptcp_listen()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0226436acf2495cde4b93e7400e5a87305c26054 Mon Sep 17 00:00:00 2001 From: Paolo Abeni <pabeni(a)redhat.com> Date: Tue, 4 Jul 2023 22:44:34 +0200 Subject: [PATCH] mptcp: do not rely on implicit state check in mptcp_listen() Since the blamed commit, closing the first subflow resets the first subflow socket state to SS_UNCONNECTED. The current mptcp listen implementation relies only on such state to prevent touching not-fully-disconnected sockets. Incoming mptcp fastclose (or paired endpoint removal) unconditionally closes the first subflow. All the above allows an incoming fastclose followed by a listen() call to successfully race with a blocking recvmsg(), potentially causing the latter to hit a divide by zero bug in cleanup_rbuf/__tcp_select_window(). Address the issue explicitly checking the msk socket state in mptcp_listen(). An alternative solution would be moving the first subflow socket state update into mptcp_disconnect(), but in the long term the first subflow socket should be removed: better avoid relaying on it for internal consistency check. Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation") Cc: stable(a)vger.kernel.org Reported-by: Christoph Paasch <cpaasch(a)apple.com> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/414 Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Reviewed-by: Matthieu Baerts <matthieu.baerts(a)tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 489a3defdde5..3613489eb6e3 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -3703,6 +3703,11 @@ static int mptcp_listen(struct socket *sock, int backlog) pr_debug("msk=%p", msk); lock_sock(sk); + + err = -EINVAL; + if (sock->state != SS_UNCONNECTED || sock->type != SOCK_STREAM) + goto unlock; + ssock = __mptcp_nmpc_socket(msk); if (IS_ERR(ssock)) { err = PTR_ERR(ssock);

2 years, 3 months

2
2
0 0

[PATCH net] batman-adv: Do not get eth header before batadv_check_management_packet

by Remi Pommarel

If received skb in batadv_v_elp_packet_recv or batadv_v_ogm_packet_recv is either cloned or non linearized then its data buffer will be reallocated by batadv_check_management_packet when skb_cow or skb_linearize get called. Thus geting ethernet header address inside skb data buffer before batadv_check_management_packet had any chance to reallocate it could lead to the following kernel panic: Unable to handle kernel paging request at virtual address ffffff8020ab069a Mem abort info: ESR = 0x96000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000040f45000 [ffffff8020ab069a] pgd=180000007fffa003, p4d=180000007fffa003, pud=180000007fffa003, pmd=180000007fefe003, pte=0068000020ab0706 Internal error: Oops: 96000007 [#1] SMP Modules linked in: ahci_mvebu libahci_platform libahci dvb_usb_af9035 dvb_usb_dib0700 dib0070 dib7000m dibx000_common ath11k_pci ath10k_pci ath10k_core mwl8k_new nf_nat_sip nf_conntrack_sip xhci_plat_hcd xhci_hcd nf_nat_pptp nf_conntrack_pptp at24 sbsa_gwdt CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.15.42-00066-g3242268d425c-dirty #550 Hardware name: A8k (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : batadv_is_my_mac+0x60/0xc0 lr : batadv_v_ogm_packet_recv+0x98/0x5d0 sp : ffffff8000183820 x29: ffffff8000183820 x28: 0000000000000001 x27: ffffff8014f9af00 x26: 0000000000000000 x25: 0000000000000543 x24: 0000000000000003 x23: ffffff8020ab0580 x22: 0000000000000110 x21: ffffff80168ae880 x20: 0000000000000000 x19: ffffff800b561000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00dc098924ae0032 x14: 0f0405433e0054b0 x13: ffffffff00000080 x12: 0000004000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : ffffffc076dae000 x6 : ffffff8000183700 x5 : ffffffc00955e698 x4 : ffffff80168ae000 x3 : ffffff80059cf000 x2 : ffffff800b561000 x1 : ffffff8020ab0696 x0 : ffffff80168ae880 Call trace: batadv_is_my_mac+0x60/0xc0 batadv_v_ogm_packet_recv+0x98/0x5d0 batadv_batman_skb_recv+0x1b8/0x244 __netif_receive_skb_core.isra.0+0x440/0xc74 __netif_receive_skb_one_core+0x14/0x20 netif_receive_skb+0x68/0x140 br_pass_frame_up+0x70/0x80 br_handle_frame_finish+0x108/0x284 br_handle_frame+0x190/0x250 __netif_receive_skb_core.isra.0+0x240/0xc74 __netif_receive_skb_list_core+0x6c/0x90 netif_receive_skb_list_internal+0x1f4/0x310 napi_complete_done+0x64/0x1d0 gro_cell_poll+0x7c/0xa0 __napi_poll+0x34/0x174 net_rx_action+0xf8/0x2a0 _stext+0x12c/0x2ac run_ksoftirqd+0x4c/0x7c smpboot_thread_fn+0x120/0x210 kthread+0x140/0x150 ret_from_fork+0x10/0x20 Code: f9403844 eb03009f 54fffee1 f94 Thus ethernet header address should only be fetched after batadv_check_management_packet has been called. Fixes: 0da0035942d4 ("batman-adv: OGMv2 - add basic infrastructure") Signed-off-by: Remi Pommarel <repk(a)triplefau.lt> --- net/batman-adv/bat_v_elp.c | 3 ++- net/batman-adv/bat_v_ogm.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/net/batman-adv/bat_v_elp.c b/net/batman-adv/bat_v_elp.c index acff565849ae..1d704574e6bf 100644 --- a/net/batman-adv/bat_v_elp.c +++ b/net/batman-adv/bat_v_elp.c @@ -505,7 +505,7 @@ int batadv_v_elp_packet_recv(struct sk_buff *skb, struct batadv_priv *bat_priv = netdev_priv(if_incoming->soft_iface); struct batadv_elp_packet *elp_packet; struct batadv_hard_iface *primary_if; - struct ethhdr *ethhdr = (struct ethhdr *)skb_mac_header(skb); + struct ethhdr *ethhdr; bool res; int ret = NET_RX_DROP; @@ -513,6 +513,7 @@ int batadv_v_elp_packet_recv(struct sk_buff *skb, if (!res) goto free_skb; + ethhdr = eth_hdr(skb); if (batadv_is_my_mac(bat_priv, ethhdr->h_source)) goto free_skb; diff --git a/net/batman-adv/bat_v_ogm.c b/net/batman-adv/bat_v_ogm.c index e710e9afe78f..84eac41d4658 100644 --- a/net/batman-adv/bat_v_ogm.c +++ b/net/batman-adv/bat_v_ogm.c @@ -985,7 +985,7 @@ int batadv_v_ogm_packet_recv(struct sk_buff *skb, { struct batadv_priv *bat_priv = netdev_priv(if_incoming->soft_iface); struct batadv_ogm2_packet *ogm_packet; - struct ethhdr *ethhdr = eth_hdr(skb); + struct ethhdr *ethhdr; int ogm_offset; u8 *packet_pos; int ret = NET_RX_DROP; @@ -999,6 +999,7 @@ int batadv_v_ogm_packet_recv(struct sk_buff *skb, if (!batadv_check_management_packet(skb, if_incoming, BATADV_OGM2_HLEN)) goto free_skb; + ethhdr = eth_hdr(skb); if (batadv_is_my_mac(bat_priv, ethhdr->h_source)) goto free_skb; -- 2.40.0

2 years, 3 months

3
2
0 0

[PATCH 001/321] fuse: add feature flag for expire-only

by jiangziqi＠haohandata.com.cn

From: Miklos Szeredi <mszeredi(a)redhat.com> Add an init flag idicating whether the FUSE_EXPIRE_ONLY flag of FUSE_NOTIFY_INVAL_ENTRY is effective. This is needed for backports of this feature, otherwise the server could just check the protocol version. Fixes: 4f8d37020e1f ("fuse: add "expire only" mode to FUSE_NOTIFY_INVAL_ENTRY") Cc: <stable(a)vger.kernel.org> # v6.2 Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> --- fs/fuse/inode.c | 3 ++- include/uapi/linux/fuse.h | 3 +++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c index d66070af145d..660be31aaabc 100644 --- a/fs/fuse/inode.c +++ b/fs/fuse/inode.c @@ -1254,7 +1254,8 @@ void fuse_send_init(struct fuse_mount *fm) FUSE_ABORT_ERROR | FUSE_MAX_PAGES | FUSE_CACHE_SYMLINKS | FUSE_NO_OPENDIR_SUPPORT | FUSE_EXPLICIT_INVAL_DATA | FUSE_HANDLE_KILLPRIV_V2 | FUSE_SETXATTR_EXT | FUSE_INIT_EXT | - FUSE_SECURITY_CTX | FUSE_CREATE_SUPP_GROUP; + FUSE_SECURITY_CTX | FUSE_CREATE_SUPP_GROUP | + FUSE_HAS_EXPIRE_ONLY; #ifdef CONFIG_FUSE_DAX if (fm->fc->dax) flags |= FUSE_MAP_ALIGNMENT; diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h index 1b9d0dfae72d..b3fcab13fcd3 100644 --- a/include/uapi/linux/fuse.h +++ b/include/uapi/linux/fuse.h @@ -206,6 +206,7 @@ * - add extension header * - add FUSE_EXT_GROUPS * - add FUSE_CREATE_SUPP_GROUP + * - add FUSE_HAS_EXPIRE_ONLY */ #ifndef _LINUX_FUSE_H @@ -369,6 +370,7 @@ struct fuse_file_lock { * FUSE_HAS_INODE_DAX: use per inode DAX * FUSE_CREATE_SUPP_GROUP: add supplementary group info to create, mkdir, * symlink and mknod (single group that matches parent) + * FUSE_HAS_EXPIRE_ONLY: kernel supports expiry-only entry invalidation */ #define FUSE_ASYNC_READ (1 << 0) #define FUSE_POSIX_LOCKS (1 << 1) @@ -406,6 +408,7 @@ struct fuse_file_lock { #define FUSE_SECURITY_CTX (1ULL << 32) #define FUSE_HAS_INODE_DAX (1ULL << 33) #define FUSE_CREATE_SUPP_GROUP (1ULL << 34) +#define FUSE_HAS_EXPIRE_ONLY (1ULL << 35) /** * CUSE INIT request/reply flags -- 2.41.0

2 years, 3 months

1
0
0 0

[PATCH v1 2/4] mm/gup: Make follow_page() succeed again on PROT_NONE PTEs/PMDs

by David Hildenbrand

We accidentally enforced PROT_NONE PTE/PMD permission checks for follow_page() like we do for get_user_pages() and friends. That was undesired, because follow_page() is usually only used to lookup a currently mapped page, not to actually access it. Further, follow_page() does not actually trigger fault handling, but instead simply fails. Let's restore that behavior by conditionally setting FOLL_FORCE if FOLL_WRITE is not set. This way, for example KSM and migration code will no longer fail on PROT_NONE mapped PTEs/PMDS. Handling this internally doesn't require us to add any new FOLL_FORCE usage outside of GUP code. While at it, refuse to accept FOLL_FORCE: we don't even perform VMA permission checks like in check_vma_flags(), so especially FOLL_FORCE|FOLL_WRITE would be dodgy. This issue was identified by code inspection. We'll add some documentation regarding FOLL_FORCE next. Reported-by: Peter Xu <peterx(a)redhat.com> Fixes: 474098edac26 ("mm/gup: replace FOLL_NUMA by gup_can_follow_protnone()") Cc: <stable(a)vger.kernel.org> Signed-off-by: David Hildenbrand <david(a)redhat.com> --- mm/gup.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/mm/gup.c b/mm/gup.c index 2493ffa10f4b..da9a5cc096ac 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -841,9 +841,17 @@ struct page *follow_page(struct vm_area_struct *vma, unsigned long address, if (vma_is_secretmem(vma)) return NULL; - if (WARN_ON_ONCE(foll_flags & FOLL_PIN)) + if (WARN_ON_ONCE(foll_flags & (FOLL_PIN | FOLL_FORCE))) return NULL; + /* + * Traditionally, follow_page() succeeded on PROT_NONE-mapped pages + * but failed follow_page(FOLL_WRITE) on R/O-mapped pages. Let's + * keep these semantics by setting FOLL_FORCE if FOLL_WRITE is not set. + */ + if (!(foll_flags & FOLL_WRITE)) + foll_flags |= FOLL_FORCE; + page = follow_page_mask(vma, address, foll_flags, &ctx); if (ctx.pgmap) put_dev_pagemap(ctx.pgmap); -- 2.41.0

2 years, 3 months

2
3
0 0

[git:media_stage/fixes] media: uvcvideo: Fix menu count handling for userspace XU mappings

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: uvcvideo: Fix menu count handling for userspace XU mappings Author: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Date: Tue Jun 6 18:55:30 2023 +0200 When commit 716c330433e3 ("media: uvcvideo: Use standard names for menus") reworked the handling of menu controls, it inadvertently replaced a GENMASK(n - 1, 0) with a BIT_MASK(n). The latter isn't equivalent to the former, which broke adding XU mappings from userspace. Fix it. Link: https://lore.kernel.org/linux-media/468a36ec-c3ac-cb47-e12f-5906239ae3cd@sp… Cc: stable(a)vger.kernel.org Reported-by: Poncho <poncho(a)spahan.ch> Fixes: 716c330433e3 ("media: uvcvideo: Use standard names for menus") Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Reviewed-by: Ricardo Ribalda <ribalda(a)chromium.org> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> drivers/media/usb/uvc/uvc_v4l2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c index 5ac2a424b13d..f4988f03640a 100644 --- a/drivers/media/usb/uvc/uvc_v4l2.c +++ b/drivers/media/usb/uvc/uvc_v4l2.c @@ -45,7 +45,7 @@ static int uvc_control_add_xu_mapping(struct uvc_video_chain *chain, map->menu_names = NULL; map->menu_mapping = NULL; - map->menu_mask = BIT_MASK(xmap->menu_count); + map->menu_mask = GENMASK(xmap->menu_count - 1, 0); size = xmap->menu_count * sizeof(*map->menu_mapping); map->menu_mapping = kzalloc(size, GFP_KERNEL);

2 years, 3 months

1
0
0 0

[PATCH] venus: hfi_parser: Add check to keep the number of codecs within range

by Vikash Garodia

Supported codec bitmask is populated from the payload from venus firmware. There is a possible case when all the bits in the codec bitmask is set. In such case, core cap for decoder is filled and MAX_CODEC_NUM is utilized. Now while filling the caps for encoder, it can lead to access the caps array beyong 32 index. Hence leading to OOB write. The fix counts the supported encoder and decoder. If the count is more than max, then it skips accessing the caps. Cc: stable(a)vger.kernel.org Fixes: 1a73374a04e5 ("media: venus: hfi_parser: add common capability parser") Signed-off-by: Vikash Garodia <quic_vgarodia(a)quicinc.com> --- drivers/media/platform/qcom/venus/hfi_parser.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/media/platform/qcom/venus/hfi_parser.c b/drivers/media/platform/qcom/venus/hfi_parser.c index ec73cac..651e215 100644 --- a/drivers/media/platform/qcom/venus/hfi_parser.c +++ b/drivers/media/platform/qcom/venus/hfi_parser.c @@ -14,11 +14,26 @@ typedef void (*func)(struct hfi_plat_caps *cap, const void *data, unsigned int size); +static int count_setbits(u32 input) +{ + u32 count = 0; + + while (input > 0) { + if ((input & 1) == 1) + count++; + input >>= 1; + } + return count; +} + static void init_codecs(struct venus_core *core) { struct hfi_plat_caps *caps = core->caps, *cap; unsigned long bit; + if ((count_setbits(core->dec_codecs) + count_setbits(core->enc_codecs)) > MAX_CODEC_NUM) + return; + for_each_set_bit(bit, &core->dec_codecs, MAX_CODEC_NUM) { cap = &caps[core->codecs_count++]; cap->codec = BIT(bit); -- 2.7.4

2 years, 3 months

1
0
0 0

[PATCH] venus: hfi_parser: Add check to keep the number of codecs within range

by Vikash Garodia

Supported codec bitmask is populated from the payload from venus firmware. There is a possible case when all the bits in the codec bitmask is set. In such case, core cap for decoder is filled and MAX_CODEC_NUM is utilized. Now while filling the caps for encoder, it can lead to access the caps array beyong 32 index. Hence leading to OOB write. The fix counts the supported encoder and decoder. If the count is more than max, then it skips accessing the caps. Cc: stable(a)vger.kernel.org Fixes: 1a73374a04e5 ("media: venus: hfi_parser: add common capability parser") Signed-off-by: Vikash Garodia <quic_vgarodia(a)quicinc.com> --- drivers/media/platform/qcom/venus/hfi_parser.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/media/platform/qcom/venus/hfi_parser.c b/drivers/media/platform/qcom/venus/hfi_parser.c index ec73cac..651e215 100644 --- a/drivers/media/platform/qcom/venus/hfi_parser.c +++ b/drivers/media/platform/qcom/venus/hfi_parser.c @@ -14,11 +14,26 @@ typedef void (*func)(struct hfi_plat_caps *cap, const void *data, unsigned int size); +static int count_setbits(u32 input) +{ + u32 count = 0; + + while (input > 0) { + if ((input & 1) == 1) + count++; + input >>= 1; + } + return count; +} + static void init_codecs(struct venus_core *core) { struct hfi_plat_caps *caps = core->caps, *cap; unsigned long bit; + if ((count_setbits(core->dec_codecs) + count_setbits(core->enc_codecs)) > MAX_CODEC_NUM) + return; + for_each_set_bit(bit, &core->dec_codecs, MAX_CODEC_NUM) { cap = &caps[core->codecs_count++]; cap->codec = BIT(bit); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 years, 3 months

1
0
0 0

Re: RPET SHOPPING BAG 2023/7/28 12:54:33

by Carrie | Oreadybags

Hi, linux-stable-mirror Wish you have a nice day! This is Carrie. Do you may need below customized non-woven bags for your branding activities or products packing? We are bag factory directly who has been in this field for more than 12 years. Below is one of non-woven bags we did for your reference. Item: Ultrasonic Non-woven Bag Fabric: 80g non-woven fabric Size: 40w x 40h x 10d cm Printing: 2 colors-2 sides MOQ: 5,000 pcs Price: Ask me, please! Lead Time: 15-25 days All bags details, including size/ fabric/ printing/ package, can be customized according to your request. Please reply directly if you need any further information. Best regards, Carrie Pan +86 18906051620 Please kindly reply “remove” if you are not interested. Wish you have a nice day! But was she mourning— or just confused? Do non-human animals grieve? 00:48 This question is tricky It's all about just building your resume In fact, it was 1987" 00:25 And imagine your musician saying, "No, it's not true

2 years, 3 months

1
0
0 0

[PATCH] [v4] bpf: fix bpf_probe_read_kernel prototype mismatch

by Arnd Bergmann

From: Arnd Bergmann <arnd(a)arndb.de> bpf_probe_read_kernel() has a __weak definition in core.c and another definition with an incompatible prototype in kernel/trace/bpf_trace.c, when CONFIG_BPF_EVENTS is enabled. Since the two are incompatible, there cannot be a shared declaration in a header file, but the lack of a prototype causes a W=1 warning: kernel/bpf/core.c:1638:12: error: no previous prototype for 'bpf_probe_read_kernel' [-Werror=missing-prototypes] On 32-bit architectures, the local prototype u64 __weak bpf_probe_read_kernel(void *dst, u32 size, const void *unsafe_ptr) passes arguments in other registers as the one in bpf_trace.c BPF_CALL_3(bpf_probe_read_kernel, void *, dst, u32, size, const void *, unsafe_ptr) which uses 64-bit arguments in pairs of registers. As both versions of the function are fairly simple and only really differ in one line, just move them into a header file as an inline function that does not add any overhead for the bpf_trace.c callers and actually avoids a function call for the other one. Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/ac25cb0f-b804-1649-3afb-1dc6138c2716@iogearbox.… Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> -- v4: rewrite again to use a shared inline helper v3: clarify changelog text further. v2: rewrite completely to fix the mismatch. --- include/linux/bpf.h | 12 ++++++++++++ kernel/bpf/core.c | 10 ++-------- kernel/trace/bpf_trace.c | 11 ----------- 3 files changed, 14 insertions(+), 19 deletions(-) diff --git a/include/linux/bpf.h b/include/linux/bpf.h index ceaa8c23287fc..abe75063630b8 100644 --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -2661,6 +2661,18 @@ static inline void bpf_dynptr_set_rdonly(struct bpf_dynptr_kern *ptr) } #endif /* CONFIG_BPF_SYSCALL */ +static __always_inline int +bpf_probe_read_kernel_common(void *dst, u32 size, const void *unsafe_ptr) +{ + int ret = -EFAULT; + + if (IS_ENABLED(CONFIG_BPF_EVENTS)) + ret = copy_from_kernel_nofault(dst, unsafe_ptr, size); + if (unlikely(ret < 0)) + memset(dst, 0, size); + return ret; +} + void __bpf_free_used_btfs(struct bpf_prog_aux *aux, struct btf_mod_pair *used_btfs, u32 len); diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c index dd70c58c9d3a3..9cdf53bfb8bd3 100644 --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -1634,12 +1634,6 @@ bool bpf_opcode_in_insntable(u8 code) } #ifndef CONFIG_BPF_JIT_ALWAYS_ON -u64 __weak bpf_probe_read_kernel(void *dst, u32 size, const void *unsafe_ptr) -{ - memset(dst, 0, size); - return -EFAULT; -} - /** * ___bpf_prog_run - run eBPF program on a given context * @regs: is the array of MAX_BPF_EXT_REG eBPF pseudo-registers @@ -1930,8 +1924,8 @@ static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn) DST = *(SIZE *)(unsigned long) (SRC + insn->off); \ CONT; \ LDX_PROBE_MEM_##SIZEOP: \ - bpf_probe_read_kernel(&DST, sizeof(SIZE), \ - (const void *)(long) (SRC + insn->off)); \ + bpf_probe_read_kernel_common(&DST, sizeof(SIZE), \ + (const void *)(long) (SRC + insn->off)); \ DST = *((SIZE *)&DST); \ CONT; diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index c92eb8c6ff08d..83bde2475ae54 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -223,17 +223,6 @@ const struct bpf_func_proto bpf_probe_read_user_str_proto = { .arg3_type = ARG_ANYTHING, }; -static __always_inline int -bpf_probe_read_kernel_common(void *dst, u32 size, const void *unsafe_ptr) -{ - int ret; - - ret = copy_from_kernel_nofault(dst, unsafe_ptr, size); - if (unlikely(ret < 0)) - memset(dst, 0, size); - return ret; -} - BPF_CALL_3(bpf_probe_read_kernel, void *, dst, u32, size, const void *, unsafe_ptr) { -- 2.39.2

2 years, 3 months

2
1
0 0

[PATCH 1/2] perf build: Update build rule for generated files

by Namhyung Kim

The bison and flex generate C files from the source (.y and .l) files. When O= option is used, they are saved in a separate directory but the default build rule assumes the .C files are in the source directory. So it might read invalid file if there are generated files from an old version. The same is true for the pmu-events files. For example, the following command would cause a build failure: $ git checkout v6.3 $ make -C tools/perf # build in the same directory $ git checkout v6.5-rc2 $ mkdir build # create a build directory $ make -C tools/perf O=build # build in a different directory but it # refers files in the source directory Let's update the build rule to specify those cases explicitly to depend on the files in the output directory. Note that it's not a complete fix and it needs the next patch for the include path too. Fixes: 80eeb67fe577 ("perf jevents: Program to convert JSON file") Cc: stable(a)vger.kernel.org Signed-off-by: Namhyung Kim <namhyung(a)kernel.org> --- tools/build/Makefile.build | 8 ++++++++ tools/perf/pmu-events/Build | 4 ++++ 2 files changed, 12 insertions(+) diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build index 89430338a3d9..f9396696fcbf 100644 --- a/tools/build/Makefile.build +++ b/tools/build/Makefile.build @@ -117,6 +117,14 @@ $(OUTPUT)%.s: %.c FORCE $(call rule_mkdir) $(call if_changed_dep,cc_s_c) +$(OUTPUT)%-bison.o: $(OUTPUT)%-bison.c FORCE + $(call rule_mkdir) + $(call if_changed_dep,$(host)cc_o_c) + +$(OUTPUT)%-flex.o: $(OUTPUT)%-flex.c FORCE + $(call rule_mkdir) + $(call if_changed_dep,$(host)cc_o_c) + # Gather build data: # obj-y - list of build objects # subdir-y - list of directories to nest diff --git a/tools/perf/pmu-events/Build b/tools/perf/pmu-events/Build index 150765f2baee..f38a27765604 100644 --- a/tools/perf/pmu-events/Build +++ b/tools/perf/pmu-events/Build @@ -35,3 +35,7 @@ $(PMU_EVENTS_C): $(JSON) $(JSON_TEST) $(JEVENTS_PY) $(METRIC_PY) $(METRIC_TEST_L $(call rule_mkdir) $(Q)$(call echo-cmd,gen)$(PYTHON) $(JEVENTS_PY) $(JEVENTS_ARCH) $(JEVENTS_MODEL) pmu-events/arch $@ endif + +$(OUTPUT)pmu-events/pmu-events.o: $(PMU_EVENTS_C) + $(call rule_mkdir) + $(call if_changed_dep,$(host)cc_o_c) -- 2.41.0.487.g6d72f3e995-goog

2 years, 3 months

3
9
0 0

[PATCH v1 1/4] smaps: Fix the abnormal memory statistics obtained through /proc/pid/smaps

by David Hildenbrand

From: liubo <liubo254(a)huawei.com> In commit 474098edac26 ("mm/gup: replace FOLL_NUMA by gup_can_follow_protnone()"), FOLL_NUMA was removed and replaced by the gup_can_follow_protnone interface. However, for the case where the user-mode process uses transparent huge pages, when analyzing the memory usage through /proc/pid/smaps_rollup, the obtained memory usage is not consistent with the RSS in /proc/pid/status. Related examples are as follows: cat /proc/15427/status VmRSS: 20973024 kB RssAnon: 20971616 kB RssFile: 1408 kB RssShmem: 0 kB cat /proc/15427/smaps_rollup 00400000-7ffcc372d000 ---p 00000000 00:00 0 [rollup] Rss: 14419432 kB Pss: 14418079 kB Pss_Dirty: 14418016 kB Pss_Anon: 14418016 kB Pss_File: 63 kB Pss_Shmem: 0 kB Anonymous: 14418016 kB LazyFree: 0 kB AnonHugePages: 14417920 kB The root cause is that the traversal In the page table, the number of pages obtained by smaps_pmd_entry does not include the pages corresponding to PROTNONE,resulting in a different situation. Therefore, when obtaining pages through the follow_trans_huge_pmd interface, add the FOLL_FORCE flag to count the pages corresponding to PROTNONE to solve the above problem. Signed-off-by: liubo <liubo254(a)huawei.com> Cc: stable(a)vger.kernel.org Fixes: 474098edac26 ("mm/gup: replace FOLL_NUMA by gup_can_follow_protnone()") Signed-off-by: David Hildenbrand <david(a)redhat.com> # AKPM fixups, cc stable Signed-off-by: David Hildenbrand <david(a)redhat.com> --- fs/proc/task_mmu.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index c1e6531cb02a..7075ce11dc7d 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -571,8 +571,12 @@ static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr, bool migration = false; if (pmd_present(*pmd)) { - /* FOLL_DUMP will return -EFAULT on huge zero page */ - page = follow_trans_huge_pmd(vma, addr, pmd, FOLL_DUMP); + /* + * FOLL_DUMP will return -EFAULT on huge zero page + * FOLL_FORCE follow a PROT_NONE mapped page + */ + page = follow_trans_huge_pmd(vma, addr, pmd, + FOLL_DUMP | FOLL_FORCE); } else if (unlikely(thp_migration_supported() && is_swap_pmd(*pmd))) { swp_entry_t entry = pmd_to_swp_entry(*pmd); -- 2.41.0

2 years, 3 months

1
0
0 0

[merged mm-hotfixes-stable] mm-memory-failure-fix-hardware-poison-check-in-unpoison_memory.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/memory-failure: fix hardware poison check in unpoison_memory() has been removed from the -mm tree. Its filename was mm-memory-failure-fix-hardware-poison-check-in-unpoison_memory.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Sidhartha Kumar <sidhartha.kumar(a)oracle.com> Subject: mm/memory-failure: fix hardware poison check in unpoison_memory() Date: Mon, 17 Jul 2023 11:18:12 -0700 It was pointed out[1] that using folio_test_hwpoison() is wrong as we need to check the indiviual page that has poison. folio_test_hwpoison() only checks the head page so go back to using PageHWPoison(). User-visible effects include existing hwpoison-inject tests possibly failing as unpoisoning a single subpage could lead to unpoisoning an entire folio. Memory unpoisoning could also not work as expected as the function will break early due to only checking the head page and not the actually poisoned subpage. [1]: https://lore.kernel.org/lkml/ZLIbZygG7LqSI9xe@casper.infradead.org/ Link: https://lkml.kernel.org/r/20230717181812.167757-1-sidhartha.kumar@oracle.com Fixes: a6fddef49eef ("mm/memory-failure: convert unpoison_memory() to folios") Signed-off-by: Sidhartha Kumar <sidhartha.kumar(a)oracle.com> Reported-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Acked-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com> Reviewed-by: Miaohe Lin <linmiaohe(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory-failure.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/memory-failure.c~mm-memory-failure-fix-hardware-poison-check-in-unpoison_memory +++ a/mm/memory-failure.c @@ -2487,7 +2487,7 @@ int unpoison_memory(unsigned long pfn) goto unlock_mutex; } - if (!folio_test_hwpoison(folio)) { + if (!PageHWPoison(p)) { unpoison_pr_info("Unpoison: Page was already unpoisoned %#lx\n", pfn, &unpoison_rs); goto unlock_mutex; _ Patches currently in -mm which might be from sidhartha.kumar(a)oracle.com are mm-increase-usage-of-folio_next_index-helper.patch mm-memory-convert-do_page_mkwrite-to-use-folios.patch mm-memory-convert-wp_page_shared-to-use-folios.patch mm-memory-convert-do_shared_fault-to-folios.patch mm-memory-convert-do_read_fault-to-use-folios.patch mm-memory-pass-folio-into-do_page_mkwrite.patch mm-hugetlb-get-rid-of-page_hstate.patch

2 years, 3 months

1
0
0 0

[merged mm-hotfixes-stable] proc-vmcore-fix-signedness-bug-in-read_from_oldmem.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: proc/vmcore: fix signedness bug in read_from_oldmem() has been removed from the -mm tree. Its filename was proc-vmcore-fix-signedness-bug-in-read_from_oldmem.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Dan Carpenter <dan.carpenter(a)linaro.org> Subject: proc/vmcore: fix signedness bug in read_from_oldmem() Date: Tue, 25 Jul 2023 20:03:16 +0300 The bug is the error handling: if (tmp < nr_bytes) { "tmp" can hold negative error codes but because "nr_bytes" is type size_t the negative error codes are treated as very high positive values (success). Fix this by changing "nr_bytes" to type ssize_t. The "nr_bytes" variable is used to store values between 1 and PAGE_SIZE and they can fit in ssize_t without any issue. Link: https://lkml.kernel.org/r/b55f7eed-1c65-4adc-95d1-6c7c65a54a6e@moroto.mount… Fixes: 5d8de293c224 ("vmcore: convert copy_oldmem_page() to take an iov_iter") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Reviewed-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Acked-by: Baoquan He <bhe(a)redhat.com> Cc: Dave Young <dyoung(a)redhat.com> Cc: Vivek Goyal <vgoyal(a)redhat.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/vmcore.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/proc/vmcore.c~proc-vmcore-fix-signedness-bug-in-read_from_oldmem +++ a/fs/proc/vmcore.c @@ -132,7 +132,7 @@ ssize_t read_from_oldmem(struct iov_iter u64 *ppos, bool encrypted) { unsigned long pfn, offset; - size_t nr_bytes; + ssize_t nr_bytes; ssize_t read = 0, tmp; int idx; _ Patches currently in -mm which might be from dan.carpenter(a)linaro.org are

2 years, 3 months

1
0
0 0

[merged mm-hotfixes-stable] mm-lock-vma-in-dup_anon_vma-before-setting-anon_vma.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: lock VMA in dup_anon_vma() before setting ->anon_vma has been removed from the -mm tree. Its filename was mm-lock-vma-in-dup_anon_vma-before-setting-anon_vma.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Jann Horn <jannh(a)google.com> Subject: mm: lock VMA in dup_anon_vma() before setting ->anon_vma Date: Fri, 21 Jul 2023 05:46:43 +0200 When VMAs are merged, dup_anon_vma() is called with `dst` pointing to the VMA that is being expanded to cover the area previously occupied by another VMA. This currently happens while `dst` is not write-locked. This means that, in the `src->anon_vma && !dst->anon_vma` case, as soon as the assignment `dst->anon_vma = src->anon_vma` has happened, concurrent page faults can happen on `dst` under the per-VMA lock. This is already icky in itself, since such page faults can now install pages into `dst` that are attached to an `anon_vma` that is not yet tied back to the `anon_vma` with an `anon_vma_chain`. But if `anon_vma_clone()` fails due to an out-of-memory error, things get much worse: `anon_vma_clone()` then reverts `dst->anon_vma` back to NULL, and `dst` remains completely unconnected to the `anon_vma`, even though we can have pages in the area covered by `dst` that point to the `anon_vma`. This means the `anon_vma` of such pages can be freed while the pages are still mapped into userspace, which leads to UAF when a helper like folio_lock_anon_vma_read() tries to look up the anon_vma of such a page. This theoretically is a security bug, but I believe it is really hard to actually trigger as an unprivileged user because it requires that you can make an order-0 GFP_KERNEL allocation fail, and the page allocator tries pretty hard to prevent that. I think doing the vma_start_write() call inside dup_anon_vma() is the most straightforward fix for now. For a kernel-assisted reproducer, see the notes section of the patch mail. Link: https://lkml.kernel.org/r/20230721034643.616851-1-jannh@google.com Fixes: 5e31275cc997 ("mm: add per-VMA lock and helper functions to control it") Signed-off-by: Jann Horn <jannh(a)google.com> Reviewed-by: Suren Baghdasaryan <surenb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mmap.c | 1 + 1 file changed, 1 insertion(+) --- a/mm/mmap.c~mm-lock-vma-in-dup_anon_vma-before-setting-anon_vma +++ a/mm/mmap.c @@ -615,6 +615,7 @@ static inline int dup_anon_vma(struct vm * anon pages imported. */ if (src->anon_vma && !dst->anon_vma) { + vma_start_write(dst); dst->anon_vma = src->anon_vma; return anon_vma_clone(dst, src); } _ Patches currently in -mm which might be from jannh(a)google.com are mm-dont-drop-vma-locks-in-mm_drop_all_locks.patch

2 years, 3 months

1
0
0 0

[merged mm-hotfixes-stable] mm-fix-memory-ordering-for-mm_lock_seq-and-vm_lock_seq.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: fix memory ordering for mm_lock_seq and vm_lock_seq has been removed from the -mm tree. Its filename was mm-fix-memory-ordering-for-mm_lock_seq-and-vm_lock_seq.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Jann Horn <jannh(a)google.com> Subject: mm: fix memory ordering for mm_lock_seq and vm_lock_seq Date: Sat, 22 Jul 2023 00:51:07 +0200 mm->mm_lock_seq effectively functions as a read/write lock; therefore it must be used with acquire/release semantics. A specific example is the interaction between userfaultfd_register() and lock_vma_under_rcu(). userfaultfd_register() does the following from the point where it changes a VMA's flags to the point where concurrent readers are permitted again (in a simple scenario where only a single private VMA is accessed and no merging/splitting is involved): userfaultfd_register userfaultfd_set_vm_flags vm_flags_reset vma_start_write down_write(&vma->vm_lock->lock) vma->vm_lock_seq = mm_lock_seq [marks VMA as busy] up_write(&vma->vm_lock->lock) vm_flags_init [sets VM_UFFD_* in __vm_flags] vma->vm_userfaultfd_ctx.ctx = ctx mmap_write_unlock vma_end_write_all WRITE_ONCE(mm->mm_lock_seq, mm->mm_lock_seq + 1) [unlocks VMA] There are no memory barriers in between the __vm_flags update and the mm->mm_lock_seq update that unlocks the VMA, so the unlock can be reordered to above the `vm_flags_init()` call, which means from the perspective of a concurrent reader, a VMA can be marked as a userfaultfd VMA while it is not VMA-locked. That's bad, we definitely need a store-release for the unlock operation. The non-atomic write to vma->vm_lock_seq in vma_start_write() is mostly fine because all accesses to vma->vm_lock_seq that matter are always protected by the VMA lock. There is a racy read in vma_start_read() though that can tolerate false-positives, so we should be using WRITE_ONCE() to keep things tidy and data-race-free (including for KCSAN). On the other side, lock_vma_under_rcu() works as follows in the relevant region for locking and userfaultfd check: lock_vma_under_rcu vma_start_read vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq) [early bailout] down_read_trylock(&vma->vm_lock->lock) vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq) [main check] userfaultfd_armed checks vma->vm_flags & __VM_UFFD_FLAGS Here, the interesting aspect is how far down the mm->mm_lock_seq read can be reordered - if this read is reordered down below the vma->vm_flags access, this could cause lock_vma_under_rcu() to partly operate on information that was read while the VMA was supposed to be locked. To prevent this kind of downwards bleeding of the mm->mm_lock_seq read, we need to read it with a load-acquire. Some of the comment wording is based on suggestions by Suren. BACKPORT WARNING: One of the functions changed by this patch (which I've written against Linus' tree) is vma_try_start_write(), but this function no longer exists in mm/mm-everything. I don't know whether the merged version of this patch will be ordered before or after the patch that removes vma_try_start_write(). If you're backporting this patch to a tree with vma_try_start_write(), make sure this patch changes that function. Link: https://lkml.kernel.org/r/20230721225107.942336-1-jannh@google.com Fixes: 5e31275cc997 ("mm: add per-VMA lock and helper functions to control it") Signed-off-by: Jann Horn <jannh(a)google.com> Reviewed-by: Suren Baghdasaryan <surenb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/mm.h | 29 +++++++++++++++++++++++------ include/linux/mm_types.h | 28 ++++++++++++++++++++++++++++ include/linux/mmap_lock.h | 10 ++++++++-- 3 files changed, 59 insertions(+), 8 deletions(-) --- a/include/linux/mmap_lock.h~mm-fix-memory-ordering-for-mm_lock_seq-and-vm_lock_seq +++ a/include/linux/mmap_lock.h @@ -76,8 +76,14 @@ static inline void mmap_assert_write_loc static inline void vma_end_write_all(struct mm_struct *mm) { mmap_assert_write_locked(mm); - /* No races during update due to exclusive mmap_lock being held */ - WRITE_ONCE(mm->mm_lock_seq, mm->mm_lock_seq + 1); + /* + * Nobody can concurrently modify mm->mm_lock_seq due to exclusive + * mmap_lock being held. + * We need RELEASE semantics here to ensure that preceding stores into + * the VMA take effect before we unlock it with this store. + * Pairs with ACQUIRE semantics in vma_start_read(). + */ + smp_store_release(&mm->mm_lock_seq, mm->mm_lock_seq + 1); } #else static inline void vma_end_write_all(struct mm_struct *mm) {} --- a/include/linux/mm.h~mm-fix-memory-ordering-for-mm_lock_seq-and-vm_lock_seq +++ a/include/linux/mm.h @@ -641,8 +641,14 @@ static inline void vma_numab_state_free( */ static inline bool vma_start_read(struct vm_area_struct *vma) { - /* Check before locking. A race might cause false locked result. */ - if (vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq)) + /* + * Check before locking. A race might cause false locked result. + * We can use READ_ONCE() for the mm_lock_seq here, and don't need + * ACQUIRE semantics, because this is just a lockless check whose result + * we don't rely on for anything - the mm_lock_seq read against which we + * need ordering is below. + */ + if (READ_ONCE(vma->vm_lock_seq) == READ_ONCE(vma->vm_mm->mm_lock_seq)) return false; if (unlikely(down_read_trylock(&vma->vm_lock->lock) == 0)) @@ -653,8 +659,13 @@ static inline bool vma_start_read(struct * False unlocked result is impossible because we modify and check * vma->vm_lock_seq under vma->vm_lock protection and mm->mm_lock_seq * modification invalidates all existing locks. + * + * We must use ACQUIRE semantics for the mm_lock_seq so that if we are + * racing with vma_end_write_all(), we only start reading from the VMA + * after it has been unlocked. + * This pairs with RELEASE semantics in vma_end_write_all(). */ - if (unlikely(vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))) { + if (unlikely(vma->vm_lock_seq == smp_load_acquire(&vma->vm_mm->mm_lock_seq))) { up_read(&vma->vm_lock->lock); return false; } @@ -676,7 +687,7 @@ static bool __is_vma_write_locked(struct * current task is holding mmap_write_lock, both vma->vm_lock_seq and * mm->mm_lock_seq can't be concurrently modified. */ - *mm_lock_seq = READ_ONCE(vma->vm_mm->mm_lock_seq); + *mm_lock_seq = vma->vm_mm->mm_lock_seq; return (vma->vm_lock_seq == *mm_lock_seq); } @@ -688,7 +699,13 @@ static inline void vma_start_write(struc return; down_write(&vma->vm_lock->lock); - vma->vm_lock_seq = mm_lock_seq; + /* + * We should use WRITE_ONCE() here because we can have concurrent reads + * from the early lockless pessimistic check in vma_start_read(). + * We don't really care about the correctness of that early check, but + * we should use WRITE_ONCE() for cleanliness and to keep KCSAN happy. + */ + WRITE_ONCE(vma->vm_lock_seq, mm_lock_seq); up_write(&vma->vm_lock->lock); } @@ -702,7 +719,7 @@ static inline bool vma_try_start_write(s if (!down_write_trylock(&vma->vm_lock->lock)) return false; - vma->vm_lock_seq = mm_lock_seq; + WRITE_ONCE(vma->vm_lock_seq, mm_lock_seq); up_write(&vma->vm_lock->lock); return true; } --- a/include/linux/mm_types.h~mm-fix-memory-ordering-for-mm_lock_seq-and-vm_lock_seq +++ a/include/linux/mm_types.h @@ -514,6 +514,20 @@ struct vm_area_struct { }; #ifdef CONFIG_PER_VMA_LOCK + /* + * Can only be written (using WRITE_ONCE()) while holding both: + * - mmap_lock (in write mode) + * - vm_lock->lock (in write mode) + * Can be read reliably while holding one of: + * - mmap_lock (in read or write mode) + * - vm_lock->lock (in read or write mode) + * Can be read unreliably (using READ_ONCE()) for pessimistic bailout + * while holding nothing (except RCU to keep the VMA struct allocated). + * + * This sequence counter is explicitly allowed to overflow; sequence + * counter reuse can only lead to occasional unnecessary use of the + * slowpath. + */ int vm_lock_seq; struct vma_lock *vm_lock; @@ -679,6 +693,20 @@ struct mm_struct { * by mmlist_lock */ #ifdef CONFIG_PER_VMA_LOCK + /* + * This field has lock-like semantics, meaning it is sometimes + * accessed with ACQUIRE/RELEASE semantics. + * Roughly speaking, incrementing the sequence number is + * equivalent to releasing locks on VMAs; reading the sequence + * number can be part of taking a read lock on a VMA. + * + * Can be modified under write mmap_lock using RELEASE + * semantics. + * Can be read with no other protection when holding write + * mmap_lock. + * Can be read with ACQUIRE semantics if not holding write + * mmap_lock. + */ int mm_lock_seq; #endif _ Patches currently in -mm which might be from jannh(a)google.com are mm-dont-drop-vma-locks-in-mm_drop_all_locks.patch

2 years, 3 months

1
0
0 0

[merged mm-hotfixes-stable] revert-um-use-swap-to-make-code-cleaner.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: Revert "um: Use swap() to make code cleaner" has been removed from the -mm tree. Its filename was revert-um-use-swap-to-make-code-cleaner.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Subject: Revert "um: Use swap() to make code cleaner" Date: Mon, 24 Jul 2023 17:31:31 +0300 This reverts commit 9b0da3f22307af693be80f5d3a89dc4c7f360a85. The sigio.c is clearly user space code which is handled by arch/um/scripts/Makefile.rules (see USER_OBJS rule). The above mentioned commit simply broke this agreement, we may not use Linux kernel internal headers in them without thorough thinking. Hence, revert the wrong commit. Link: https://lkml.kernel.org/r/20230724143131.30090-1-andriy.shevchenko@linux.in… Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202307212304.cH79zJp1-lkp@intel.com/ Cc: Anton Ivanov <anton.ivanov(a)cambridgegreys.com> Cc: Herve Codina <herve.codina(a)bootlin.com> Cc: Jason A. Donenfeld <Jason(a)zx2c4.com> Cc: Johannes Berg <johannes(a)sipsolutions.net> Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Cc: Richard Weinberger <richard(a)nod.at> Cc: Yang Guang <yang.guang5(a)zte.com.cn> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/um/os-Linux/sigio.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/arch/um/os-Linux/sigio.c~revert-um-use-swap-to-make-code-cleaner +++ a/arch/um/os-Linux/sigio.c @@ -3,7 +3,6 @@ * Copyright (C) 2002 - 2008 Jeff Dike (jdike(a){addtoit,linux.intel}.com) */ -#include <linux/minmax.h> #include <unistd.h> #include <errno.h> #include <fcntl.h> @@ -51,7 +50,7 @@ static struct pollfds all_sigio_fds; static int write_sigio_thread(void *unused) { - struct pollfds *fds; + struct pollfds *fds, tmp; struct pollfd *p; int i, n, respond_fd; char c; @@ -78,7 +77,9 @@ static int write_sigio_thread(void *unus "write_sigio_thread : " "read on socket failed, " "err = %d\n", errno); - swap(current_poll, next_poll); + tmp = current_poll; + current_poll = next_poll; + next_poll = tmp; respond_fd = sigio_private[1]; } else { _ Patches currently in -mm which might be from andriy.shevchenko(a)linux.intel.com are kernelh-split-out-count_args-and-concatenate-to-argsh.patch x86-asm-replace-custom-count_args-concatenate-implementations.patch arm64-smccc-replace-custom-count_args-concatenate-implementations.patch genetlink-replace-custom-concatenate-implementation.patch

2 years, 3 months

1
0
0 0

[PATCH] firmware: Fix an NULL vs IS_ERR() bug in probe

by Dinh Nguyen

From: Wang Ming <machel(a)vivo.com> The devm_memremap() function returns error pointers. It never returns NULL. Fix the check. Fixes: 7ca5ce896524 ("firmware: add Intel Stratix10 service layer driver") Cc: stable(a)vger.kernel.org Signed-off-by: Wang Ming <machel(a)vivo.com> Signed-off-by: Dinh Nguyen <dinguyen(a)kernel.org> --- drivers/firmware/stratix10-svc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/stratix10-svc.c b/drivers/firmware/stratix10-svc.c index 260695a8a9e6..c693da60e9a9 100644 --- a/drivers/firmware/stratix10-svc.c +++ b/drivers/firmware/stratix10-svc.c @@ -774,7 +774,7 @@ svc_create_memory_pool(struct platform_device *pdev, paddr = begin; size = end - begin; va = devm_memremap(dev, paddr, size, MEMREMAP_WC); - if (!va) { + if (IS_ERR(va)) { dev_err(dev, "fail to remap shared memory\n"); return ERR_PTR(-EINVAL); } -- 2.25.1

2 years, 3 months

1
0
0 0

[PATCH v1] usb: typec: bus: verify partner exists in typec_altmode_attention

by RD Babiera

Some usb hubs will negotiate DisplayPort Alt mode with the device but will then negotiate a data role swap after entering the alt mode. The data role swap causes the device to unregister all alt modes, however the usb hub will still send Attention messages even after failing to reregister the Alt Mode. type_altmode_attention currently does not verify whether or not a device's altmode partner exists, which results in a NULL pointer error when dereferencing the typec_altmode and typec_altmode_ops belonging to the altmode partner. This patch verifies the presence of a device's altmode partner before sending the Attention message to the Alt Mode driver. It also changes the return type from void to int so errors can be logged at the tcpm level. Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes") Cc: stable(a)vger.kernel.org Signed-off-by: RD Babiera <rdbabiera(a)google.com> --- drivers/usb/typec/bus.c | 12 ++++++++++-- drivers/usb/typec/tcpm/tcpm.c | 5 ++++- include/linux/usb/typec_altmode.h | 2 +- 3 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/usb/typec/bus.c b/drivers/usb/typec/bus.c index fe5b9a2e61f5..2f1823e16b3b 100644 --- a/drivers/usb/typec/bus.c +++ b/drivers/usb/typec/bus.c @@ -183,12 +183,20 @@ EXPORT_SYMBOL_GPL(typec_altmode_exit); * * Notifies the partner of @adev about Attention command. */ -void typec_altmode_attention(struct typec_altmode *adev, u32 vdo) +int typec_altmode_attention(struct typec_altmode *adev, u32 vdo) { - struct typec_altmode *pdev = &to_altmode(adev)->partner->adev; + struct altmode *partner = to_altmode(adev)->partner; + struct typec_altmode *pdev = &partner->adev; + + if (!partner || !pdev) + return -ENODEV; if (pdev->ops && pdev->ops->attention) pdev->ops->attention(pdev, vdo); + else + return -EOPNOTSUPP; + + return 0; } EXPORT_SYMBOL_GPL(typec_altmode_attention); diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 829d75ebab42..be37a662e54d 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -1791,6 +1791,7 @@ static void tcpm_handle_vdm_request(struct tcpm_port *port, u32 p[PD_MAX_PAYLOAD]; u32 response[8] = { }; int i, rlen = 0; + int ret; for (i = 0; i < cnt; i++) p[i] = le32_to_cpu(payload[i]); @@ -1877,7 +1878,9 @@ static void tcpm_handle_vdm_request(struct tcpm_port *port, } break; case ADEV_ATTENTION: - typec_altmode_attention(adev, p[1]); + ret = typec_altmode_attention(adev, p[1]); + if (ret) + tcpm_log(port, "altmode_attention failed ret:%d", ret); break; } } diff --git a/include/linux/usb/typec_altmode.h b/include/linux/usb/typec_altmode.h index 350d49012659..28aeef8f9e7b 100644 --- a/include/linux/usb/typec_altmode.h +++ b/include/linux/usb/typec_altmode.h @@ -67,7 +67,7 @@ struct typec_altmode_ops { int typec_altmode_enter(struct typec_altmode *altmode, u32 *vdo); int typec_altmode_exit(struct typec_altmode *altmode); -void typec_altmode_attention(struct typec_altmode *altmode, u32 vdo); +int typec_altmode_attention(struct typec_altmode *altmode, u32 vdo); int typec_altmode_vdm(struct typec_altmode *altmode, const u32 header, const u32 *vdo, int count); int typec_altmode_notify(struct typec_altmode *altmode, unsigned long conf, base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c -- 2.41.0.487.g6d72f3e995-goog

2 years, 3 months

2
2
0 0

[PATCH 4/4] vdpa: Enable strict validation for netlinks ops

by Dragos Tatulea

The previous patches added the missing nla policies that were required for validation to work. Now strict validation on netlink ops can be enabled. This patch does it. Signed-off-by: Dragos Tatulea <dtatulea(a)nvidia.com> Cc: stable(a)vger.kernel.org --- drivers/vdpa/vdpa.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c index f2f654fd84e5..a7612e0783b3 100644 --- a/drivers/vdpa/vdpa.c +++ b/drivers/vdpa/vdpa.c @@ -1257,37 +1257,31 @@ static const struct nla_policy vdpa_nl_policy[VDPA_ATTR_MAX + 1] = { static const struct genl_ops vdpa_nl_ops[] = { { .cmd = VDPA_CMD_MGMTDEV_GET, - .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP, .doit = vdpa_nl_cmd_mgmtdev_get_doit, .dumpit = vdpa_nl_cmd_mgmtdev_get_dumpit, }, { .cmd = VDPA_CMD_DEV_NEW, - .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP, .doit = vdpa_nl_cmd_dev_add_set_doit, .flags = GENL_ADMIN_PERM, }, { .cmd = VDPA_CMD_DEV_DEL, - .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP, .doit = vdpa_nl_cmd_dev_del_set_doit, .flags = GENL_ADMIN_PERM, }, { .cmd = VDPA_CMD_DEV_GET, - .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP, .doit = vdpa_nl_cmd_dev_get_doit, .dumpit = vdpa_nl_cmd_dev_get_dumpit, }, { .cmd = VDPA_CMD_DEV_CONFIG_GET, - .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP, .doit = vdpa_nl_cmd_dev_config_get_doit, .dumpit = vdpa_nl_cmd_dev_config_get_dumpit, }, { .cmd = VDPA_CMD_DEV_VSTATS_GET, - .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP, .doit = vdpa_nl_cmd_dev_stats_get_doit, .flags = GENL_ADMIN_PERM, }, -- 2.41.0

2 years, 3 months

1
0
0 0

[PATCH 3/4] vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check

by Dragos Tatulea

From: Lin Ma <linma(a)zju.edu.cn> The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops. That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missing nla_policy for vdpa max vqp attr to avoid such bugs. Fixes: ad69dd0bf26b ("vdpa: Introduce query of device config layout") Signed-off-by: Lin Ma <linma(a)zju.edu.cn> Cc: stable(a)vger.kernel.org --- drivers/vdpa/vdpa.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c index 75f1df2b9d2a..f2f654fd84e5 100644 --- a/drivers/vdpa/vdpa.c +++ b/drivers/vdpa/vdpa.c @@ -1247,6 +1247,7 @@ static const struct nla_policy vdpa_nl_policy[VDPA_ATTR_MAX + 1] = { [VDPA_ATTR_MGMTDEV_DEV_NAME] = { .type = NLA_STRING }, [VDPA_ATTR_DEV_NAME] = { .type = NLA_STRING }, [VDPA_ATTR_DEV_NET_CFG_MACADDR] = NLA_POLICY_ETH_ADDR, + [VDPA_ATTR_DEV_NET_CFG_MAX_VQP] = { .type = NLA_U16 }, /* virtio spec 1.1 section 5.1.4.1 for valid MTU range */ [VDPA_ATTR_DEV_NET_CFG_MTU] = NLA_POLICY_MIN(NLA_U16, 68), [VDPA_ATTR_DEV_QUEUE_INDEX] = { .type = NLA_U32 }, -- 2.41.0

2 years, 3 months

1
0
0 0

[PATCH 1/4] vdpa: Add features attr to vdpa_nl_policy for nlattr length check

by Dragos Tatulea

From: Lin Ma <linma(a)zju.edu.cn> The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops. That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missing nla_policy for vdpa features attr to avoid such bugs. Fixes: 90fea5a800c3 ("vdpa: device feature provisioning") Signed-off-by: Lin Ma <linma(a)zju.edu.cn> Cc: stable(a)vger.kernel.org --- drivers/vdpa/vdpa.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c index 965e32529eb8..3ad355a2208a 100644 --- a/drivers/vdpa/vdpa.c +++ b/drivers/vdpa/vdpa.c @@ -1249,6 +1249,7 @@ static const struct nla_policy vdpa_nl_policy[VDPA_ATTR_MAX + 1] = { [VDPA_ATTR_DEV_NET_CFG_MACADDR] = NLA_POLICY_ETH_ADDR, /* virtio spec 1.1 section 5.1.4.1 for valid MTU range */ [VDPA_ATTR_DEV_NET_CFG_MTU] = NLA_POLICY_MIN(NLA_U16, 68), + [VDPA_ATTR_DEV_FEATURES] = { .type = NLA_U64 }, }; static const struct genl_ops vdpa_nl_ops[] = { -- 2.41.0

2 years, 3 months

1
0
0 0

[PATCH 4.14] net/sched: cls_fw: Fix improper refcount update leads to use-after-free

by SeongJae Park

From: M A Ramdhan <ramdhan(a)starlabs.sg> [ Upstream commit 0323bce598eea038714f941ce2b22541c46d488f ] In the event of a failure in tcf_change_indev(), fw_set_parms() will immediately return an error after incrementing or decrementing reference counter in tcf_bind_filter(). If attacker can control reference counter to zero and make reference freed, leading to use after free. In order to prevent this, move the point of possible failure above the point where the TC_FW_CLASSID is handled. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: M A Ramdhan <ramdhan(a)starlabs.sg> Signed-off-by: M A Ramdhan <ramdhan(a)starlabs.sg> Acked-by: Jamal Hadi Salim <jhs(a)mojatatu.com> Reviewed-by: Pedro Tammela <pctammela(a)mojatatu.com> Message-ID: <20230705161530.52003-1-ramdhan(a)starlabs.sg> Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: SeongJae Park <sj(a)kernel.org> --- net/sched/cls_fw.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/net/sched/cls_fw.c b/net/sched/cls_fw.c index 7f45e5ab8afcd..e63f9c2e37e50 100644 --- a/net/sched/cls_fw.c +++ b/net/sched/cls_fw.c @@ -225,11 +225,6 @@ static int fw_set_parms(struct net *net, struct tcf_proto *tp, if (err < 0) return err; - if (tb[TCA_FW_CLASSID]) { - f->res.classid = nla_get_u32(tb[TCA_FW_CLASSID]); - tcf_bind_filter(tp, &f->res, base); - } - #ifdef CONFIG_NET_CLS_IND if (tb[TCA_FW_INDEV]) { int ret; @@ -248,6 +243,11 @@ static int fw_set_parms(struct net *net, struct tcf_proto *tp, } else if (head->mask != 0xFFFFFFFF) return err; + if (tb[TCA_FW_CLASSID]) { + f->res.classid = nla_get_u32(tb[TCA_FW_CLASSID]); + tcf_bind_filter(tp, &f->res, base); + } + return 0; } -- 2.40.1

2 years, 3 months

1
0
0 0

+ mm-memory-failure-avoid-false-hwpoison-page-mapped-error-info.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: memory-failure: avoid false hwpoison page mapped error info has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-memory-failure-avoid-false-hwpoison-page-mapped-error-info.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Miaohe Lin <linmiaohe(a)huawei.com> Subject: mm: memory-failure: avoid false hwpoison page mapped error info Date: Thu, 27 Jul 2023 19:56:42 +0800 folio->_mapcount is overloaded in SLAB, so folio_mapped() has to be done after folio_test_slab() is checked. Otherwise slab folio might be treated as a mapped folio leading to false 'Someone maps the hwpoison page' error info. Link: https://lkml.kernel.org/r/20230727115643.639741-4-linmiaohe@huawei.com Fixes: 230ac719c500 ("mm/hwpoison: don't try to unpoison containment-failed pages") Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com> Reviewed-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Acked-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory-failure.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/mm/memory-failure.c~mm-memory-failure-avoid-false-hwpoison-page-mapped-error-info +++ a/mm/memory-failure.c @@ -2499,6 +2499,13 @@ int unpoison_memory(unsigned long pfn) goto unlock_mutex; } + if (folio_test_slab(folio) || PageTable(&folio->page) || folio_test_reserved(folio)) + goto unlock_mutex; + + /* + * Note that folio->_mapcount is overloaded in SLAB, so the simple test + * in folio_mapped() has to be done after folio_test_slab() is checked. + */ if (folio_mapped(folio)) { unpoison_pr_info("Unpoison: Someone maps the hwpoison page %#lx\n", pfn, &unpoison_rs); @@ -2511,9 +2518,6 @@ int unpoison_memory(unsigned long pfn) goto unlock_mutex; } - if (folio_test_slab(folio) || PageTable(&folio->page) || folio_test_reserved(folio)) - goto unlock_mutex; - ghp = get_hwpoison_page(p, MF_UNPOISON); if (!ghp) { if (PageHuge(p)) { _ Patches currently in -mm which might be from linmiaohe(a)huawei.com are mm-swapfile-fix-wrong-swap-entry-type-for-hwpoisoned-swapcache-page.patch mm-memory-failure-fix-potential-unexpected-return-value-from-unpoison_memory.patch mm-memory-failure-avoid-false-hwpoison-page-mapped-error-info.patch mm-memory-failure-add-pageoffline-check.patch mm-mm_initc-update-obsolete-comment-in-get_pfn_range_for_nid.patch mm-memory-failure-fix-unexpected-return-value-in-soft_offline_page.patch mm-memory-failure-fix-potential-page-refcnt-leak-in-memory_failure.patch mm-memory-failure-remove-unneeded-page-state-check-in-shake_page.patch memory-tier-use-helper-function-destroy_memory_type.patch mm-memory-failure-remove-unneeded-inline-annotation.patch mm-mm_initc-remove-obsolete-macro-hash_small.patch mm-page_alloc-avoid-false-page-outside-zone-error-info.patch memory-tier-rename-destroy_memory_type-to-put_memory_type.patch mm-remove-obsolete-comment-above-struct-per_cpu_pages.patch mm-memcg-minor-cleanup-for-mem_cgroup_id_max.patch mm-memory-failure-remove-unneeded-pagehuge-check.patch mm-memory-failure-ensure-moving-hwpoison-flag-to-the-raw-error-pages.patch mm-memory-failure-dont-account-hwpoison_filter-filtered-pages.patch mm-memory-failure-use-local-variable-huge-to-check-hugetlb-page.patch mm-memory-failure-remove-unneeded-header-files.patch mm-memory-failure-minor-cleanup-for-comments-and-codestyle.patch mm-memory-failure-fetch-compound-head-after-extra-page-refcnt-is-held.patch mm-memory-failure-fix-race-window-when-trying-to-get-hugetlb-folio.patch mm-huge_memory-use-rmap_none-when-calling-page_add_anon_rmap.patch mm-memcg-fix-obsolete-comment-above-mem_cgroup_max_reclaim_loops.patch mm-memcg-minor-cleanup-for-mc_handle_present_pte.patch memory-tier-use-helper-macro-__attr_rw.patch mm-fix-obsolete-function-name-above-debug_pagealloc_enabled_static.patch mm-mprotect-fix-obsolete-function-name-in-change_pte_range.patch mm-memcg-fix-obsolete-function-name-in-mem_cgroup_protection.patch

2 years, 3 months

1
0
0 0

+ mm-memory-failure-fix-potential-unexpected-return-value-from-unpoison_memory.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: memory-failure: fix potential unexpected return value from unpoison_memory() has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-memory-failure-fix-potential-unexpected-return-value-from-unpoison_memory.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Miaohe Lin <linmiaohe(a)huawei.com> Subject: mm: memory-failure: fix potential unexpected return value from unpoison_memory() Date: Thu, 27 Jul 2023 19:56:41 +0800 If unpoison_memory() fails to clear page hwpoisoned flag, return value ret is expected to be -EBUSY. But when get_hwpoison_page() returns 1 and fails to clear page hwpoisoned flag due to races, return value will be unexpected 1 leading to users being confused. And there's a code smell that the variable "ret" is used not only to save the return value of unpoison_memory(), but also the return value from get_hwpoison_page(). Make a further cleanup by using another auto-variable solely to save the return value of get_hwpoison_page() as suggested by Naoya. Link: https://lkml.kernel.org/r/20230727115643.639741-3-linmiaohe@huawei.com Fixes: bf181c582588 ("mm/hwpoison: fix unpoison_memory()") Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Naoya Horiguchi <naoya.horiguchi(a)nec.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory-failure.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) --- a/mm/memory-failure.c~mm-memory-failure-fix-potential-unexpected-return-value-from-unpoison_memory +++ a/mm/memory-failure.c @@ -2466,7 +2466,7 @@ int unpoison_memory(unsigned long pfn) { struct folio *folio; struct page *p; - int ret = -EBUSY; + int ret = -EBUSY, ghp; unsigned long count = 1; bool huge = false; static DEFINE_RATELIMIT_STATE(unpoison_rs, DEFAULT_RATELIMIT_INTERVAL, @@ -2514,29 +2514,28 @@ int unpoison_memory(unsigned long pfn) if (folio_test_slab(folio) || PageTable(&folio->page) || folio_test_reserved(folio)) goto unlock_mutex; - ret = get_hwpoison_page(p, MF_UNPOISON); - if (!ret) { + ghp = get_hwpoison_page(p, MF_UNPOISON); + if (!ghp) { if (PageHuge(p)) { huge = true; count = folio_free_raw_hwp(folio, false); - if (count == 0) { - ret = -EBUSY; + if (count == 0) goto unlock_mutex; - } } ret = folio_test_clear_hwpoison(folio) ? 0 : -EBUSY; - } else if (ret < 0) { - if (ret == -EHWPOISON) { + } else if (ghp < 0) { + if (ghp == -EHWPOISON) { ret = put_page_back_buddy(p) ? 0 : -EBUSY; - } else + } else { + ret = ghp; unpoison_pr_info("Unpoison: failed to grab page %#lx\n", pfn, &unpoison_rs); + } } else { if (PageHuge(p)) { huge = true; count = folio_free_raw_hwp(folio, false); if (count == 0) { - ret = -EBUSY; folio_put(folio); goto unlock_mutex; } _ Patches currently in -mm which might be from linmiaohe(a)huawei.com are mm-swapfile-fix-wrong-swap-entry-type-for-hwpoisoned-swapcache-page.patch mm-memory-failure-fix-potential-unexpected-return-value-from-unpoison_memory.patch mm-memory-failure-avoid-false-hwpoison-page-mapped-error-info.patch mm-memory-failure-add-pageoffline-check.patch mm-mm_initc-update-obsolete-comment-in-get_pfn_range_for_nid.patch mm-memory-failure-fix-unexpected-return-value-in-soft_offline_page.patch mm-memory-failure-fix-potential-page-refcnt-leak-in-memory_failure.patch mm-memory-failure-remove-unneeded-page-state-check-in-shake_page.patch memory-tier-use-helper-function-destroy_memory_type.patch mm-memory-failure-remove-unneeded-inline-annotation.patch mm-mm_initc-remove-obsolete-macro-hash_small.patch mm-page_alloc-avoid-false-page-outside-zone-error-info.patch memory-tier-rename-destroy_memory_type-to-put_memory_type.patch mm-remove-obsolete-comment-above-struct-per_cpu_pages.patch mm-memcg-minor-cleanup-for-mem_cgroup_id_max.patch mm-memory-failure-remove-unneeded-pagehuge-check.patch mm-memory-failure-ensure-moving-hwpoison-flag-to-the-raw-error-pages.patch mm-memory-failure-dont-account-hwpoison_filter-filtered-pages.patch mm-memory-failure-use-local-variable-huge-to-check-hugetlb-page.patch mm-memory-failure-remove-unneeded-header-files.patch mm-memory-failure-minor-cleanup-for-comments-and-codestyle.patch mm-memory-failure-fetch-compound-head-after-extra-page-refcnt-is-held.patch mm-memory-failure-fix-race-window-when-trying-to-get-hugetlb-folio.patch mm-huge_memory-use-rmap_none-when-calling-page_add_anon_rmap.patch mm-memcg-fix-obsolete-comment-above-mem_cgroup_max_reclaim_loops.patch mm-memcg-minor-cleanup-for-mc_handle_present_pte.patch memory-tier-use-helper-macro-__attr_rw.patch mm-fix-obsolete-function-name-above-debug_pagealloc_enabled_static.patch mm-mprotect-fix-obsolete-function-name-in-change_pte_range.patch mm-memcg-fix-obsolete-function-name-in-mem_cgroup_protection.patch

2 years, 3 months

1
0
0 0

+ mm-swapfile-fix-wrong-swap-entry-type-for-hwpoisoned-swapcache-page.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/swapfile: fix wrong swap entry type for hwpoisoned swapcache page has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-swapfile-fix-wrong-swap-entry-type-for-hwpoisoned-swapcache-page.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Miaohe Lin <linmiaohe(a)huawei.com> Subject: mm/swapfile: fix wrong swap entry type for hwpoisoned swapcache page Date: Thu, 27 Jul 2023 19:56:40 +0800 Patch series "A few fixup patches for mm", v2. This series contains a few fixup patches to fix potential unexpected return value, fix wrong swap entry type for hwpoisoned swapcache page and so on. More details can be found in the respective changelogs. This patch (of 4): Hwpoisoned dirty swap cache page is kept in the swap cache and there's simple interception code in do_swap_page() to catch it. But when trying to swapoff, unuse_pte() will wrongly install a general sense of "future accesses are invalid" swap entry for hwpoisoned swap cache page due to unaware of such type of page. The user will receive SIGBUS signal without expected BUS_MCEERR_AR payload. BTW, typo 'hwposioned' is fixed. Link: https://lkml.kernel.org/r/20230727115643.639741-1-linmiaohe@huawei.com Link: https://lkml.kernel.org/r/20230727115643.639741-2-linmiaohe@huawei.com Fixes: 6b970599e807 ("mm: hwpoison: support recovery from ksm_might_need_to_copy()") Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Naoya Horiguchi <naoya.horiguchi(a)nec.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/ksm.c | 2 ++ mm/swapfile.c | 8 ++++---- 2 files changed, 6 insertions(+), 4 deletions(-) --- a/mm/ksm.c~mm-swapfile-fix-wrong-swap-entry-type-for-hwpoisoned-swapcache-page +++ a/mm/ksm.c @@ -2784,6 +2784,8 @@ struct page *ksm_might_need_to_copy(stru anon_vma->root == vma->anon_vma->root) { return page; /* still no need to copy it */ } + if (PageHWPoison(page)) + return ERR_PTR(-EHWPOISON); if (!PageUptodate(page)) return page; /* let do_swap_page report the error */ --- a/mm/swapfile.c~mm-swapfile-fix-wrong-swap-entry-type-for-hwpoisoned-swapcache-page +++ a/mm/swapfile.c @@ -1746,7 +1746,7 @@ static int unuse_pte(struct vm_area_stru struct page *swapcache; spinlock_t *ptl; pte_t *pte, new_pte, old_pte; - bool hwposioned = false; + bool hwpoisoned = PageHWPoison(page); int ret = 1; swapcache = page; @@ -1754,7 +1754,7 @@ static int unuse_pte(struct vm_area_stru if (unlikely(!page)) return -ENOMEM; else if (unlikely(PTR_ERR(page) == -EHWPOISON)) - hwposioned = true; + hwpoisoned = true; pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl); if (unlikely(!pte || !pte_same_as_swp(ptep_get(pte), @@ -1765,11 +1765,11 @@ static int unuse_pte(struct vm_area_stru old_pte = ptep_get(pte); - if (unlikely(hwposioned || !PageUptodate(page))) { + if (unlikely(hwpoisoned || !PageUptodate(page))) { swp_entry_t swp_entry; dec_mm_counter(vma->vm_mm, MM_SWAPENTS); - if (hwposioned) { + if (hwpoisoned) { swp_entry = make_hwpoison_entry(swapcache); page = swapcache; } else { _ Patches currently in -mm which might be from linmiaohe(a)huawei.com are mm-swapfile-fix-wrong-swap-entry-type-for-hwpoisoned-swapcache-page.patch mm-memory-failure-fix-potential-unexpected-return-value-from-unpoison_memory.patch mm-memory-failure-avoid-false-hwpoison-page-mapped-error-info.patch mm-memory-failure-add-pageoffline-check.patch mm-mm_initc-update-obsolete-comment-in-get_pfn_range_for_nid.patch mm-memory-failure-fix-unexpected-return-value-in-soft_offline_page.patch mm-memory-failure-fix-potential-page-refcnt-leak-in-memory_failure.patch mm-memory-failure-remove-unneeded-page-state-check-in-shake_page.patch memory-tier-use-helper-function-destroy_memory_type.patch mm-memory-failure-remove-unneeded-inline-annotation.patch mm-mm_initc-remove-obsolete-macro-hash_small.patch mm-page_alloc-avoid-false-page-outside-zone-error-info.patch memory-tier-rename-destroy_memory_type-to-put_memory_type.patch mm-remove-obsolete-comment-above-struct-per_cpu_pages.patch mm-memcg-minor-cleanup-for-mem_cgroup_id_max.patch mm-memory-failure-remove-unneeded-pagehuge-check.patch mm-memory-failure-ensure-moving-hwpoison-flag-to-the-raw-error-pages.patch mm-memory-failure-dont-account-hwpoison_filter-filtered-pages.patch mm-memory-failure-use-local-variable-huge-to-check-hugetlb-page.patch mm-memory-failure-remove-unneeded-header-files.patch mm-memory-failure-minor-cleanup-for-comments-and-codestyle.patch mm-memory-failure-fetch-compound-head-after-extra-page-refcnt-is-held.patch mm-memory-failure-fix-race-window-when-trying-to-get-hugetlb-folio.patch mm-huge_memory-use-rmap_none-when-calling-page_add_anon_rmap.patch mm-memcg-fix-obsolete-comment-above-mem_cgroup_max_reclaim_loops.patch mm-memcg-minor-cleanup-for-mc_handle_present_pte.patch memory-tier-use-helper-macro-__attr_rw.patch mm-fix-obsolete-function-name-above-debug_pagealloc_enabled_static.patch mm-mprotect-fix-obsolete-function-name-in-change_pte_range.patch mm-memcg-fix-obsolete-function-name-in-mem_cgroup_protection.patch

2 years, 3 months

1
0
0 0

+ radix-tree-test-suite-fix-incorrect-allocation-size-for-pthreads.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: radix tree test suite: fix incorrect allocation size for pthreads has been added to the -mm mm-hotfixes-unstable branch. Its filename is radix-tree-test-suite-fix-incorrect-allocation-size-for-pthreads.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Colin Ian King <colin.i.king(a)gmail.com> Subject: radix tree test suite: fix incorrect allocation size for pthreads Date: Thu, 27 Jul 2023 17:09:30 +0100 Currently the pthread allocation for each array item is based on the size of a pthread_t pointer and should be the size of the pthread_t structure, so the allocation is under-allocating the correct size. Fix this by using the size of each element in the pthreads array. Static analysis cppcheck reported: tools/testing/radix-tree/regression1.c:180:2: warning: Size of pointer 'threads' used instead of size of its data. [pointerSize] Link: https://lkml.kernel.org/r/20230727160930.632674-1-colin.i.king@gmail.com Fixes: 1366c37ed84b ("radix tree test harness") Signed-off-by: Colin Ian King <colin.i.king(a)gmail.com> Cc: Konstantin Khlebnikov <koct9i(a)gmail.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/radix-tree/regression1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/radix-tree/regression1.c~radix-tree-test-suite-fix-incorrect-allocation-size-for-pthreads +++ a/tools/testing/radix-tree/regression1.c @@ -177,7 +177,7 @@ void regression1_test(void) nr_threads = 2; pthread_barrier_init(&worker_barrier, NULL, nr_threads); - threads = malloc(nr_threads * sizeof(pthread_t *)); + threads = malloc(nr_threads * sizeof(*threads)); for (i = 0; i < nr_threads; i++) { arg = i; _ Patches currently in -mm which might be from colin.i.king(a)gmail.com are radix-tree-test-suite-fix-incorrect-allocation-size-for-pthreads.patch fs-hfsplus-make-extend-error-rate-limited.patch

2 years, 3 months

1
0
0 0

[PATCH v2 0/3] arm64/fpsimd: Fix use after free in SME when changing SVE VL

by Mark Brown

This series fixes an issue which David Spickett found where if we change the SVE VL while SME is in use we can end up attempting to save state to an unallocated buffer and adds testing coverage for that plus a bit more coverage of VL changes, just for paranioa. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Changes in v2: - Always reallocate the SVE state. - Rebase onto v6.5-rc2. - Link to v1: https://lore.kernel.org/r/20230713-arm64-fix-sve-sme-vl-change-v1-0-129dd86… --- Mark Brown (3): arm64/fpsimd: Ensure SME storage is allocated after SVE VL changes kselftest/arm64: Add a test case for SVE VL changes with SME active kselftest/arm64: Validate that changing one VL type does not affect another arch/arm64/kernel/fpsimd.c | 33 +++++-- tools/testing/selftests/arm64/fp/vec-syscfg.c | 127 +++++++++++++++++++++++++- 2 files changed, 148 insertions(+), 12 deletions(-) --- base-commit: 06785562d1b99ff6dc1cd0af54be5e3ff999dc02 change-id: 20230713-arm64-fix-sve-sme-vl-change-60eb1fa6a707 Best regards, -- Mark Brown <broonie(a)kernel.org>

2 years, 3 months

2
3
0 0

FAILED: patch "[PATCH] selftests: mptcp: sockopt: use 'iptables-legacy' if available" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x a5a5990c099dd354e05e89ee77cd2dbf6655d4a1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023072146-grit-winking-6e88@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: a5a5990c099d ("selftests: mptcp: sockopt: use 'iptables-legacy' if available") 5f17f8e315ad ("selftests: mptcp: declare var as local") de2392028a19 ("selftests: mptcp: clearly declare global ns vars") 787eb1e4df93 ("selftests: mptcp: uniform 'rndh' variable") b71dd705179c ("selftests: mptcp: removed defined but unused vars") b4e0df4cafe1 ("selftests: mptcp: run mptcp_inq from a clean netns") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a5a5990c099dd354e05e89ee77cd2dbf6655d4a1 Mon Sep 17 00:00:00 2001 From: Matthieu Baerts <matthieu.baerts(a)tessares.net> Date: Tue, 4 Jul 2023 22:44:36 +0200 Subject: [PATCH] selftests: mptcp: sockopt: use 'iptables-legacy' if available IPTables commands using 'iptables-nft' fail on old kernels, at least on v5.15 because it doesn't see the default IPTables chains: $ iptables -L iptables/1.8.2 Failed to initialize nft: Protocol not supported As a first step before switching to NFTables, we can use iptables-legacy if available. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: dc65fe82fb07 ("selftests: mptcp: add packet mark test case") Cc: stable(a)vger.kernel.org Acked-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/tools/testing/selftests/net/mptcp/mptcp_sockopt.sh b/tools/testing/selftests/net/mptcp/mptcp_sockopt.sh index f295a371ff14..c21bfd7f0c01 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_sockopt.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_sockopt.sh @@ -12,6 +12,8 @@ ksft_skip=4 timeout_poll=30 timeout_test=$((timeout_poll * 2 + 1)) mptcp_connect="" +iptables="iptables" +ip6tables="ip6tables" sec=$(date +%s) rndh=$(printf %x $sec)-$(mktemp -u XXXXXX) @@ -25,7 +27,7 @@ add_mark_rules() local m=$2 local t - for t in iptables ip6tables; do + for t in ${iptables} ${ip6tables}; do # just to debug: check we have multiple subflows connection requests ip netns exec $ns $t -A OUTPUT -p tcp --syn -m mark --mark $m -j ACCEPT @@ -95,14 +97,14 @@ if [ $? -ne 0 ];then exit $ksft_skip fi -iptables -V > /dev/null 2>&1 -if [ $? -ne 0 ];then +# Use the legacy version if available to support old kernel versions +if iptables-legacy -V &> /dev/null; then + iptables="iptables-legacy" + ip6tables="ip6tables-legacy" +elif ! iptables -V &> /dev/null; then echo "SKIP: Could not run all tests without iptables tool" exit $ksft_skip -fi - -ip6tables -V > /dev/null 2>&1 -if [ $? -ne 0 ];then +elif ! ip6tables -V &> /dev/null; then echo "SKIP: Could not run all tests without ip6tables tool" exit $ksft_skip fi @@ -112,10 +114,10 @@ check_mark() local ns=$1 local af=$2 - local tables=iptables + local tables=${iptables} if [ $af -eq 6 ];then - tables=ip6tables + tables=${ip6tables} fi local counters values

2 years, 3 months

2
1
0 0

FAILED: patch "[PATCH] mptcp: ensure subflow is unhashed before cleaning the backlog" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 3fffa15bfef48b0ad6424779c03e68ae8ace5acb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023072102-finicky-everyday-cce4@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 3fffa15bfef4 ("mptcp: ensure subflow is unhashed before cleaning the backlog") 57fc0f1ceaa4 ("mptcp: ensure listener is unhashed before updating the sk status") 2a6a870e44dd ("mptcp: stops worker on unaccepted sockets at listener close") 0a3f4f1f9c27 ("mptcp: fix UaF in listener shutdown") b6985b9b8295 ("mptcp: use the workqueue to destroy unaccepted sockets") c558246ee73e ("mptcp: add statistics for mptcp socket in use") cfdcfeed6449 ("mptcp: introduce 'sk' to replace 'sock->sk' in mptcp_listen()") fec3adfd754c ("mptcp: fix lockdep false positive") 7d803344fdc3 ("mptcp: fix deadlock in fastopen error path") f8c9dfbd875b ("mptcp: add pm listener events") f2bb566f5c97 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3fffa15bfef48b0ad6424779c03e68ae8ace5acb Mon Sep 17 00:00:00 2001 From: Paolo Abeni <pabeni(a)redhat.com> Date: Tue, 4 Jul 2023 22:44:33 +0200 Subject: [PATCH] mptcp: ensure subflow is unhashed before cleaning the backlog While tacking care of the mptcp-level listener I unintentionally moved the subflow level unhash after the subflow listener backlog cleanup. That could cause some nasty race and makes the code harder to read. Address the issue restoring the proper order of operations. Fixes: 57fc0f1ceaa4 ("mptcp: ensure listener is unhashed before updating the sk status") Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Reviewed-by: Matthieu Baerts <matthieu.baerts(a)tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index e892673deb73..489a3defdde5 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2909,10 +2909,10 @@ static void mptcp_check_listen_stop(struct sock *sk) return; lock_sock_nested(ssk, SINGLE_DEPTH_NESTING); + tcp_set_state(ssk, TCP_CLOSE); mptcp_subflow_queue_clean(sk, ssk); inet_csk_listen_stop(ssk); mptcp_event_pm_listener(ssk, MPTCP_EVENT_LISTENER_CLOSED); - tcp_set_state(ssk, TCP_CLOSE); release_sock(ssk); }

2 years, 3 months

2
1
0 0

[PATCH rc 0/3] Several iommufd bug fixes

by Jason Gunthorpe

Syzkaller found another small issue, a race with iommufd_object_destroy_user() and IOMMUFD_DESTROY. While researching that I noticed an error unwind mistake by inspection. Yi and Nicolin stumbled on the last one running the test suite sometimes. Jason Gunthorpe (3): iommufd/selftest: Do not try to destroy an access once it is attached iommufd: IOMMUFD_DESTROY should not increase the refcount iommufd: Set end correctly when doing batch carry drivers/iommu/iommufd/device.c | 12 +--- drivers/iommu/iommufd/iommufd_private.h | 15 ++++- drivers/iommu/iommufd/main.c | 78 +++++++++++++++++++------ drivers/iommu/iommufd/pages.c | 2 +- drivers/iommu/iommufd/selftest.c | 9 +-- 5 files changed, 81 insertions(+), 35 deletions(-) base-commit: 6eaae198076080886b9e7d57f4ae06fa782f90ef -- 2.41.0

2 years, 3 months

4
9
0 0

stable-rc/linux-5.15.y baseline: 125 runs, 14 regressions (v5.15.123)

by kernelci.org bot

stable-rc/linux-5.15.y baseline: 125 runs, 14 regressions (v5.15.123) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ asus-C436FA-Flip-hatch | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 asus-CM1400CXA-dalboz | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 asus-cx9400-volteer | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 cubietruck | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 fsl-ls2088a-rdb | arm64 | lab-nxp | gcc-10 | defconfig | 1 fsl-lx2160a-rdb | arm64 | lab-nxp | gcc-10 | defconfig | 1 hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 hp-x360-14a-cb0001xx-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 imx53-qsrb | arm | lab-pengutronix | gcc-10 | multi_v7_defconfig | 1 lenovo-TPad-C13-Yoga-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 r8a77960-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 r8a779m1-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 sun50i-h6-pine-h64 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-5.15.y/kernel/v5.15.12… Test: baseline Tree: stable-rc Branch: linux-5.15.y Describe: v5.15.123 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 09996673e3139a6d86fc3d95c852b3a020e2fe5f Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ asus-C436FA-Flip-hatch | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c245703972ee511a8ace80 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c245703972ee511a8ace85 failing since 120 days (last pass: v5.15.104, first fail: v5.15.104-147-gea115396267e) 2023-07-27T10:22:30.262110 <8>[ 10.894497] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150572_1.4.2.3.1> 2023-07-27T10:22:30.265360 + set +x 2023-07-27T10:22:30.370268 /# 2023-07-27T10:22:30.473067 # #export SHELL=/bin/sh 2023-07-27T10:22:30.474005 2023-07-27T10:22:30.575749 / # export SHELL=/bin/sh. /lava-11150572/environment 2023-07-27T10:22:30.576527 2023-07-27T10:22:30.678118 / # . /lava-11150572/environment/lava-11150572/bin/lava-test-runner /lava-11150572/1 2023-07-27T10:22:30.679348 2023-07-27T10:22:30.685996 / # /lava-11150572/bin/lava-test-runner /lava-11150572/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ asus-CM1400CXA-dalboz | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c245743972ee511a8acea4 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c245743972ee511a8acea9 failing since 120 days (last pass: v5.15.104, first fail: v5.15.104-147-gea115396267e) 2023-07-27T10:22:26.984831 + set<8>[ 11.428800] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150559_1.4.2.3.1> 2023-07-27T10:22:26.984914 +x 2023-07-27T10:22:27.089512 / # # 2023-07-27T10:22:27.190059 export SHELL=/bin/sh 2023-07-27T10:22:27.190218 # 2023-07-27T10:22:27.290742 / # export SHELL=/bin/sh. /lava-11150559/environment 2023-07-27T10:22:27.290926 2023-07-27T10:22:27.391447 / # . /lava-11150559/environment/lava-11150559/bin/lava-test-runner /lava-11150559/1 2023-07-27T10:22:27.391673 2023-07-27T10:22:27.396555 / # /lava-11150559/bin/lava-test-runner /lava-11150559/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ asus-cx9400-volteer | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c245703972ee511a8ace75 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c245703972ee511a8ace7a failing since 120 days (last pass: v5.15.104, first fail: v5.15.104-147-gea115396267e) 2023-07-27T10:22:22.962520 <8>[ 10.131031] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150555_1.4.2.3.1> 2023-07-27T10:22:22.966066 + set +x 2023-07-27T10:22:23.067379 2023-07-27T10:22:23.167954 / # #export SHELL=/bin/sh 2023-07-27T10:22:23.168110 2023-07-27T10:22:23.268618 / # export SHELL=/bin/sh. /lava-11150555/environment 2023-07-27T10:22:23.268798 2023-07-27T10:22:23.369314 / # . /lava-11150555/environment/lava-11150555/bin/lava-test-runner /lava-11150555/1 2023-07-27T10:22:23.369573 2023-07-27T10:22:23.375096 / # /lava-11150555/bin/lava-test-runner /lava-11150555/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ cubietruck | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/64c248a08cfb2e86b68ace23 Results: 5 PASS, 1 FAIL, 1 SKIP Full config: multi_v7_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm/multi_v7… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm/multi_v7… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c248a08cfb2e86b68ace28 failing since 191 days (last pass: v5.15.82-124-gd731c63c25d1, first fail: v5.15.87-101-g5bcc318cb4cd) 2023-07-27T10:35:55.081748 + set +x<8>[ 10.118777] <LAVA_SIGNAL_ENDRUN 0_dmesg 3725861_1.5.2.4.1> 2023-07-27T10:35:55.082386 2023-07-27T10:35:55.192234 / # # 2023-07-27T10:35:55.295672 export SHELL=/bin/sh 2023-07-27T10:35:55.296530 # 2023-07-27T10:35:55.296975 / # <3>[ 10.273381] Bluetooth: hci0: command 0xfc18 tx timeout 2023-07-27T10:35:55.398801 export SHELL=/bin/sh. /lava-3725861/environment 2023-07-27T10:35:55.399207 2023-07-27T10:35:55.500413 / # . /lava-3725861/environment/lava-3725861/bin/lava-test-runner /lava-3725861/1 2023-07-27T10:35:55.500877 ... (13 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ fsl-ls2088a-rdb | arm64 | lab-nxp | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c246696e129ed2c48ace65 Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c246696e129ed2c48ace68 failing since 13 days (last pass: v5.15.67, first fail: v5.15.119-16-g66130849c020f) 2023-07-27T10:26:25.074331 + [ 11.819644] <LAVA_SIGNAL_ENDRUN 0_dmesg 1238965_1.5.2.4.1> 2023-07-27T10:26:25.074667 set +x 2023-07-27T10:26:25.180752 2023-07-27T10:26:25.282040 / # #export SHELL=/bin/sh 2023-07-27T10:26:25.282652 2023-07-27T10:26:25.383861 / # export SHELL=/bin/sh. /lava-1238965/environment 2023-07-27T10:26:25.384466 2023-07-27T10:26:25.485659 / # . /lava-1238965/environment/lava-1238965/bin/lava-test-runner /lava-1238965/1 2023-07-27T10:26:25.486647 2023-07-27T10:26:25.490277 / # /lava-1238965/bin/lava-test-runner /lava-1238965/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ fsl-lx2160a-rdb | arm64 | lab-nxp | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c246da3795a97fbd8ace82 Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c246da3795a97fbd8ace85 failing since 145 days (last pass: v5.15.79, first fail: v5.15.98) 2023-07-27T10:28:22.070611 [ 14.108331] <LAVA_SIGNAL_ENDRUN 0_dmesg 1238967_1.5.2.4.1> 2023-07-27T10:28:22.175891 2023-07-27T10:28:22.277128 / # #export SHELL=/bin/sh 2023-07-27T10:28:22.277545 2023-07-27T10:28:22.378507 / # export SHELL=/bin/sh. /lava-1238967/environment 2023-07-27T10:28:22.378925 2023-07-27T10:28:22.479951 / # . /lava-1238967/environment/lava-1238967/bin/lava-test-runner /lava-1238967/1 2023-07-27T10:28:22.480672 2023-07-27T10:28:22.484655 / # /lava-1238967/bin/lava-test-runner /lava-1238967/1 2023-07-27T10:28:22.500049 + export 'TESTRUN_ID=1_bootrr' ... (11 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2455cafd0900d4d8ace3c Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c2455cafd0900d4d8ace41 failing since 120 days (last pass: v5.15.104, first fail: v5.15.104-147-gea115396267e) 2023-07-27T10:22:06.987857 + set +x 2023-07-27T10:22:06.994079 <8>[ 10.736868] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150525_1.4.2.3.1> 2023-07-27T10:22:07.098818 / # # 2023-07-27T10:22:07.199428 export SHELL=/bin/sh 2023-07-27T10:22:07.199653 # 2023-07-27T10:22:07.300193 / # export SHELL=/bin/sh. /lava-11150525/environment 2023-07-27T10:22:07.300380 2023-07-27T10:22:07.400861 / # . /lava-11150525/environment/lava-11150525/bin/lava-test-runner /lava-11150525/1 2023-07-27T10:22:07.401190 2023-07-27T10:22:07.406002 / # /lava-11150525/bin/lava-test-runner /lava-11150525/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c245597690933eb58ace83 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c245597690933eb58ace88 failing since 120 days (last pass: v5.15.104, first fail: v5.15.104-147-gea115396267e) 2023-07-27T10:22:02.680709 + set +x 2023-07-27T10:22:02.687474 <8>[ 10.618664] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150521_1.4.2.3.1> 2023-07-27T10:22:02.789034 # 2023-07-27T10:22:02.789322 2023-07-27T10:22:02.889866 / # #export SHELL=/bin/sh 2023-07-27T10:22:02.890074 2023-07-27T10:22:02.990662 / # export SHELL=/bin/sh. /lava-11150521/environment 2023-07-27T10:22:02.990830 2023-07-27T10:22:03.091314 / # . /lava-11150521/environment/lava-11150521/bin/lava-test-runner /lava-11150521/1 2023-07-27T10:22:03.091568 ... (13 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ hp-x360-14a-cb0001xx-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c24573c15c391f538ace34 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c24573c15c391f538ace39 failing since 120 days (last pass: v5.15.104, first fail: v5.15.104-147-gea115396267e) 2023-07-27T10:22:20.649190 + set +x<8>[ 11.641912] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150570_1.4.2.3.1> 2023-07-27T10:22:20.649768 2023-07-27T10:22:20.757718 / # # 2023-07-27T10:22:20.860138 export SHELL=/bin/sh 2023-07-27T10:22:20.860934 # 2023-07-27T10:22:20.962538 / # export SHELL=/bin/sh. /lava-11150570/environment 2023-07-27T10:22:20.963349 2023-07-27T10:22:21.065089 / # . /lava-11150570/environment/lava-11150570/bin/lava-test-runner /lava-11150570/1 2023-07-27T10:22:21.066352 2023-07-27T10:22:21.071993 / # /lava-11150570/bin/lava-test-runner /lava-11150570/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ imx53-qsrb | arm | lab-pengutronix | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/64c2486d4c4a292a888ace1e Results: 5 PASS, 1 FAIL, 1 SKIP Full config: multi_v7_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm/multi_v7… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm/multi_v7… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c2486d4c4a292a888ace23 failing since 177 days (last pass: v5.15.81-122-gc5f8d4a5d3c8, first fail: v5.15.90-205-g5605d15db022) 2023-07-27T10:35:03.483692 + set +x 2023-07-27T10:35:03.484058 [ 9.425898] <LAVA_SIGNAL_ENDRUN 0_dmesg 996375_1.5.2.3.1> 2023-07-27T10:35:03.592937 / # # 2023-07-27T10:35:03.694671 export SHELL=/bin/sh 2023-07-27T10:35:03.695146 # 2023-07-27T10:35:03.796376 / # export SHELL=/bin/sh. /lava-996375/environment 2023-07-27T10:35:03.796870 2023-07-27T10:35:03.898193 / # . /lava-996375/environment/lava-996375/bin/lava-test-runner /lava-996375/1 2023-07-27T10:35:03.899062 2023-07-27T10:35:03.901378 / # /lava-996375/bin/lava-test-runner /lava-996375/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ lenovo-TPad-C13-Yoga-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c245683972ee511a8ace54 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/x86_64/x86_6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c245683972ee511a8ace59 failing since 120 days (last pass: v5.15.104, first fail: v5.15.104-147-gea115396267e) 2023-07-27T10:22:33.533105 + set<8>[ 11.620404] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150541_1.4.2.3.1> 2023-07-27T10:22:33.533690 +x 2023-07-27T10:22:33.641344 / # # 2023-07-27T10:22:33.743441 export SHELL=/bin/sh 2023-07-27T10:22:33.744142 # 2023-07-27T10:22:33.845494 / # export SHELL=/bin/sh. /lava-11150541/environment 2023-07-27T10:22:33.846197 2023-07-27T10:22:33.947826 / # . /lava-11150541/environment/lava-11150541/bin/lava-test-runner /lava-11150541/1 2023-07-27T10:22:33.948953 2023-07-27T10:22:33.953735 / # /lava-11150541/bin/lava-test-runner /lava-11150541/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ r8a77960-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c26693f2b6d73b668ace49 Results: 4 PASS, 2 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c26693f2b6d73b668ace4e failing since 7 days (last pass: v5.15.120-274-g478387c57e172, first fail: v5.15.120) 2023-07-27T12:45:18.746894 / # # 2023-07-27T12:45:18.849006 export SHELL=/bin/sh 2023-07-27T12:45:18.849710 # 2023-07-27T12:45:18.951164 / # export SHELL=/bin/sh. /lava-11150582/environment 2023-07-27T12:45:18.951870 2023-07-27T12:45:19.053317 / # . /lava-11150582/environment/lava-11150582/bin/lava-test-runner /lava-11150582/1 2023-07-27T12:45:19.054406 2023-07-27T12:45:19.071049 / # /lava-11150582/bin/lava-test-runner /lava-11150582/1 2023-07-27T12:45:19.120017 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T12:45:19.120525 + cd /lav<8>[ 15.994993] <LAVA_SIGNAL_STARTRUN 1_bootrr 11150582_1.5.2.4.5> ... (28 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ r8a779m1-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c2462f346e1e69238ace47 Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c2462f346e1e69238ace4c failing since 7 days (last pass: v5.15.120-274-g478387c57e172, first fail: v5.15.120) 2023-07-27T10:26:00.569112 / # # 2023-07-27T10:26:01.649843 export SHELL=/bin/sh 2023-07-27T10:26:01.651781 # 2023-07-27T10:26:03.142958 / # export SHELL=/bin/sh. /lava-11150580/environment 2023-07-27T10:26:03.144933 2023-07-27T10:26:05.870905 / # . /lava-11150580/environment/lava-11150580/bin/lava-test-runner /lava-11150580/1 2023-07-27T10:26:05.873324 2023-07-27T10:26:05.878625 / # /lava-11150580/bin/lava-test-runner /lava-11150580/1 2023-07-27T10:26:05.944187 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T10:26:05.944701 + cd /lava-111505<8>[ 25.560197] <LAVA_SIGNAL_STARTRUN 1_bootrr 11150580_1.5.2.4.5> ... (38 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+-----------------+----------+------------------------------+------------ sun50i-h6-pine-h64 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c24623319174b8898ace29 Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-5.15.y/v5.15.123/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c24623319174b8898ace2e failing since 7 days (last pass: v5.15.120-274-g478387c57e172, first fail: v5.15.120) 2023-07-27T10:27:06.680847 / # # 2023-07-27T10:27:06.783357 export SHELL=/bin/sh 2023-07-27T10:27:06.784140 # 2023-07-27T10:27:06.885638 / # export SHELL=/bin/sh. /lava-11150585/environment 2023-07-27T10:27:06.886347 2023-07-27T10:27:06.987882 / # . /lava-11150585/environment/lava-11150585/bin/lava-test-runner /lava-11150585/1 2023-07-27T10:27:06.989157 2023-07-27T10:27:07.005119 / # /lava-11150585/bin/lava-test-runner /lava-11150585/1 2023-07-27T10:27:07.063031 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T10:27:07.063541 + cd /lava-1115058<8>[ 16.870848] <LAVA_SIGNAL_STARTRUN 1_bootrr 11150585_1.5.2.4.5> ... (10 line(s) more)

2 years, 3 months

1
0
0 0

stable-rc/linux-4.19.y baseline: 102 runs, 21 regressions (v4.19.289)

by kernelci.org bot

stable-rc/linux-4.19.y baseline: 102 runs, 21 regressions (v4.19.289) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ at91sam9g20ek | arm | lab-broonie | gcc-10 | multi_v5_defconfig | 1 beaglebone-black | arm | lab-broonie | gcc-10 | omap2plus_defconfig | 1 cubietruck | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 rk3399-gru-kevin | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 2 Details: https://kernelci.org/test/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.28… Test: baseline Tree: stable-rc Branch: linux-4.19.y Describe: v4.19.289 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 767049cead76cf699707290d5aeefb3e4d0d5b43 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ at91sam9g20ek | arm | lab-broonie | gcc-10 | multi_v5_defconfig | 1 Details: https://kernelci.org/test/plan/id/64c240c94b3320f12d8ace73 Results: 42 PASS, 9 FAIL, 1 SKIP Full config: multi_v5_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm/multi_v5… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm/multi_v5… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c240c94b3320f12d8acea5 failing since 27 days (last pass: v4.19.287, first fail: v4.19.288-6-g9430a6475aa0) 2023-07-27T10:02:13.030845 + set +x 2023-07-27T10:02:13.036053 <8><LAVA_SIGNAL_ENDRUN 0_dmesg 12930_1.5.2.4.1> 2023-07-27T10:02:13.149250 / # # 2023-07-27T10:02:13.252067 export SHELL=/bin/sh 2023-07-27T10:02:13.252950 # 2023-07-27T10:02:13.354812 / # export SHELL=/bin/sh. /lava-12930/environment 2023-07-27T10:02:13.355603 2023-07-27T10:02:13.457537 / # . /lava-12930/environment/lava-12930/bin/lava-test-runner /lava-12930/1 2023-07-27T10:02:13.458818 2023-07-27T10:02:13.465200 / # /lava-12930/bin/lava-test-runner /lava-12930/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ beaglebone-black | arm | lab-broonie | gcc-10 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/plan/id/64c240d44b3320f12d8aceb7 Results: 41 PASS, 10 FAIL, 1 SKIP Full config: omap2plus_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm/omap2plu… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm/omap2plu… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c240d44b3320f12d8acee8 new failure (last pass: v4.19.289-218-gd8e587288fc49) 2023-07-27T10:02:39.546659 + set +x<8>[ 16.090090] <LAVA_SIGNAL_ENDRUN 0_dmesg 12935_1.5.2.4.1> 2023-07-27T10:02:39.547258 2023-07-27T10:02:39.660155 / # # 2023-07-27T10:02:39.763430 export SHELL=/bin/sh 2023-07-27T10:02:39.764338 # 2023-07-27T10:02:39.866503 / # export SHELL=/bin/sh. /lava-12935/environment 2023-07-27T10:02:39.867446 2023-07-27T10:02:39.969538 / # . /lava-12935/environment/lava-12935/bin/lava-test-runner /lava-12935/1 2023-07-27T10:02:39.971036 2023-07-27T10:02:39.975631 / # /lava-12935/bin/lava-test-runner /lava-12935/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ cubietruck | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/64c2428029a1a8dd0b8ace5c Results: 5 PASS, 1 FAIL, 1 SKIP Full config: multi_v7_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm/multi_v7… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm/multi_v7… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c2428029a1a8dd0b8ace61 failing since 191 days (last pass: v4.19.268-50-gbf741d1d7e6d, first fail: v4.19.269-522-gc75d2b5524ab) 2023-07-27T10:09:58.686269 <8>[ 7.375611] <LAVA_SIGNAL_ENDRUN 0_dmesg 3725827_1.5.2.4.1> 2023-07-27T10:09:58.797683 / # # 2023-07-27T10:09:58.900875 export SHELL=/bin/sh 2023-07-27T10:09:58.901915 # 2023-07-27T10:09:59.004101 / # export SHELL=/bin/sh. /lava-3725827/environment 2023-07-27T10:09:59.005140 2023-07-27T10:09:59.107234 / # . /lava-3725827/environment/lava-3725827/bin/lava-test-runner /lava-3725827/1 2023-07-27T10:09:59.108778 2023-07-27T10:09:59.113838 / # /lava-3725827/bin/lava-test-runner /lava-3725827/1 2023-07-27T10:09:59.191980 + export 'TESTRUN_ID=1_bootrr' ... (11 line(s) more) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c244a8b6b99727a78ace1c Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c244a8b6b99727a78ace1d failing since 345 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.255-191-gab9c8d4442969) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2464b0fc9cf80bc8ace1c Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c2464b0fc9cf80bc8ace1d failing since 345 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.255-215-g4373264025937) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c242ed5491e185908ace32 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c242ed5491e185908ace33 failing since 345 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.255-191-gab9c8d4442969) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c244054a062484ab8ace6d Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c244054a062484ab8ace6e failing since 345 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.255-215-g4373264025937) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c2440727e05b5c408ace1c Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c2440727e05b5c408ace1d failing since 332 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.256-37-g34c3cf0160a8) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2468827211a316f8ace28 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c2468827211a316f8ace29 failing since 338 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.255-288-g9901269a16d1) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c242c6f75b382f4b8ace40 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c242c6f75b382f4b8ace41 failing since 332 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.256-37-g34c3cf0160a8) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c244274a062484ab8ace7b Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c244274a062484ab8ace7c failing since 338 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.255-288-g9901269a16d1) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c2441b27e05b5c408ace38 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c2441b27e05b5c408ace39 failing since 357 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.254) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2464d0fc9cf80bc8ace1f Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c2464d0fc9cf80bc8ace20 failing since 345 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.255-191-gab9c8d4442969) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c242c7f75b382f4b8ace43 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c242c7f75b382f4b8ace44 failing since 357 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.254) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c244054a062484ab8ace70 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c244054a062484ab8ace71 failing since 345 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.255-191-gab9c8d4442969) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c24367b7c408a4298ace1c Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c24367b7c408a4298ace1d failing since 343 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.255) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c24660d29b49076c8ace28 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c24660d29b49076c8ace29 failing since 338 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.255-288-g9901269a16d1) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c2429d7eee666aa98ace2f Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c2429d7eee666aa98ace30 failing since 343 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.255) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2442527e05b5c408ace3b Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c2442527e05b5c408ace3c failing since 338 days (last pass: v4.19.230-41-g73351b9c55d9, first fail: v4.19.255-288-g9901269a16d1) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+---------------+----------+----------------------------+------------ rk3399-gru-kevin | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 2 Details: https://kernelci.org/test/plan/id/64c242ef62694401978ace21 Results: 77 PASS, 5 FAIL, 1 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.289/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.rockchip-usb2phy1-probed: https://kernelci.org/test/case/id/64c242ef62694401978ace27 failing since 135 days (last pass: v4.19.276, first fail: v4.19.276-4-g4f95ee925a2b) 2023-07-27T10:11:53.077085 <8>[ 36.341930] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=rockchip-usb2phy0-probed RESULT=fail> 2023-07-27T10:11:54.089680 /lava-11150476/1/../bin/lava-test-case 2023-07-27T10:11:54.098457 <8>[ 37.364307] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=rockchip-usb2phy1-probed RESULT=fail> * baseline.bootrr.rockchip-usb2phy0-probed: https://kernelci.org/test/case/id/64c242ef62694401978ace28 failing since 135 days (last pass: v4.19.276, first fail: v4.19.276-4-g4f95ee925a2b) 2023-07-27T10:11:53.067716 /lava-11150476/1/../bin/lava-test-case

2 years, 3 months

1
0
0 0

stable-rc/linux-5.10.y baseline: 126 runs, 10 regressions (v5.10.188)

by kernelci.org bot

stable-rc/linux-5.10.y baseline: 126 runs, 10 regressions (v5.10.188) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ cubietruck | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 dell-latitude...8665U-sarien | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 fsl-ls2088a-rdb | arm64 | lab-nxp | gcc-10 | defconfig | 1 fsl-lx2160a-rdb | arm64 | lab-nxp | gcc-10 | defconfig | 1 hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 juno-uboot | arm64 | lab-broonie | gcc-10 | defconfig | 1 r8a774c0-ek874 | arm64 | lab-cip | gcc-10 | defconfig | 1 r8a77960-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 sun50i-h6-pine-h64 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-5.10.y/kernel/v5.10.18… Test: baseline Tree: stable-rc Branch: linux-5.10.y Describe: v5.10.188 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 3602dbc57b556eff2456715301d35a1ef8964bba Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ cubietruck | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23ffe07e90ad7338aceec Results: 5 PASS, 1 FAIL, 1 SKIP Full config: multi_v7_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm/multi_v7… HTML log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm/multi_v7… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c23ffe07e90ad7338acef1 failing since 190 days (last pass: v5.10.158-107-gd2432186ff47, first fail: v5.10.162-852-geeaac3cf2eb3) 2023-07-27T09:59:16.023012 <8>[ 10.983016] <LAVA_SIGNAL_ENDRUN 0_dmesg 3725818_1.5.2.4.1> 2023-07-27T09:59:16.130090 / # # 2023-07-27T09:59:16.231557 export SHELL=/bin/sh 2023-07-27T09:59:16.232058 # 2023-07-27T09:59:16.333373 / # export SHELL=/bin/sh. /lava-3725818/environment 2023-07-27T09:59:16.333970 2023-07-27T09:59:16.435329 / # . /lava-3725818/environment/lava-3725818/bin/lava-test-runner /lava-3725818/1 2023-07-27T09:59:16.436024 2023-07-27T09:59:16.440850 / # /lava-3725818/bin/lava-test-runner /lava-3725818/1 2023-07-27T09:59:16.526067 + export 'TESTRUN_ID=1_bootrr' ... (11 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ dell-latitude...8665U-sarien | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c23f9009d0e3559a8ace53 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/x86_64/x86_6… HTML log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/x86_64/x86_6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c23f9009d0e3559a8ace54 new failure (last pass: v5.10.187-509-g76be48121794) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ fsl-ls2088a-rdb | arm64 | lab-nxp | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23fd35d952e1d418ace40 Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c23fd35d952e1d418ace43 failing since 9 days (last pass: v5.10.142, first fail: v5.10.186-332-gf98a4d3a5cec) 2023-07-27T09:58:25.246516 [ 14.909841] <LAVA_SIGNAL_ENDRUN 0_dmesg 1238937_1.5.2.4.1> 2023-07-27T09:58:25.352285 2023-07-27T09:58:25.453764 / # #export SHELL=/bin/sh 2023-07-27T09:58:25.454368 2023-07-27T09:58:25.555640 / # export SHELL=/bin/sh. /lava-1238937/environment 2023-07-27T09:58:25.556237 2023-07-27T09:58:25.657461 / # . /lava-1238937/environment/lava-1238937/bin/lava-test-runner /lava-1238937/1 2023-07-27T09:58:25.658305 2023-07-27T09:58:25.662034 / # /lava-1238937/bin/lava-test-runner /lava-1238937/1 2023-07-27T09:58:25.683691 + export 'TESTRUN_[ 15.346325] <LAVA_SIGNAL_STARTRUN 1_bootrr 1238937_1.5.2.4.5> ... (11 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ fsl-lx2160a-rdb | arm64 | lab-nxp | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23fd65d952e1d418ace4e Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c23fd65d952e1d418ace51 failing since 145 days (last pass: v5.10.155, first fail: v5.10.172) 2023-07-27T09:58:25.700054 [ 14.454170] <LAVA_SIGNAL_ENDRUN 0_dmesg 1238938_1.5.2.4.1> 2023-07-27T09:58:25.806466 2023-07-27T09:58:25.907704 / # #export SHELL=/bin/sh 2023-07-27T09:58:25.908089 2023-07-27T09:58:26.009054 / # export SHELL=/bin/sh. /lava-1238938/environment 2023-07-27T09:58:26.009520 2023-07-27T09:58:26.110519 / # . /lava-1238938/environment/lava-1238938/bin/lava-test-runner /lava-1238938/1 2023-07-27T09:58:26.111220 2023-07-27T09:58:26.115158 / # /lava-1238938/bin/lava-test-runner /lava-1238938/1 2023-07-27T09:58:26.129871 + export 'TESTRUN_ID=1_bootrr' ... (11 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c23eb666afdf8bc18ace2b Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/x86_64/x86_6… HTML log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/x86_64/x86_6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c23eb666afdf8bc18ace30 failing since 120 days (last pass: v5.10.176, first fail: v5.10.176-105-g18265b240021) 2023-07-27T09:53:39.813083 + set +x 2023-07-27T09:53:39.818997 <8>[ 10.062446] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150217_1.4.2.3.1> 2023-07-27T09:53:39.928287 / # # 2023-07-27T09:53:40.031015 export SHELL=/bin/sh 2023-07-27T09:53:40.031297 # 2023-07-27T09:53:40.132143 / # export SHELL=/bin/sh. /lava-11150217/environment 2023-07-27T09:53:40.132977 2023-07-27T09:53:40.234509 / # . /lava-11150217/environment/lava-11150217/bin/lava-test-runner /lava-11150217/1 2023-07-27T09:53:40.235669 2023-07-27T09:53:40.240576 / # /lava-11150217/bin/lava-test-runner /lava-11150217/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c23e8dcc4039dd348acec5 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/x86_64/x86_6… HTML log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/x86_64/x86_6… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c23e8dcc4039dd348aceca failing since 120 days (last pass: v5.10.176, first fail: v5.10.176-105-g18265b240021) 2023-07-27T09:53:11.866230 <8>[ 13.020284] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150179_1.4.2.3.1> 2023-07-27T09:53:11.869630 + set +x 2023-07-27T09:53:11.970882 # 2023-07-27T09:53:11.971115 2023-07-27T09:53:12.071659 / # #export SHELL=/bin/sh 2023-07-27T09:53:12.071838 2023-07-27T09:53:12.172318 / # export SHELL=/bin/sh. /lava-11150179/environment 2023-07-27T09:53:12.172524 2023-07-27T09:53:12.273102 / # . /lava-11150179/environment/lava-11150179/bin/lava-test-runner /lava-11150179/1 2023-07-27T09:53:12.273362 ... (13 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ juno-uboot | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c240019d5b0809508ace6e Results: 50 PASS, 11 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c240019d5b0809508acea7 failing since 9 days (last pass: v5.10.186-221-gf178eace6e074, first fail: v5.10.186-332-gf98a4d3a5cec) 2023-07-27T09:58:53.511225 / # # 2023-07-27T09:58:53.614091 export SHELL=/bin/sh 2023-07-27T09:58:53.614860 # 2023-07-27T09:58:53.716855 / # export SHELL=/bin/sh. /lava-12872/environment 2023-07-27T09:58:53.717624 2023-07-27T09:58:53.819591 / # . /lava-12872/environment/lava-12872/bin/lava-test-runner /lava-12872/1 2023-07-27T09:58:53.820929 2023-07-27T09:58:53.835248 / # /lava-12872/bin/lava-test-runner /lava-12872/1 2023-07-27T09:58:53.893060 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T09:58:53.893582 + cd /lava-12872/1/tests/1_bootrr ... (10 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ r8a774c0-ek874 | arm64 | lab-cip | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23ff308b37a634f8ace65 Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c23ff308b37a634f8ace68 failing since 9 days (last pass: v5.10.186-221-gf178eace6e074, first fail: v5.10.186-332-gf98a4d3a5cec) 2023-07-27T09:58:53.291797 / # # 2023-07-27T09:58:54.753100 export SHELL=/bin/sh 2023-07-27T09:58:54.773559 # 2023-07-27T09:58:54.773691 / # export SHELL=/bin/sh 2023-07-27T09:58:56.658075 / # . /lava-989712/environment 2023-07-27T09:59:00.113983 /lava-989712/bin/lava-test-runner /lava-989712/1 2023-07-27T09:59:00.134771 . /lava-989712/environment 2023-07-27T09:59:00.134881 / # /lava-989712/bin/lava-test-runner /lava-989712/1 2023-07-27T09:59:00.214001 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T09:59:00.214399 + cd /lava-989712/1/tests/1_bootrr ... (25 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ r8a77960-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c265cb9531ca38d98ace1e Results: 4 PASS, 2 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c265cb9531ca38d98ace23 failing since 9 days (last pass: v5.10.186-221-gf178eace6e074, first fail: v5.10.186-332-gf98a4d3a5cec) 2023-07-27T12:41:59.391062 / # # 2023-07-27T12:41:59.493127 export SHELL=/bin/sh 2023-07-27T12:41:59.493842 # 2023-07-27T12:41:59.595267 / # export SHELL=/bin/sh. /lava-11150237/environment 2023-07-27T12:41:59.595986 2023-07-27T12:41:59.697474 / # . /lava-11150237/environment/lava-11150237/bin/lava-test-runner /lava-11150237/1 2023-07-27T12:41:59.698574 2023-07-27T12:41:59.715172 / # /lava-11150237/bin/lava-test-runner /lava-11150237/1 2023-07-27T12:41:59.764310 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T12:41:59.764827 + cd /lav<8>[ 16.446216] <LAVA_SIGNAL_STARTRUN 1_bootrr 11150237_1.5.2.4.5> ... (28 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ sun50i-h6-pine-h64 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23f57b2c6f7745f8acf6a Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-5.10.y/v5.10.188/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c23f57b2c6f7745f8acf6f failing since 9 days (last pass: v5.10.186-221-gf178eace6e074, first fail: v5.10.186-332-gf98a4d3a5cec) 2023-07-27T09:58:03.779555 / # # 2023-07-27T09:58:03.881755 export SHELL=/bin/sh 2023-07-27T09:58:03.882487 # 2023-07-27T09:58:03.983865 / # export SHELL=/bin/sh. /lava-11150250/environment 2023-07-27T09:58:03.984627 2023-07-27T09:58:04.086143 / # . /lava-11150250/environment/lava-11150250/bin/lava-test-runner /lava-11150250/1 2023-07-27T09:58:04.087345 2023-07-27T09:58:04.089595 / # /lava-11150250/bin/lava-test-runner /lava-11150250/1 2023-07-27T09:58:04.133495 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T09:58:04.163562 + cd /lava-1115025<8>[ 18.261224] <LAVA_SIGNAL_STARTRUN 1_bootrr 11150250_1.5.2.4.5> ... (10 line(s) more)

2 years, 3 months

1
0
0 0

stable/linux-6.1.y baseline: 126 runs, 14 regressions (v6.1.42)

by kernelci.org bot

stable/linux-6.1.y baseline: 126 runs, 14 regressions (v6.1.42) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ acer-chromebox-cxi4-puff | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 asus-C436FA-Flip-hatch | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 asus-CM1400CXA-dalboz | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 asus-cx9400-volteer | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 hp-x360-14a-cb0001xx-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 kontron-pitx-imx8m | arm64 | lab-kontron | gcc-10 | defconfig | 2 lenovo-TPad-C13-Yoga-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 r8a77960-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 r8a779m1-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 rk3399-gru-kevin | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 sun50i-h6-pine-h64 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/job/stable/branch/linux-6.1.y/kernel/v6.1.42/plan… Test: baseline Tree: stable Branch: linux-6.1.y Describe: v6.1.42 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git SHA: d2a6dc4eaf6d50ba32a9b39b4c6ec713a92072ab Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ acer-chromebox-cxi4-puff | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2386c2123f915bf8ace58 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c2386c2123f915bf8ace59 new failure (last pass: v6.1.39) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ asus-C436FA-Flip-hatch | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c238446462360d578ace53 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c238446462360d578ace58 failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T09:26:52.684874 <8>[ 10.654124] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150004_1.4.2.3.1> 2023-07-27T09:26:52.688173 + set +x 2023-07-27T09:26:52.789755 # 2023-07-27T09:26:52.890559 / # #export SHELL=/bin/sh 2023-07-27T09:26:52.890708 2023-07-27T09:26:52.991219 / # export SHELL=/bin/sh. /lava-11150004/environment 2023-07-27T09:26:52.991368 2023-07-27T09:26:53.091879 / # . /lava-11150004/environment/lava-11150004/bin/lava-test-runner /lava-11150004/1 2023-07-27T09:26:53.092113 2023-07-27T09:26:53.097806 / # /lava-11150004/bin/lava-test-runner /lava-11150004/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ asus-CM1400CXA-dalboz | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c23844674b4f64ee8ace20 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c23844674b4f64ee8ace25 failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T09:26:12.632315 + set<8>[ 11.662074] <LAVA_SIGNAL_ENDRUN 0_dmesg 11149991_1.4.2.3.1> 2023-07-27T09:26:12.632882 +x 2023-07-27T09:26:12.741087 / # # 2023-07-27T09:26:12.843683 export SHELL=/bin/sh 2023-07-27T09:26:12.844482 # 2023-07-27T09:26:12.946063 / # export SHELL=/bin/sh. /lava-11149991/environment 2023-07-27T09:26:12.946922 2023-07-27T09:26:13.048645 / # . /lava-11149991/environment/lava-11149991/bin/lava-test-runner /lava-11149991/1 2023-07-27T09:26:13.049903 2023-07-27T09:26:13.054814 / # /lava-11149991/bin/lava-test-runner /lava-11149991/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ asus-cx9400-volteer | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c238436462360d578ace48 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c238436462360d578ace4d failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T09:26:15.557285 <8>[ 10.163047] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150023_1.4.2.3.1> 2023-07-27T09:26:15.560702 + set +x 2023-07-27T09:26:15.661871 # 2023-07-27T09:26:15.763026 / # #export SHELL=/bin/sh 2023-07-27T09:26:15.763258 2023-07-27T09:26:15.863850 / # export SHELL=/bin/sh. /lava-11150023/environment 2023-07-27T09:26:15.864042 2023-07-27T09:26:15.964568 / # . /lava-11150023/environment/lava-11150023/bin/lava-test-runner /lava-11150023/1 2023-07-27T09:26:15.964827 2023-07-27T09:26:15.969680 / # /lava-11150023/bin/lava-test-runner /lava-11150023/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c238436462360d578ace3d Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c238436462360d578ace42 failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T09:26:39.911217 + set +x 2023-07-27T09:26:39.917814 <8>[ 10.466224] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150002_1.4.2.3.1> 2023-07-27T09:26:40.022510 / # # 2023-07-27T09:26:40.123201 export SHELL=/bin/sh 2023-07-27T09:26:40.123419 # 2023-07-27T09:26:40.223947 / # export SHELL=/bin/sh. /lava-11150002/environment 2023-07-27T09:26:40.224216 2023-07-27T09:26:40.324804 / # . /lava-11150002/environment/lava-11150002/bin/lava-test-runner /lava-11150002/1 2023-07-27T09:26:40.325137 2023-07-27T09:26:40.329474 / # /lava-11150002/bin/lava-test-runner /lava-11150002/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2383b34e7310bfa8aced2 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c2383b34e7310bfa8aced7 failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T09:26:01.347986 + set<8>[ 10.895002] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150028_1.4.2.3.1> 2023-07-27T09:26:01.348438 +x 2023-07-27T09:26:01.456412 # 2023-07-27T09:26:01.457499 2023-07-27T09:26:01.559234 / # #export SHELL=/bin/sh 2023-07-27T09:26:01.560088 2023-07-27T09:26:01.661581 / # export SHELL=/bin/sh. /lava-11150028/environment 2023-07-27T09:26:01.662291 2023-07-27T09:26:01.763972 / # . /lava-11150028/environment/lava-11150028/bin/lava-test-runner /lava-11150028/1 2023-07-27T09:26:01.765333 ... (13 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ hp-x360-14a-cb0001xx-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2384f6945ad91658ace21 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c238506945ad91658ace26 failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T09:26:20.321384 + <8>[ 11.414220] <LAVA_SIGNAL_ENDRUN 0_dmesg 11150029_1.4.2.3.1> 2023-07-27T09:26:20.322107 set +x 2023-07-27T09:26:20.430787 / # # 2023-07-27T09:26:20.533293 export SHELL=/bin/sh 2023-07-27T09:26:20.534068 # 2023-07-27T09:26:20.635725 / # export SHELL=/bin/sh. /lava-11150029/environment 2023-07-27T09:26:20.636577 2023-07-27T09:26:20.738198 / # . /lava-11150029/environment/lava-11150029/bin/lava-test-runner /lava-11150029/1 2023-07-27T09:26:20.739404 2023-07-27T09:26:20.744666 / # /lava-11150029/bin/lava-test-runner /lava-11150029/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ kontron-pitx-imx8m | arm64 | lab-kontron | gcc-10 | defconfig | 2 Details: https://kernelci.org/test/plan/id/64c23ad498493700c98acf29 Results: 50 PASS, 2 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/arm64/defconfig/gc… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/arm64/defconfig/gc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c23ad498493700c98acf2c new failure (last pass: v6.1.39) 2023-07-27T09:37:08.507309 / # # 2023-07-27T09:37:08.609396 export SHELL=/bin/sh 2023-07-27T09:37:08.610105 # 2023-07-27T09:37:08.711486 / # export SHELL=/bin/sh. /lava-372313/environment 2023-07-27T09:37:08.712168 2023-07-27T09:37:08.813754 / # . /lava-372313/environment/lava-372313/bin/lava-test-runner /lava-372313/1 2023-07-27T09:37:08.814940 2023-07-27T09:37:08.834952 / # /lava-372313/bin/lava-test-runner /lava-372313/1 2023-07-27T09:37:08.883935 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T09:37:08.884356 + cd /l<8>[ 14.475852] <LAVA_SIGNAL_STARTRUN 1_bootrr 372313_1.5.2.4.5> ... (10 line(s) more) * baseline.bootrr.dwc3-usb1-probed: https://kernelci.org/test/case/id/64c23ad498493700c98acf3c new failure (last pass: v6.1.39) 2023-07-27T09:37:11.237715 /lava-372313/1/../bin/lava-test-case 2023-07-27T09:37:11.238172 <8>[ 16.923794] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=dwc3-usb1-probed RESULT=fail> 2023-07-27T09:37:11.238535 /lava-372313/1/../bin/lava-test-case platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ lenovo-TPad-C13-Yoga-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2383734e7310bfa8aceaf Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/x86_64/x86_64_defc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c2383734e7310bfa8aceb4 failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T09:25:57.458565 <8>[ 12.325727] <LAVA_SIGNAL_ENDRUN 0_dmesg 11149980_1.4.2.3.1> 2023-07-27T09:25:57.562748 / # # 2023-07-27T09:25:57.663422 export SHELL=/bin/sh 2023-07-27T09:25:57.663625 # 2023-07-27T09:25:57.764169 / # export SHELL=/bin/sh. /lava-11149980/environment 2023-07-27T09:25:57.764394 2023-07-27T09:25:57.864949 / # . /lava-11149980/environment/lava-11149980/bin/lava-test-runner /lava-11149980/1 2023-07-27T09:25:57.865277 2023-07-27T09:25:57.869926 / # /lava-11149980/bin/lava-test-runner /lava-11149980/1 2023-07-27T09:25:57.876586 + export 'TESTRUN_ID=1_bootrr' ... (11 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ r8a77960-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c265b7feaa48b4218ace4c Results: 4 PASS, 2 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/arm64/defconfig/gc… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/arm64/defconfig/gc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c265b7feaa48b4218ace51 failing since 7 days (last pass: v6.1.38, first fail: v6.1.39) 2023-07-27T12:41:43.323373 / # # 2023-07-27T12:41:43.425558 export SHELL=/bin/sh 2023-07-27T12:41:43.426276 # 2023-07-27T12:41:43.527664 / # export SHELL=/bin/sh. /lava-11150064/environment 2023-07-27T12:41:43.528376 2023-07-27T12:41:43.629744 / # . /lava-11150064/environment/lava-11150064/bin/lava-test-runner /lava-11150064/1 2023-07-27T12:41:43.630821 2023-07-27T12:41:43.647647 / # /lava-11150064/bin/lava-test-runner /lava-11150064/1 2023-07-27T12:41:43.695558 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T12:41:43.696021 + cd /lav<8>[ 19.085451] <LAVA_SIGNAL_STARTRUN 1_bootrr 11150064_1.5.2.4.5> ... (28 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ r8a779m1-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23b01aa7306242f8ace2c Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/arm64/defconfig/gc… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/arm64/defconfig/gc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c23b01aa7306242f8ace31 failing since 7 days (last pass: v6.1.38, first fail: v6.1.39) 2023-07-27T09:38:01.535193 / # # 2023-07-27T09:38:02.614839 export SHELL=/bin/sh 2023-07-27T09:38:02.616731 # 2023-07-27T09:38:04.104135 / # export SHELL=/bin/sh. /lava-11150061/environment 2023-07-27T09:38:04.105427 2023-07-27T09:38:06.822369 / # . /lava-11150061/environment/lava-11150061/bin/lava-test-runner /lava-11150061/1 2023-07-27T09:38:06.824617 2023-07-27T09:38:06.828077 / # /lava-11150061/bin/lava-test-runner /lava-11150061/1 2023-07-27T09:38:06.892070 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T09:38:06.892223 + cd /lava-111500<8>[ 28.476141] <LAVA_SIGNAL_STARTRUN 1_bootrr 11150061_1.5.2.4.5> ... (39 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ rk3399-gru-kevin | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c23c5e7ee668356c8ace6e Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/arm64/defconfig+ar… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/arm64/defconfig+ar… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c23c5e7ee668356c8ace6f new failure (last pass: v6.1.39) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ sun50i-h6-pine-h64 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23af554b7ffa0598aceab Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/arm64/defconfig/gc… HTML log: https://storage.kernelci.org//stable/linux-6.1.y/v6.1.42/arm64/defconfig/gc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c23af554b7ffa0598aceb0 failing since 7 days (last pass: v6.1.38, first fail: v6.1.39) 2023-07-27T09:39:11.744806 / # # 2023-07-27T09:39:11.846945 export SHELL=/bin/sh 2023-07-27T09:39:11.847635 # 2023-07-27T09:39:11.948983 / # export SHELL=/bin/sh. /lava-11150075/environment 2023-07-27T09:39:11.949745 2023-07-27T09:39:12.051030 / # . /lava-11150075/environment/lava-11150075/bin/lava-test-runner /lava-11150075/1 2023-07-27T09:39:12.051338 2023-07-27T09:39:12.093032 / # /lava-11150075/bin/lava-test-runner /lava-11150075/1 2023-07-27T09:39:12.093145 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T09:39:12.132260 + cd /lava-11150075/1/tests/1_boot<8>[ 16.847524] <LAVA_SIGNAL_STARTRUN 1_bootrr 11150075_1.5.2.4.5> ... (11 line(s) more)

2 years, 3 months

1
0
0 0

stable-rc/linux-5.4.y baseline: 116 runs, 22 regressions (v5.4.251)

by kernelci.org bot

stable-rc/linux-5.4.y baseline: 116 runs, 22 regressions (v5.4.251) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ cubietruck | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 hifive-unleashed-a00 | riscv | lab-baylibre | gcc-10 | defconfig | 1 hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 rk3399-gru-kevin | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 2 Details: https://kernelci.org/test/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.251/… Test: baseline Tree: stable-rc Branch: linux-5.4.y Describe: v5.4.251 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 887433e4bc9394676d22c038dba33a27405f94e8 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ cubietruck | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/64c239074e468729b18ace29 Results: 5 PASS, 1 FAIL, 1 SKIP Full config: multi_v7_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm/multi_v7_d… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm/multi_v7_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c239074e468729b18ace2e failing since 191 days (last pass: v5.4.226-68-g8c05f5e0777d, first fail: v5.4.228-659-gb3b34c474ec7) 2023-07-27T09:29:29.529137 <8>[ 9.868934] <LAVA_SIGNAL_ENDRUN 0_dmesg 3725739_1.5.2.4.1> 2023-07-27T09:29:29.640972 / # # 2023-07-27T09:29:29.743165 export SHELL=/bin/sh 2023-07-27T09:29:29.744480 # 2023-07-27T09:29:29.846688 / # export SHELL=/bin/sh. /lava-3725739/environment 2023-07-27T09:29:29.847596 2023-07-27T09:29:29.949575 / # . /lava-3725739/environment/lava-3725739/bin/lava-test-runner /lava-3725739/1 2023-07-27T09:29:29.950728 2023-07-27T09:29:29.955346 / # /lava-3725739/bin/lava-test-runner /lava-3725739/1 2023-07-27T09:29:30.040285 + export 'TESTRUN_ID=1_bootrr' ... (11 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ hifive-unleashed-a00 | riscv | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c237b05fc446d5c18ace48 Results: 3 PASS, 2 FAIL, 2 SKIP Full config: defconfig Compiler: gcc-10 (riscv64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/riscv/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/riscv/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.dmesg.crit: https://kernelci.org/test/case/id/64c237b05fc446d5c18ace51 failing since 281 days (last pass: v5.4.219, first fail: v5.4.219-267-g4a976f825745) 3 lines 2023-07-27T09:23:36.182707 / # 2023-07-27T09:23:36.190692 2023-07-27T09:23:36.297286 / # # 2023-07-27T09:23:36.302549 # 2023-07-27T09:23:36.421471 / # export SHELL=/bin/sh 2023-07-27T09:23:36.430669 export SHELL=/bin/sh 2023-07-27T09:23:36.533273 / # . /lava-3725712/environment 2023-07-27T09:23:36.542662 . /lava-3725712/environment 2023-07-27T09:23:36.645311 / # /lava-3725712/bin/lava-test-runner /lava-3725712/0 2023-07-27T09:23:36.654355 /lava-3725712/bin/lava-test-runner /lava-3725712/0 ... (10 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2372aadc1fc1ce28ace1c Results: 5 PASS, 1 FAIL, 1 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/x86_64/x86_64_… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/x86_64/x86_64_… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c2372aadc1fc1ce28ace21 failing since 118 days (last pass: v5.4.238, first fail: v5.4.238) 2023-07-27T09:21:46.275617 + set<8>[ 10.672056] <LAVA_SIGNAL_ENDRUN 0_dmesg 11149910_1.4.2.3.1> 2023-07-27T09:21:46.275704 +x 2023-07-27T09:21:46.376872 / # 2023-07-27T09:21:46.477659 # #export SHELL=/bin/sh 2023-07-27T09:21:46.477845 2023-07-27T09:21:46.578341 / # export SHELL=/bin/sh. /lava-11149910/environment 2023-07-27T09:21:46.578551 2023-07-27T09:21:46.679123 / # . /lava-11149910/environment/lava-11149910/bin/lava-test-runner /lava-11149910/1 2023-07-27T09:21:46.679455 2023-07-27T09:21:46.683776 / # /lava-11149910/bin/lava-test-runner /lava-11149910/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2372a801fb1cb9f8ace23 Results: 5 PASS, 1 FAIL, 1 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/x86_64/x86_64_… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/x86_64/x86_64_… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c2372a801fb1cb9f8ace28 failing since 118 days (last pass: v5.4.238, first fail: v5.4.238) 2023-07-27T09:21:41.017133 + set +x 2023-07-27T09:21:41.023820 <8>[ 13.013193] <LAVA_SIGNAL_ENDRUN 0_dmesg 11149931_1.4.2.3.1> 2023-07-27T09:21:41.132496 2023-07-27T09:21:41.234169 / # #export SHELL=/bin/sh 2023-07-27T09:21:41.234860 2023-07-27T09:21:41.336258 / # export SHELL=/bin/sh. /lava-11149931/environment 2023-07-27T09:21:41.337077 2023-07-27T09:21:41.438520 / # . /lava-11149931/environment/lava-11149931/bin/lava-test-runner /lava-11149931/1 2023-07-27T09:21:41.439640 2023-07-27T09:21:41.444485 / # /lava-11149931/bin/lava-test-runner /lava-11149931/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2396694261e57588ace6f Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c2396694261e57588ace70 failing since 357 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.209) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23b1e25ab600a3b8ace29 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c23b1e25ab600a3b8ace2a failing since 337 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.210-390-g1cece69eaa88) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c239274d4118e21d8ace40 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c239274d4118e21d8ace41 failing since 357 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.209) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23978a7edf61a708ace1f Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c23978a7edf61a708ace20 failing since 337 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.210-390-g1cece69eaa88) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2397a94261e57588ace82 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c2397a94261e57588ace83 failing since 359 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.207-123-gb48a8f43dce6) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23b0aaa7306242f8ace7e Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c23b0aaa7306242f8ace7f failing since 359 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.207-123-gb48a8f43dce6) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c239274d4118e21d8ace3b Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c239274d4118e21d8ace3c failing since 359 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.207-123-gb48a8f43dce6) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c2396494261e57588ace6a Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c2396494261e57588ace6b failing since 359 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.207-123-gb48a8f43dce6) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c2395194261e57588ace2f Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c2395194261e57588ace30 failing since 357 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.209) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23af654b7ffa0598aceb6 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c23af654b7ffa0598aceb7 failing since 357 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.209) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c239134e468729b18ace3c Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c239134e468729b18ace3d failing since 357 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.209) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c239638563f2454d8ace3c Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c239638563f2454d8ace3d failing since 357 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.209) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c23a41214ad29eac8ace1c Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c23a41214ad29eac8ace1d failing since 345 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.210-258-ge86027f8111f5) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23baa34023d1e9f8ace21 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c23baa34023d1e9f8ace22 failing since 337 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.210-390-g1cece69eaa88) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c239288563f2454d8ace1d Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c239288563f2454d8ace1e failing since 345 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.210-258-ge86027f8111f5) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c23a68214ad29eac8ace81 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c23a68214ad29eac8ace82 failing since 337 days (last pass: v5.4.180-59-g4f62141869c8, first fail: v5.4.210-390-g1cece69eaa88) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ rk3399-gru-kevin | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 2 Details: https://kernelci.org/test/plan/id/64c2383e34e7310bfa8acedd Results: 82 PASS, 2 FAIL, 1 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.251/arm64/defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.rockchip-usb2phy1-probed: https://kernelci.org/test/case/id/64c2383e34e7310bfa8acee3 failing since 135 days (last pass: v5.4.235, first fail: v5.4.235-4-gb829e8b6e1a7) 2023-07-27T09:26:15.767897 /lava-11149964/1/../bin/lava-test-case 2023-07-27T09:26:15.776798 <8>[ 32.279182] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=rockchip-usb2phy1-probed RESULT=fail> * baseline.bootrr.rockchip-usb2phy0-probed: https://kernelci.org/test/case/id/64c2383e34e7310bfa8acee4 failing since 135 days (last pass: v5.4.235, first fail: v5.4.235-4-gb829e8b6e1a7) 2023-07-27T09:26:14.746228 /lava-11149964/1/../bin/lava-test-case 2023-07-27T09:26:14.754698 <8>[ 31.256931] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=rockchip-usb2phy0-probed RESULT=fail>

2 years, 3 months

1
0
0 0

FAILED: patch "[PATCH] ASoC: cs42l51: fix driver to properly autoload with automatic" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x e51df4f81b02bcdd828a04de7c1eb6a92988b61e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023072306-polyester-reproach-45e3@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: e51df4f81b02 ("ASoC: cs42l51: fix driver to properly autoload with automatic module loading") 4a4043456cb8 ("ASoC: cs*: use simple i2c probe function") f8593e885400 ("ASoC: cs42l42: Handle system suspend") 5982b5a8ec7d ("ASoC: cs42l42: Change jack_detect_mutex to a lock of all IRQ handling") 8d06f797f844 ("ASoC: cs42l42: Report full jack status when plug is detected") a319cb32e7cf ("ASoC: cs4265: Add a remove() function") fdd535283779 ("ASoC: cs42l42: Report initial jack state") c778c01d3e66 ("ASoC: cs42l42: Remove unused runtime_suspend/runtime_resume callbacks") bfceb9c21601 ("Merge branch 'asoc-5.15' into asoc-5.16") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e51df4f81b02bcdd828a04de7c1eb6a92988b61e Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> Date: Thu, 13 Jul 2023 13:21:12 +0200 Subject: [PATCH] ASoC: cs42l51: fix driver to properly autoload with automatic module loading In commit 2cb1e0259f50 ("ASoC: cs42l51: re-hook of_match_table pointer"), 9 years ago, some random guy fixed the cs42l51 after it was split into a core part and an I2C part to properly match based on a Device Tree compatible string. However, the fix in this commit is wrong: the MODULE_DEVICE_TABLE(of, ....) is in the core part of the driver, not the I2C part. Therefore, automatic module loading based on module.alias, based on matching with the DT compatible string, loads the core part of the driver, but not the I2C part. And threfore, the i2c_driver is not registered, and the codec is not known to the system, nor matched with a DT node with the corresponding compatible string. In order to fix that, we move the MODULE_DEVICE_TABLE(of, ...) into the I2C part of the driver. The cs42l51_of_match[] array is also moved as well, as it is not possible to have this definition in one file, and the MODULE_DEVICE_TABLE(of, ...) invocation in another file, due to how MODULE_DEVICE_TABLE works. Thanks to this commit, the I2C part of the driver now properly autoloads, and thanks to its dependency on the core part, the core part gets autoloaded as well, resulting in a functional sound card without having to manually load kernel modules. Fixes: 2cb1e0259f50 ("ASoC: cs42l51: re-hook of_match_table pointer") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> Link: https://lore.kernel.org/r/20230713112112.778576-1-thomas.petazzoni@bootlin.… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/codecs/cs42l51-i2c.c b/sound/soc/codecs/cs42l51-i2c.c index b2106ff6a7cb..e7db7bcd0296 100644 --- a/sound/soc/codecs/cs42l51-i2c.c +++ b/sound/soc/codecs/cs42l51-i2c.c @@ -19,6 +19,12 @@ static struct i2c_device_id cs42l51_i2c_id[] = { }; MODULE_DEVICE_TABLE(i2c, cs42l51_i2c_id); +const struct of_device_id cs42l51_of_match[] = { + { .compatible = "cirrus,cs42l51", }, + { } +}; +MODULE_DEVICE_TABLE(of, cs42l51_of_match); + static int cs42l51_i2c_probe(struct i2c_client *i2c) { struct regmap_config config; diff --git a/sound/soc/codecs/cs42l51.c b/sound/soc/codecs/cs42l51.c index a67cd3ee84e0..a7079ae0ca09 100644 --- a/sound/soc/codecs/cs42l51.c +++ b/sound/soc/codecs/cs42l51.c @@ -823,13 +823,6 @@ int __maybe_unused cs42l51_resume(struct device *dev) } EXPORT_SYMBOL_GPL(cs42l51_resume); -const struct of_device_id cs42l51_of_match[] = { - { .compatible = "cirrus,cs42l51", }, - { } -}; -MODULE_DEVICE_TABLE(of, cs42l51_of_match); -EXPORT_SYMBOL_GPL(cs42l51_of_match); - MODULE_AUTHOR("Arnaud Patard <arnaud.patard(a)rtp-net.org>"); MODULE_DESCRIPTION("Cirrus Logic CS42L51 ALSA SoC Codec Driver"); MODULE_LICENSE("GPL"); diff --git a/sound/soc/codecs/cs42l51.h b/sound/soc/codecs/cs42l51.h index a79343e8a54e..125703ede113 100644 --- a/sound/soc/codecs/cs42l51.h +++ b/sound/soc/codecs/cs42l51.h @@ -16,7 +16,6 @@ int cs42l51_probe(struct device *dev, struct regmap *regmap); void cs42l51_remove(struct device *dev); int __maybe_unused cs42l51_suspend(struct device *dev); int __maybe_unused cs42l51_resume(struct device *dev); -extern const struct of_device_id cs42l51_of_match[]; #define CS42L51_CHIP_ID 0x1B #define CS42L51_CHIP_REV_A 0x00

2 years, 3 months

2
1
0 0

FAILED: patch "[PATCH] ASoC: cs42l51: fix driver to properly autoload with automatic" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x e51df4f81b02bcdd828a04de7c1eb6a92988b61e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023072304-tripping-clean-8cd5@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: e51df4f81b02 ("ASoC: cs42l51: fix driver to properly autoload with automatic module loading") 4a4043456cb8 ("ASoC: cs*: use simple i2c probe function") f8593e885400 ("ASoC: cs42l42: Handle system suspend") 5982b5a8ec7d ("ASoC: cs42l42: Change jack_detect_mutex to a lock of all IRQ handling") 8d06f797f844 ("ASoC: cs42l42: Report full jack status when plug is detected") a319cb32e7cf ("ASoC: cs4265: Add a remove() function") fdd535283779 ("ASoC: cs42l42: Report initial jack state") c778c01d3e66 ("ASoC: cs42l42: Remove unused runtime_suspend/runtime_resume callbacks") bfceb9c21601 ("Merge branch 'asoc-5.15' into asoc-5.16") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e51df4f81b02bcdd828a04de7c1eb6a92988b61e Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> Date: Thu, 13 Jul 2023 13:21:12 +0200 Subject: [PATCH] ASoC: cs42l51: fix driver to properly autoload with automatic module loading In commit 2cb1e0259f50 ("ASoC: cs42l51: re-hook of_match_table pointer"), 9 years ago, some random guy fixed the cs42l51 after it was split into a core part and an I2C part to properly match based on a Device Tree compatible string. However, the fix in this commit is wrong: the MODULE_DEVICE_TABLE(of, ....) is in the core part of the driver, not the I2C part. Therefore, automatic module loading based on module.alias, based on matching with the DT compatible string, loads the core part of the driver, but not the I2C part. And threfore, the i2c_driver is not registered, and the codec is not known to the system, nor matched with a DT node with the corresponding compatible string. In order to fix that, we move the MODULE_DEVICE_TABLE(of, ...) into the I2C part of the driver. The cs42l51_of_match[] array is also moved as well, as it is not possible to have this definition in one file, and the MODULE_DEVICE_TABLE(of, ...) invocation in another file, due to how MODULE_DEVICE_TABLE works. Thanks to this commit, the I2C part of the driver now properly autoloads, and thanks to its dependency on the core part, the core part gets autoloaded as well, resulting in a functional sound card without having to manually load kernel modules. Fixes: 2cb1e0259f50 ("ASoC: cs42l51: re-hook of_match_table pointer") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> Link: https://lore.kernel.org/r/20230713112112.778576-1-thomas.petazzoni@bootlin.… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/codecs/cs42l51-i2c.c b/sound/soc/codecs/cs42l51-i2c.c index b2106ff6a7cb..e7db7bcd0296 100644 --- a/sound/soc/codecs/cs42l51-i2c.c +++ b/sound/soc/codecs/cs42l51-i2c.c @@ -19,6 +19,12 @@ static struct i2c_device_id cs42l51_i2c_id[] = { }; MODULE_DEVICE_TABLE(i2c, cs42l51_i2c_id); +const struct of_device_id cs42l51_of_match[] = { + { .compatible = "cirrus,cs42l51", }, + { } +}; +MODULE_DEVICE_TABLE(of, cs42l51_of_match); + static int cs42l51_i2c_probe(struct i2c_client *i2c) { struct regmap_config config; diff --git a/sound/soc/codecs/cs42l51.c b/sound/soc/codecs/cs42l51.c index a67cd3ee84e0..a7079ae0ca09 100644 --- a/sound/soc/codecs/cs42l51.c +++ b/sound/soc/codecs/cs42l51.c @@ -823,13 +823,6 @@ int __maybe_unused cs42l51_resume(struct device *dev) } EXPORT_SYMBOL_GPL(cs42l51_resume); -const struct of_device_id cs42l51_of_match[] = { - { .compatible = "cirrus,cs42l51", }, - { } -}; -MODULE_DEVICE_TABLE(of, cs42l51_of_match); -EXPORT_SYMBOL_GPL(cs42l51_of_match); - MODULE_AUTHOR("Arnaud Patard <arnaud.patard(a)rtp-net.org>"); MODULE_DESCRIPTION("Cirrus Logic CS42L51 ALSA SoC Codec Driver"); MODULE_LICENSE("GPL"); diff --git a/sound/soc/codecs/cs42l51.h b/sound/soc/codecs/cs42l51.h index a79343e8a54e..125703ede113 100644 --- a/sound/soc/codecs/cs42l51.h +++ b/sound/soc/codecs/cs42l51.h @@ -16,7 +16,6 @@ int cs42l51_probe(struct device *dev, struct regmap *regmap); void cs42l51_remove(struct device *dev); int __maybe_unused cs42l51_suspend(struct device *dev); int __maybe_unused cs42l51_resume(struct device *dev); -extern const struct of_device_id cs42l51_of_match[]; #define CS42L51_CHIP_ID 0x1B #define CS42L51_CHIP_REV_A 0x00

2 years, 3 months

2
1
0 0

FAILED: patch "[PATCH] ASoC: cs42l51: fix driver to properly autoload with automatic" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x e51df4f81b02bcdd828a04de7c1eb6a92988b61e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023072302-prancing-correct-152e@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: e51df4f81b02 ("ASoC: cs42l51: fix driver to properly autoload with automatic module loading") 4a4043456cb8 ("ASoC: cs*: use simple i2c probe function") f8593e885400 ("ASoC: cs42l42: Handle system suspend") 5982b5a8ec7d ("ASoC: cs42l42: Change jack_detect_mutex to a lock of all IRQ handling") 8d06f797f844 ("ASoC: cs42l42: Report full jack status when plug is detected") a319cb32e7cf ("ASoC: cs4265: Add a remove() function") fdd535283779 ("ASoC: cs42l42: Report initial jack state") c778c01d3e66 ("ASoC: cs42l42: Remove unused runtime_suspend/runtime_resume callbacks") bfceb9c21601 ("Merge branch 'asoc-5.15' into asoc-5.16") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e51df4f81b02bcdd828a04de7c1eb6a92988b61e Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> Date: Thu, 13 Jul 2023 13:21:12 +0200 Subject: [PATCH] ASoC: cs42l51: fix driver to properly autoload with automatic module loading In commit 2cb1e0259f50 ("ASoC: cs42l51: re-hook of_match_table pointer"), 9 years ago, some random guy fixed the cs42l51 after it was split into a core part and an I2C part to properly match based on a Device Tree compatible string. However, the fix in this commit is wrong: the MODULE_DEVICE_TABLE(of, ....) is in the core part of the driver, not the I2C part. Therefore, automatic module loading based on module.alias, based on matching with the DT compatible string, loads the core part of the driver, but not the I2C part. And threfore, the i2c_driver is not registered, and the codec is not known to the system, nor matched with a DT node with the corresponding compatible string. In order to fix that, we move the MODULE_DEVICE_TABLE(of, ...) into the I2C part of the driver. The cs42l51_of_match[] array is also moved as well, as it is not possible to have this definition in one file, and the MODULE_DEVICE_TABLE(of, ...) invocation in another file, due to how MODULE_DEVICE_TABLE works. Thanks to this commit, the I2C part of the driver now properly autoloads, and thanks to its dependency on the core part, the core part gets autoloaded as well, resulting in a functional sound card without having to manually load kernel modules. Fixes: 2cb1e0259f50 ("ASoC: cs42l51: re-hook of_match_table pointer") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> Link: https://lore.kernel.org/r/20230713112112.778576-1-thomas.petazzoni@bootlin.… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/codecs/cs42l51-i2c.c b/sound/soc/codecs/cs42l51-i2c.c index b2106ff6a7cb..e7db7bcd0296 100644 --- a/sound/soc/codecs/cs42l51-i2c.c +++ b/sound/soc/codecs/cs42l51-i2c.c @@ -19,6 +19,12 @@ static struct i2c_device_id cs42l51_i2c_id[] = { }; MODULE_DEVICE_TABLE(i2c, cs42l51_i2c_id); +const struct of_device_id cs42l51_of_match[] = { + { .compatible = "cirrus,cs42l51", }, + { } +}; +MODULE_DEVICE_TABLE(of, cs42l51_of_match); + static int cs42l51_i2c_probe(struct i2c_client *i2c) { struct regmap_config config; diff --git a/sound/soc/codecs/cs42l51.c b/sound/soc/codecs/cs42l51.c index a67cd3ee84e0..a7079ae0ca09 100644 --- a/sound/soc/codecs/cs42l51.c +++ b/sound/soc/codecs/cs42l51.c @@ -823,13 +823,6 @@ int __maybe_unused cs42l51_resume(struct device *dev) } EXPORT_SYMBOL_GPL(cs42l51_resume); -const struct of_device_id cs42l51_of_match[] = { - { .compatible = "cirrus,cs42l51", }, - { } -}; -MODULE_DEVICE_TABLE(of, cs42l51_of_match); -EXPORT_SYMBOL_GPL(cs42l51_of_match); - MODULE_AUTHOR("Arnaud Patard <arnaud.patard(a)rtp-net.org>"); MODULE_DESCRIPTION("Cirrus Logic CS42L51 ALSA SoC Codec Driver"); MODULE_LICENSE("GPL"); diff --git a/sound/soc/codecs/cs42l51.h b/sound/soc/codecs/cs42l51.h index a79343e8a54e..125703ede113 100644 --- a/sound/soc/codecs/cs42l51.h +++ b/sound/soc/codecs/cs42l51.h @@ -16,7 +16,6 @@ int cs42l51_probe(struct device *dev, struct regmap *regmap); void cs42l51_remove(struct device *dev); int __maybe_unused cs42l51_suspend(struct device *dev); int __maybe_unused cs42l51_resume(struct device *dev); -extern const struct of_device_id cs42l51_of_match[]; #define CS42L51_CHIP_ID 0x1B #define CS42L51_CHIP_REV_A 0x00

2 years, 3 months

2
1
0 0

stable-rc/linux-6.1.y baseline: 98 runs, 10 regressions (v6.1.42)

by kernelci.org bot

stable-rc/linux-6.1.y baseline: 98 runs, 10 regressions (v6.1.42) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ acer-chromebox-cxi4-puff | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 asus-C436FA-Flip-hatch | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 asus-CM1400CXA-dalboz | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 asus-cx9400-volteer | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 hp-x360-14a-cb0001xx-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 lenovo-TPad-C13-Yoga-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 r8a779m1-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 sun50i-h6-pine-h64 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-6.1.y/kernel/v6.1.42/p… Test: baseline Tree: stable-rc Branch: linux-6.1.y Describe: v6.1.42 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: d2a6dc4eaf6d50ba32a9b39b4c6ec713a92072ab Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ acer-chromebox-cxi4-puff | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c22d183de8e17bb88ace71 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… HTML log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c22d183de8e17bb88ace72 new failure (last pass: v6.1.41-184-gb3f8a9d2b1371) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ asus-C436FA-Flip-hatch | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c22c218008fbf5bb8ace52 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… HTML log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c22c228008fbf5bb8ace57 failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T08:34:54.045022 + set +x 2023-07-27T08:34:54.051744 <8>[ 11.104802] <LAVA_SIGNAL_ENDRUN 0_dmesg 11149670_1.4.2.3.1> 2023-07-27T08:34:54.153372 # 2023-07-27T08:34:54.153599 2023-07-27T08:34:54.254119 / # #export SHELL=/bin/sh 2023-07-27T08:34:54.254297 2023-07-27T08:34:54.354752 / # export SHELL=/bin/sh. /lava-11149670/environment 2023-07-27T08:34:54.354917 2023-07-27T08:34:54.455387 / # . /lava-11149670/environment/lava-11149670/bin/lava-test-runner /lava-11149670/1 2023-07-27T08:34:54.455647 ... (13 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ asus-CM1400CXA-dalboz | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c22c1001d34675478ace41 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… HTML log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c22c1001d34675478ace46 failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T08:34:16.326058 + set<8>[ 11.586353] <LAVA_SIGNAL_ENDRUN 0_dmesg 11149662_1.4.2.3.1> 2023-07-27T08:34:16.326141 +x 2023-07-27T08:34:16.430377 / # # 2023-07-27T08:34:16.531111 export SHELL=/bin/sh 2023-07-27T08:34:16.531339 # 2023-07-27T08:34:16.631907 / # export SHELL=/bin/sh. /lava-11149662/environment 2023-07-27T08:34:16.632161 2023-07-27T08:34:16.732721 / # . /lava-11149662/environment/lava-11149662/bin/lava-test-runner /lava-11149662/1 2023-07-27T08:34:16.733053 2023-07-27T08:34:16.737374 / # /lava-11149662/bin/lava-test-runner /lava-11149662/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ asus-cx9400-volteer | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c22c1c01d34675478ace4e Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… HTML log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c22c1c01d34675478ace53 failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T08:34:21.156885 <8>[ 10.117462] <LAVA_SIGNAL_ENDRUN 0_dmesg 11149663_1.4.2.3.1> 2023-07-27T08:34:21.160266 + set +x 2023-07-27T08:34:21.265563 # 2023-07-27T08:34:21.266862 2023-07-27T08:34:21.368763 / # #export SHELL=/bin/sh 2023-07-27T08:34:21.369567 2023-07-27T08:34:21.471164 / # export SHELL=/bin/sh. /lava-11149663/environment 2023-07-27T08:34:21.472196 2023-07-27T08:34:21.574153 / # . /lava-11149663/environment/lava-11149663/bin/lava-test-runner /lava-11149663/1 2023-07-27T08:34:21.575672 ... (13 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c22c10fb90f50be18ace36 Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… HTML log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c22c10fb90f50be18ace3b failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T08:34:40.935723 + set +x 2023-07-27T08:34:40.942310 <8>[ 10.760524] <LAVA_SIGNAL_ENDRUN 0_dmesg 11149690_1.4.2.3.1> 2023-07-27T08:34:41.046240 / # # 2023-07-27T08:34:41.146789 export SHELL=/bin/sh 2023-07-27T08:34:41.146963 # 2023-07-27T08:34:41.247476 / # export SHELL=/bin/sh. /lava-11149690/environment 2023-07-27T08:34:41.247687 2023-07-27T08:34:41.348240 / # . /lava-11149690/environment/lava-11149690/bin/lava-test-runner /lava-11149690/1 2023-07-27T08:34:41.348713 2023-07-27T08:34:41.353710 / # /lava-11149690/bin/lava-test-runner /lava-11149690/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c22d203de8e17bb88ace76 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… HTML log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.login: https://kernelci.org/test/case/id/64c22d203de8e17bb88ace77 new failure (last pass: v6.1.41-184-gb3f8a9d2b1371) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ hp-x360-14a-cb0001xx-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c22c08fb90f50be18ace1c Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… HTML log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c22c08fb90f50be18ace21 failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T08:34:02.018442 + <8>[ 11.320112] <LAVA_SIGNAL_ENDRUN 0_dmesg 11149652_1.4.2.3.1> 2023-07-27T08:34:02.018941 set +x 2023-07-27T08:34:02.125985 / # # 2023-07-27T08:34:02.228484 export SHELL=/bin/sh 2023-07-27T08:34:02.229248 # 2023-07-27T08:34:02.330803 / # export SHELL=/bin/sh. /lava-11149652/environment 2023-07-27T08:34:02.331608 2023-07-27T08:34:02.433143 / # . /lava-11149652/environment/lava-11149652/bin/lava-test-runner /lava-11149652/1 2023-07-27T08:34:02.434345 2023-07-27T08:34:02.439659 / # /lava-11149652/bin/lava-test-runner /lava-11149652/1 ... (12 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ lenovo-TPad-C13-Yoga-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1 Details: https://kernelci.org/test/plan/id/64c22bff5d0167e5bf8ace9a Results: 6 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig+x86-chromebook Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… HTML log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/x86_64/x86_64_d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c22bff5d0167e5bf8ace9f failing since 118 days (last pass: v6.1.21, first fail: v6.1.22) 2023-07-27T08:34:02.373802 <8>[ 11.904667] <LAVA_SIGNAL_ENDRUN 0_dmesg 11149666_1.4.2.3.1> 2023-07-27T08:34:02.481537 / # # 2023-07-27T08:34:02.583937 export SHELL=/bin/sh 2023-07-27T08:34:02.584719 # 2023-07-27T08:34:02.686346 / # export SHELL=/bin/sh. /lava-11149666/environment 2023-07-27T08:34:02.687126 2023-07-27T08:34:02.788765 / # . /lava-11149666/environment/lava-11149666/bin/lava-test-runner /lava-11149666/1 2023-07-27T08:34:02.790035 2023-07-27T08:34:02.795230 / # /lava-11149666/bin/lava-test-runner /lava-11149666/1 2023-07-27T08:34:02.801928 + export 'TESTRUN_ID=1_bootrr' ... (11 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ r8a779m1-ulcb | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c22ea78c4bbd313b8acf4f Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/arm64/defconfig… HTML log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/arm64/defconfig… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c22ea78c4bbd313b8acf54 failing since 9 days (last pass: v6.1.38-393-gb6386e7314b4, first fail: v6.1.38-590-gce7ec1011187) 2023-07-27T08:45:30.828077 / # # 2023-07-27T08:45:31.904225 export SHELL=/bin/sh 2023-07-27T08:45:31.905518 # 2023-07-27T08:45:33.388158 / # export SHELL=/bin/sh. /lava-11149735/environment 2023-07-27T08:45:33.389844 2023-07-27T08:45:36.107341 / # . /lava-11149735/environment/lava-11149735/bin/lava-test-runner /lava-11149735/1 2023-07-27T08:45:36.109467 2023-07-27T08:45:36.121110 / # /lava-11149735/bin/lava-test-runner /lava-11149735/1 2023-07-27T08:45:36.180192 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T08:45:36.180690 + cd /lava-111497<8>[ 28.433906] <LAVA_SIGNAL_STARTRUN 1_bootrr 11149735_1.5.2.4.5> ... (38 line(s) more) platform | arch | lab | compiler | defconfig | regressions -----------------------------+--------+---------------+----------+------------------------------+------------ sun50i-h6-pine-h64 | arm64 | lab-collabora | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/64c22e818c4bbd313b8ace40 Results: 5 PASS, 1 FAIL, 1 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/arm64/defconfig… HTML log: https://storage.kernelci.org//stable-rc/linux-6.1.y/v6.1.42/arm64/defconfig… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2023… * baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64c22e818c4bbd313b8ace45 failing since 9 days (last pass: v6.1.38-393-gb6386e7314b4, first fail: v6.1.38-590-gce7ec1011187) 2023-07-27T08:46:19.483659 / # # 2023-07-27T08:46:19.585823 export SHELL=/bin/sh 2023-07-27T08:46:19.586494 # 2023-07-27T08:46:19.687539 / # export SHELL=/bin/sh. /lava-11149727/environment 2023-07-27T08:46:19.688138 2023-07-27T08:46:19.789297 / # . /lava-11149727/environment/lava-11149727/bin/lava-test-runner /lava-11149727/1 2023-07-27T08:46:19.790136 2023-07-27T08:46:19.791702 / # /lava-11149727/bin/lava-test-runner /lava-11149727/1 2023-07-27T08:46:19.873823 + export 'TESTRUN_ID=1_bootrr' 2023-07-27T08:46:19.874275 + cd /lava-1114972<8>[ 16.977056] <LAVA_SIGNAL_STARTRUN 1_bootrr 11149727_1.5.2.4.5> ... (11 line(s) more)

2 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror