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

From: Borislav Petkov <bp@alien8.de>
To: "Bae, Chang Seok" <chang.seok.bae@intel.com>
Cc: "Lutomirski, Andy" <luto@kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"Brown, Len" <len.brown@intel.com>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"Macieira, Thiago" <thiago.macieira@intel.com>,
	"Liu, Jing2" <jing2.liu@intel.com>,
	"Shankar, Ravi V" <ravi.v.shankar@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v9 08/26] x86/fpu/xstate: Introduce helpers to manage the XSTATE buffer dynamically
Date: Wed, 18 Aug 2021 11:28:24 +0200	[thread overview]
Message-ID: <YRzSuC25eHEOgj6h@zn.tnic> (raw)
In-Reply-To: <2B279B5F-ACF2-46F2-9259-684419A57BDF@intel.com>

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