From: Thomas Gleixner <tglx@linutronix.de>
To: Prakash Sangappa <prakash.sangappa@oracle.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"mathieu.desnoyers@efficios.com" <mathieu.desnoyers@efficios.com>,
"bigeasy@linutronix.de" <bigeasy@linutronix.de>,
"kprateek.nayak@amd.com" <kprateek.nayak@amd.com>,
"vineethr@linux.ibm.com" <vineethr@linux.ibm.com>
Subject: Re: [PATCH V7 02/11] sched: Indicate if thread got rescheduled
Date: Thu, 14 Aug 2025 20:20:50 +0200 [thread overview]
Message-ID: <871ppd7ojh.ffs@tglx> (raw)
In-Reply-To: <402952DE-F930-4F03-8482-E39025A6222D@oracle.com>
On Thu, Aug 14 2025 at 07:18, Prakash Sangappa wrote:
>> On Aug 11, 2025, at 2:45 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> Is it ok to fail the sched_yield(2) syscall? The man page says
> sched_yield(2) always succeeds(returns 0).
I used it because it's simple. In practice we need a new syscall w/o
side effects.
> Also, is it necessary to force kill the process here with SIGSEGV, if
> some other system call was made?
Yes, because we do not trust user space and any violation of the
contract has consequences. Any kernel facility which interacts in such a
way with user space has to be defensive by design. Assuming that user
space is neither stupid nor malicious is naive at best and has been a
source of big gaping holes forever.
> 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).
The timeslice extension is canceled when a signal is pending, so nothing
bad happens. The kernel already revoked it similar to how rseq aborts
the critical section on signal delivery.
If it doesn't work with the POC, that may be. With the stuff I'm
polishing now it works because I tested it :)
Thanks
tglx
next prev parent reply other threads:[~2025-08-14 18:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-24 16:16 [PATCH V7 00/11] Scheduler time slice extension Prakash Sangappa
2025-07-24 16:16 ` [PATCH V7 01/11] sched: " Prakash Sangappa
2025-08-06 20:34 ` Thomas Gleixner
2025-08-07 14:07 ` Thomas Gleixner
2025-08-07 16:45 ` Prakash Sangappa
2025-08-07 15:49 ` Sebastian Andrzej Siewior
2025-08-07 16:56 ` Prakash Sangappa
2025-08-08 9:59 ` Sebastian Andrzej Siewior
2025-08-08 17:00 ` Prakash Sangappa
2025-08-11 6:28 ` Sebastian Andrzej Siewior
2025-08-07 16:13 ` Prakash Sangappa
2025-07-24 16:16 ` [PATCH V7 02/11] sched: Indicate if thread got rescheduled Prakash Sangappa
2025-08-07 13:06 ` Thomas Gleixner
2025-08-07 16:15 ` Prakash Sangappa
2025-08-11 9:45 ` Thomas Gleixner
2025-08-13 16:19 ` bigeasy
2025-08-13 16:56 ` Thomas Gleixner
2025-08-18 13:16 ` bigeasy
2025-08-19 8:12 ` Thomas Gleixner
2025-08-14 7:18 ` Prakash Sangappa
2025-08-14 18:20 ` Thomas Gleixner [this message]
2025-07-24 16:16 ` [PATCH V7 03/11] sched: Tunable to specify duration of time slice extension Prakash Sangappa
2025-07-24 16:16 ` [PATCH V7 04/11] sched: Add scheduler stat for cpu " Prakash Sangappa
2025-07-24 16:16 ` [PATCH V7 05/11] sched: Add tracepoint for sched " Prakash Sangappa
2025-07-24 16:16 ` [PATCH V7 06/11] Add API to query supported rseq cs flags Prakash Sangappa
2025-07-24 16:16 ` [PATCH V7 07/11] sched: Add API to indicate not to delay scheduling Prakash Sangappa
2025-07-25 14:30 ` kernel test robot
2025-07-24 16:16 ` [PATCH V7 08/11] sched: Add TIF_NEED_RESCHED_NODELAY infrastructure Prakash Sangappa
2025-07-24 16:16 ` [PATCH V7 09/11] sched: Add nodelay scheduling Prakash Sangappa
2025-08-08 13:26 ` Thomas Gleixner
2025-08-08 16:54 ` Prakash Sangappa
2025-07-24 16:16 ` [PATCH V7 10/11] sched, x86: Enable " Prakash Sangappa
2025-07-24 16:16 ` [PATCH V7 11/11] sched: Add kernel parameter to enable delaying RT threads Prakash Sangappa
2025-07-25 15:52 ` kernel test robot
2025-08-06 16:03 ` [PATCH V7 00/11] Scheduler time slice extension Prakash Sangappa
2025-08-06 16:24 ` Thomas Gleixner
2025-08-06 16:30 ` Thomas Gleixner
2025-08-07 6:52 ` Prakash Sangappa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871ppd7ojh.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=peterz@infradead.org \
--cc=prakash.sangappa@oracle.com \
--cc=rostedt@goodmis.org \
--cc=vineethr@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox