Dear All,

On 14.03.2024 09:39, Catalin Marinas wrote:

On Wed, Mar 13, 2024 at 05:13:33PM +0000, Russell King wrote:

quoted

So, I wonder whether what you're seeing is a latent bug which is
being tickled by the presence of the CPU masks being off-stack
changing the kernel timing.

I would suggest the printk debug approach may help here to see when
the OPPs are begun to be parsed, when they're created etc and their
timing relationship to being used. Given the suspicion, it's possible
that the mere addition of printk() may "fix" the problem, which again
would be another semi-useful data point.

It might be an init order problem. Passing "initcall_debug" on the
cmdline might help a bit.

It would also be useful in dev_pm_opp_set_config(), in the WARN_ON
block, to print opp_table->opp_list.next to get an idea whether it looks
like a valid pointer or memory corruption.

I've finally found some time to do the step-by-step printk-based 
debugging of this issue and finally found what's broken!

Here is the fix:

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 8bd6e5e8f121..2d83bbc65dd0 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c

@@ -208,7 +208,7 @@ static int dt_cpufreq_early_init(struct device *dev, 

int cpu)
         if (!priv)
                 return -ENOMEM;

-       if (!alloc_cpumask_var(&priv->cpus, GFP_KERNEL))
+       if (!zalloc_cpumask_var(&priv->cpus, GFP_KERNEL))
                 return -ENOMEM;

         cpumask_set_cpu(cpu, priv->cpus);


It is really surprising that this didn't blow up for anyone else so 
far... This means that the $subject patch is fine.

I will send a proper patch fixing this issue in a few minutes.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel