linux-kernel - Re: [PATCH V7 02/11] sched: Indicate if thread got rescheduled

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] [day] [month] [year] [list]

Message-ID: <402952DE-F930-4F03-8482-E39025A6222D@oracle.com>
Date: Thu, 14 Aug 2025 07:18:02 +0000
From: Prakash Sangappa <prakash.sangappa@...cle.com>
To: Thomas Gleixner <tglx@...utronix.de>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "rostedt@...dmis.org"
	<rostedt@...dmis.org>,
        "mathieu.desnoyers@...icios.com"
	<mathieu.desnoyers@...icios.com>,
        "bigeasy@...utronix.de"
	<bigeasy@...utronix.de>,
        "kprateek.nayak@....com" <kprateek.nayak@....com>,
        "vineethr@...ux.ibm.com" <vineethr@...ux.ibm.com>
Subject: Re: [PATCH V7 02/11] sched: Indicate if thread got rescheduled



> On Aug 11, 2025, at 2:45 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> On Thu, Aug 07 2025 at 16:15, Prakash Sangappa wrote:
>>> On Aug 7, 2025, at 6:06 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>>> rseq_preempt() sets RSEQ_EVENT_PREEMPT_BIT and TIF_NOTIFY_RESUME, which
>>> causes exit to userspace to invoke __rseq_handle_notify_resume(). That's
>>> the obvious place to handle this instead of inflicting it into the
>>> scheduler hotpath.
>>> 
>>> No?
>> 
>> Sure, I will look at moving rseq_delay_resched_clear() call to __rseq_handle_notify_resume().
> 
> I looked deeper into it and it does not completely solve the problem.

Thanks for taking a deeper look.

> 
> +bool rseq_syscall_enter_work(long syscall)
> +{
> + struct task_struct *curr = current;
> + unsigned int slext = curr->rseq_slice_extension;
> +
> + clear_task_syscall_work(curr, SYSCALL_RSEQ_SLICE);
> + curr->rseq_slice_extension = RSEQ_SLICE_EXTENSION_ENABLED;
> +
> + /*
> + * Kernel internal state inconsistency. SYSCALL_RSEQ_SLICE can only
> + * be set when state is GRANTED!
> + */
> + if (WARN_ON_ONCE(slext != RSEQ_SLICE_EXTENSION_GRANTED))
> + return false;
> +
> + set_tsk_need_resched(curr);
> +
> + if (unlikely(!__rseq_reset_slice_extension(curr) || syscall != __NR_sched_yield))
> + force_sigsegv(0);
> +
> + /* Abort syscall to reschedule immediately */
> + return true;
> +}

Is it ok to fail the sched_yield(2) syscall? The man page says
sched_yield(2) always succeeds(returns 0).

Also, is it necessary to force kill the process here with SIGSEGV, if some other 
system call was made?

Ideally it would be expected that the process should not be making any system call 
while in the critical section and is using time slice extension, other then sched_yield(2) 
to relinquish the cpu. However an application process could have a signal handler 
that gets invoked while in the critical section which can potentially be making some 
system call that is not sched_yield(2).

Thanks,
-Prakash