[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240705054132.108523-1-peilinhe2020@163.com>
Date: Fri, 5 Jul 2024 05:41:32 +0000
From: Peilin He <peilinhe2020@....com>
To: peterz@...radead.org
Cc: bsegall@...gle.com,
dietmar.eggemann@....com,
fan.yu9@....com.cn,
he.peilin@....com.cn,
jiang.kun2@....com.cn,
juri.lelli@...hat.com,
linux-kernel@...r.kernel.org,
liu.chun2@....com.cn,
mgorman@...e.de,
mingo@...hat.com,
rostedt@...dmis.org,
tu.qiang35@....com.cn,
vincent.guittot@...aro.org,
xu.xin16@....com.cn,
yang.yang29@....com.cn,
zhang.yunkai@....com.cn
Subject: Re: Re: [PATCH linux-next v2] sched/core: Add WARN() to check overflow in migrate_disable()
> How about we do something like this?
>
> ---
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 7a5ea8fc8abb..06a559532ed6 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2237,6 +2237,12 @@ void migrate_disable(void)
>
> if (p->migration_disabled) {
> p->migration_disabled++;
> +#ifdef CONFIG_DEBUG_PREEMPT
> + /*
> + * Warn about overflow half-way through the range.
> + */
> + WARN_ON_ONCE((s16)p->migration_disabled < 0);
> +#endif
> return;
> }
Agreed, converting p->migration_disabled to a signed number
will detect overflow occurrences earlier than our current method.
> @@ -2254,14 +2260,20 @@ void migrate_enable(void)
> .flags = SCA_MIGRATE_ENABLE,
> };
>
> +#ifdef CONFIG_DEBUG_PREEMPT
> + /*
> + * Check both overflow from migrate_disable() and superfluous
> + * migrate_enable().
> + */
> + if (WARN_ON_ONCE((s16)p->migration_disabled <= 0))
> + return;
> +#endif
> +
> if (p->migration_disabled > 1) {
> p->migration_disabled--;
> return;
> }
>
> - if (WARN_ON_ONCE(!p->migration_disabled))
> - return;
> -
> /*
> * Ensure stop_task runs either before or after this, and that
> * __set_cpus_allowed_ptr(SCA_MIGRATE_ENABLE) doesn't schedule().
Agreed, similarly checking for overflow in p->migration_disabled
within migrate_enable is fine, but placing WARN_ON_ONCE inside
the CONFIG_DEBUG_PREEMPT macro may cause return logic deviations.
It is recommended to support WARN_ON_ONCE as a standard feature.
The fix will be reflected in version v3.
Powered by blists - more mailing lists