linux-kernel - Re: [PATCH sched_ext/for-6.14-fixes] sched_ext: Fix incorrect assumption about migration disabled tasks in task_can_run_on_remote

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z6pdwM6upNhMUFRU@gpd3>
Date: Mon, 10 Feb 2025 21:12:48 +0100
From: Andrea Righi <arighi@...dia.com>
To: Tejun Heo <tj@...nel.org>
Cc: David Vernet <void@...ifault.com>, Changwoo Min <changwoo@...lia.com>,
	linux-kernel@...r.kernel.org, sched-ext@...a.com,
	Jake Hillion <jakehillion@...a.com>
Subject: Re: [PATCH sched_ext/for-6.14-fixes] sched_ext: Fix incorrect
 assumption about migration disabled tasks in task_can_run_on_remote_rq()

On Mon, Feb 10, 2025 at 09:27:09AM -1000, Tejun Heo wrote:
> While fixing migration disabled task handling, 32966821574c ("sched_ext: Fix
> migration disabled handling in targeted dispatches") assumed that a
> migration disabled task's ->cpus_ptr would only have the pinned CPU. While
> this is eventually true for migration disabled tasks that are switched out,
> ->cpus_ptr update is performed by migrate_disable_switch() which is called
> right before context_switch() in __scheduler(). However, the task is
> enqueued earlier during pick_next_task() via put_prev_task_scx(), so there
> is a race window where another CPU can see the task on a DSQ.
> 
> If the CPU tries to dispatch the migration disabled task while in that
> window, task_allowed_on_cpu() will succeed and task_can_run_on_remote_rq()
> will subsequently trigger SCHED_WARN(is_migration_disabled()).
> 
>   WARNING: CPU: 8 PID: 1837 at kernel/sched/ext.c:2466 task_can_run_on_remote_rq+0x12e/0x140
>   Sched_ext: layered (enabled+all), task: runnable_at=-10ms
>   RIP: 0010:task_can_run_on_remote_rq+0x12e/0x140
>   ...
>    <TASK>
>    consume_dispatch_q+0xab/0x220
>    scx_bpf_dsq_move_to_local+0x58/0xd0
>    bpf_prog_84dd17b0654b6cf0_layered_dispatch+0x290/0x1cfa
>    bpf__sched_ext_ops_dispatch+0x4b/0xab
>    balance_one+0x1fe/0x3b0
>    balance_scx+0x61/0x1d0
>    prev_balance+0x46/0xc0
>    __pick_next_task+0x73/0x1c0
>    __schedule+0x206/0x1730
>    schedule+0x3a/0x160
>    __do_sys_sched_yield+0xe/0x20
>    do_syscall_64+0xbb/0x1e0
>    entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> Fix it by converting the SCHED_WARN() back to a regular failure path. Also,
> perform the migration disabled test before task_allowed_on_cpu() test so
> that BPF schedulers which fail to handle migration disabled tasks can be
> noticed easily.
> 
> While at it, adjust scx_ops_error() message for !task_allowed_on_cpu() case
> for brevity and consistency.
> 
> Signed-off-by: Tejun Heo <tj@...nel.org>
> Fixes: 32966821574c ("sched_ext: Fix migration disabled handling in targeted dispatches")
> Reported-by: Jake Hillion <jakehillion@...a.com>

Makes sense to me.

Acked-by: Andrea Righi <arighi@...dia.com>

Thanks,
-Andrea