linux-kernel - Re: [RFC PATCH 6/9] sched: Treat try_to_block

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: <20250416092027.yShf-ReN@linutronix.de>
Date: Wed, 16 Apr 2025 11:20:27 +0200
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Tomas Glozar <tglozar@...hat.com>, Juri Lelli <jlelli@...hat.com>
Subject: Re: [RFC PATCH 6/9] sched: Treat try_to_block_task with pending
 signal as wakeup

On Fri, Apr 04, 2025 at 10:45:19AM +0200, Gabriele Monaco wrote:
> If a task sets itself to interruptible and schedules, the __schedule
> function checks whether there's a pending signal and, if that's the
> case, updates the state of the task to runnable instead of dequeuing.
> By looking at the tracepoints, we see the task enters the scheduler
> while sleepable but exits as runnable. From a modelling perspective,
> this is equivalent to a wakeup and the tracepoints should reflect that.
> 
> Add the waking/wakeup tracepoints in the try_to_block_task function and
> set the prev_state used by the sched_switch tracepoint to TASK_RUNNING
> if the task had a pending signal and was not blocked.
> 
> Signed-off-by: Gabriele Monaco <gmonaco@...hat.com>
> ---
>  kernel/sched/core.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index f2f79236d5811..48cb32abce01a 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6584,7 +6584,12 @@ static bool try_to_block_task(struct rq *rq, struct task_struct *p,
>  	int flags = DEQUEUE_NOCLOCK;
>  
>  	if (signal_pending_state(task_state, p)) {
> -		WRITE_ONCE(p->__state, TASK_RUNNING);
> +		/*
> +		 * From a modelling perspective, this is equivalent to a wakeup
> +		 * before dequeuing the task: trace accordingly.
> +		 */
> +		trace_sched_waking(p);
> +		ttwu_do_wakeup(p);
>  		return false;
>  	}
>  
> @@ -6721,7 +6726,9 @@ static void __sched notrace __schedule(int sched_mode)
>  			goto picked;
>  		}
>  	} else if (!preempt && prev_state) {
> -		try_to_block_task(rq, prev, prev_state);
> +		/* Task was not blocked due to a signal and is again runnable */
> +		if (!try_to_block_task(rq, prev, prev_state))
> +			prev_state = TASK_RUNNING;
>  		switch_count = &prev->nvcsw;
>  	}

I couldn't reproduce the problem that this patch is solving. But staring at
the srs monitor, I made an educated guess that this is to accomodate the
transition "sleepable x wakeup -> running"?

But for this transition, no real wakeup happens, just the task's state is
changed to "sleepable" then back to "running", right? Sleep hasn't actually
happened yet?

If that is the case, would the patch below also solves it? It would turn
the transition into "sleepable x set_runnable -> running", which I think
describe it more accurately.

Best regards,
Nam

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9a14d792a681..e39b4aadeba2 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6592,6 +6592,7 @@ static bool try_to_block_task(struct rq *rq, struct task_struct *p,
 	int flags = DEQUEUE_NOCLOCK;
 
 	if (signal_pending_state(task_state, p)) {
+		trace_sched_set_state_tp(p, TASK_RUNNING);
 		WRITE_ONCE(p->__state, TASK_RUNNING);
 		return false;
 	}