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

[Steven Rostedt]

On Wed, 29 Oct 2025 14:22:30 +0100 (CET)
Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:

> +static __always_inline bool rseq_grant_slice_extension(bool work_pending)
> +{
> +	struct task_struct *curr = current;
> +	struct rseq_slice_ctrl usr_ctrl;
> +	union rseq_slice_state state;
> +	struct rseq __user *rseq;
> +
> +	if (!rseq_slice_extension_enabled())
> +		return false;
> +
> +	/* If not enabled or not a return from interrupt, nothing to do. */
> +	state = curr->rseq.slice.state;
> +	state.enabled &= curr->rseq.event.user_irq;
> +	if (likely(!state.state))
> +		return false;
> +
> +	rseq = curr->rseq.usrptr;
> +	scoped_user_rw_access(rseq, efault) {
> +
> +		/*
> +		 * 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?

-- Steve


> +		 *  2) A previous rescheduling request resulted in a slice
> +		 *     extension grant.
> +		 */
> +		if (unlikely(work_pending || state.granted)) {
> +			/* Clear user control unconditionally. No point for checking */
> +			unsafe_put_user(0U, &rseq->slice_ctrl.all, efault);
> +			rseq_slice_clear_grant(curr);
> +			return false;
> +		}
> +
> +		unsafe_get_user(usr_ctrl.all, &rseq->slice_ctrl.all, efault);
> +		if (likely(!(usr_ctrl.request)))
> +			return false;
> +
> +		/* Grant the slice extention */
> +		usr_ctrl.request = 0;
> +		usr_ctrl.granted = 1;
> +		unsafe_put_user(usr_ctrl.all, &rseq->slice_ctrl.all, efault);
> +	}
> +