Re: [PATCH v9 08/26] x86/fpu/xstate: Introduce helpers to manage the XSTATE buffer dynamically

[Borislav Petkov]

On Fri, Aug 13, 2021 at 07:43:53PM +0000, Bae, Chang Seok wrote:
> Without the “compacted” notion in the function name, one might
> call this even with !XSAVES. But chances are very low in practice.

So leave only the first two which are obvious and are more likely to
happen - the first one is going to be the most likely on non-dynamic
setups and the second one is on dynamic systems.

For all the other configurations, just do the loop and that's it.

*IF* an optimization needs to happen there, then it can happen latter,
supplied with perf numbers to justify it.

> Perhaps, the call site in the ptrace path becomes like this, I think:
> 
> +	if (xfeatures_mask_user_dynamic) {
> +		u64 state_mask;
> +
> +		/* Retrieve XSTATE_BV. */
> +		memcpy(&state_mask, (kbuf ?: tmpbuf) + offsetof(struct xregs_state, header),
> +		       sizeof(u64));
> +
> +		/* Expand the xstate buffer based on the XSTATE_BV. */
> +		ret = realloc_xstate_buffer(fpu, state_mask & xfeatures_mask_user_dynamic);
> +		if (ret)
> +			goto out;
> +	}
> 
> Maybe retrieve XSTATE_BV is inevitable here. Then, it is not that ugly.

Lemme see if I can follow: here, a task is being ptraced and the tracer
process does PTRACE_SETREGS to set the xregs and you want to go and read
out the XSTATE_BV vector from the supplied xstate buffer to see how much
to enlarge the buffer.

Which makes me go, whut?

Why doesn't the task already have a large enough buffer?

IOW and IIUC, you should not have to ever resize the xstate buffer of a
task in ptrace.

> In this case, the ptracer just failed to inject some context. But the
> ptracee’s context in the (old) buffer is intact. It will resume and eventually
> exit. I think arch_release_task_struct()->free_xstate_buffer() will take care
> of the old buffer.

You think or you know?

How about verifying it.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette