Re: [patch V3 10/12] rseq: Implement rseq_grant_slice_extension()

[Thomas Gleixner <tglx@linutronix.de>]

On Wed, Oct 29 2025 at 16:08, Steven Rostedt wrote:
> On Wed, 29 Oct 2025 14:22:30 +0100 (CET)
> Thomas Gleixner <tglx@linutronix.de> wrote:
>> +		/*
>> +		 * Quick check conditions where a grant is not possible or
>> +		 * needs to be revoked.
>> +		 *
>> +		 *  1) Any TIF bit which needs to do extra work aside of
>> +		 *     rescheduling prevents a grant.
>> +		 *
>
> I'm curious to why any other TIF bit causes this to refuse a grant?
>
> If deferred unwinding gets implemented, and profiling is enabled, it uses
> task_work. From my understanding, task_work will set a TIF bit. Would this
> mean that we would not be able to profile this feature with the deferred
> unwinder? As profiling it will prevent it from being used?

You still can use it. The point is that a set TIF bit will do extra
work, which means extra scheduling latency. The extra work might be
short enough to still make the grant useful, but that's something which
needs to be worked out and analyzed. Quite some of the TIF bits actually
end up with another reschedule request.

As this whole thing is an opportunistic poor mans priority ceiling
attempt, I opted for the simple decision of not granting it when other
TIF bits are set. KISS rules :)

That's not set in stone and has no user space ABI relevance because it's
solely a kernel implementation detail.

> -- Steve

Can you please trim your replies as anybody else does?

Thanks,

        tglx