[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <820b04a1-8c2f-ba81-f508-5750c63f3239@redhat.com>
Date: Fri, 3 Feb 2023 17:13:02 -0500
From: Waiman Long <longman@...hat.com>
To: Tejun Heo <tj@...nel.org>
Cc: Ingo Molnar <mingo@...hat.com>,
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>,
Valentin Schneider <vschneid@...hat.com>,
Will Deacon <will@...nel.org>, Phil Auld <pauld@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/core: Fix a missed update of user_cpus_ptr
On 2/3/23 16:04, Tejun Heo wrote:
> On Fri, Feb 03, 2023 at 01:18:49PM -0500, Waiman Long wrote:
>> Since commit 8f9ea86fdf99 ("sched: Always preserve the user requested
>> cpumask"), a successful call to sched_setaffinity() should always save
>> the user requested cpu affinity mask in a task's user_cpus_ptr. However,
>> when the given cpu mask is the same as the current one, user_cpus_ptr
>> is not updated. Fix this by saving the user mask in this case too.
>>
>> Fixes: 8f9ea86fdf99 ("sched: Always preserve the user requested cpumask")
>> Signed-off-by: Waiman Long <longman@...hat.com>
>> ---
>> kernel/sched/core.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 30d9752e2ca5..91255f791df3 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -2951,8 +2951,11 @@ static int __set_cpus_allowed_ptr_locked(struct task_struct *p,
>> }
>>
>> if (!(ctx->flags & SCA_MIGRATE_ENABLE)) {
>> - if (cpumask_equal(&p->cpus_mask, ctx->new_mask))
>> + if (cpumask_equal(&p->cpus_mask, ctx->new_mask)) {
>> + if (ctx->flags & SCA_USER)
>> + swap(p->user_cpus_ptr, ctx->user_mask);
>> goto out;
>> + }
>>
>> if (WARN_ON_ONCE(p == current &&
>> is_migration_disabled(p) &&
> and this is for a separate bug and should go through the scheduler tree.
Yes, this is for Peter to pick up.
Cheers,
Longman
Powered by blists - more mailing lists