[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <xhsmhle6kdbmd.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
Date: Thu, 14 Mar 2024 17:25:14 +0100
From: Valentin Schneider <vschneid@...hat.com>
To: Daniil Dulov <d.dulov@...ddin.ru>, Ingo Molnar <mingo@...hat.com>
Cc: Daniil Dulov <d.dulov@...ddin.ru>, Peter Zijlstra
<peterz@...radead.org>, Juri Lelli <juri.lelli@...hat.com>, Vincent
Guittot <vincent.guittot@...aro.org>, Dietmar Eggemann
<dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, Ben
Segall <bsegall@...gle.com>, Mel
Gorman <mgorman@...e.de>, Daniel Bristot de Oliveira <bristot@...hat.com>,
linux-kernel@...r.kernel.org, lvc-project@...uxtesting.org
Subject: Re: [PATCH] sched/topology: Check return value of zalloc_cpumask_var()
On 07/03/24 16:23, Daniil Dulov wrote:
> zalloc_cpumask_var() returns false if mask was not allocated.
> So, let's check if cpu masks are allocated successfully.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: 8d5dc5126bb2 ("sched/topology: Small cleanup")
> Signed-off-by: Daniil Dulov <d.dulov@...ddin.ru>
> ---
> kernel/sched/topology.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index 10d1391e7416..2df98ffdfe16 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -2600,9 +2600,10 @@ int __init sched_init_domains(const struct cpumask *cpu_map)
> {
> int err;
>
> - zalloc_cpumask_var(&sched_domains_tmpmask, GFP_KERNEL);
> - zalloc_cpumask_var(&sched_domains_tmpmask2, GFP_KERNEL);
> - zalloc_cpumask_var(&fallback_doms, GFP_KERNEL);
> + if (!zalloc_cpumask_var(&sched_domains_tmpmask, GFP_KERNEL) ||
> + !zalloc_cpumask_var(&sched_domains_tmpmask2, GFP_KERNEL) ||
> + !zalloc_cpumask_var(&fallback_doms, GFP_KERNEL))
> + return -ENOMEM;
Despite returning an int, sched_init_domains()' return value is ignored by
sched_init_smp()
The int return was added in 2006 by:
51888ca25a03 ("[PATCH] sched_domain: handle kmalloc failure")
but it looks like sched_init_smp() never checked it.
Now, allocation failures this early in init really isn't good and more
things are bound to explode, but I suppose you could add a return value
check in sched_init_smp() and WARN on anything non-zero. Without
sched_domain's, we'll still have the boot CPU doing useful work.
>
> arch_update_cpu_topology();
> asym_cpu_capacity_scan();
> --
> 2.25.1
Powered by blists - more mailing lists