All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To: "Dave Hansen" <dave.hansen@intel.com>, x86@kernel.org
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com,
	chang.seok.bae@intel.com, linux-kernel@vger.kernel.org,
	"Jiaxun Yang" <j.yang-87@sms.ed.ac.uk>
Subject: Re: [RFC PATCH 07/10] x86/fpu: Rellocate fpstate on save_fpregs_to_fpstate
Date: Fri, 03 Dec 2021 11:39:19 +0000	[thread overview]
Message-ID: <57665273-e56e-4b66-9dbd-003d592eb65d@www.fastmail.com> (raw)
In-Reply-To: <343c2c64-4d0b-6e21-80e0-834d0b7147aa@intel.com>



在2021年12月3日十二月 上午12:44,Dave Hansen写道:
> On 12/2/21 4:36 PM, Jiaxun Yang wrote:
>> --- a/arch/x86/kernel/fpu/core.c
>> +++ b/arch/x86/kernel/fpu/core.c
>> @@ -112,6 +112,22 @@ static void update_avx_timestamp(struct fpu *fpu)
>>  		fpu->avx512_timestamp = jiffies;
>>  }
>>  
>> +/* Update xstate size if it more dynamic features are opted-in. */
>> +static inline void xstate_update_size(struct fpu *fpu)
>> +{
>> +	int err;
>> +	struct fpstate *fpstate = fpu->fpstate;
>> +	u64 fpsmask = fpstate->xfeatures;
>> +	u64 curmask = fpsmask | xfeatures_in_use();
>> +
>> +	if (fpu_state_size_dynamic()) {
>> +		if (fpsmask != curmask) {
>> +			err = fpstate_realloc(fpu, curmask);
>> +			WARN_ON_FPU(err);
>> +		}
>> +	}
>> +}
>> +
>>  /*
>>   * Save the FPU register state in fpu->fpstate->regs. The register state is
>>   * preserved.
>> @@ -129,6 +145,7 @@ static void update_avx_timestamp(struct fpu *fpu)
>>  void save_fpregs_to_fpstate(struct fpu *fpu)
>>  {
>>  	if (likely(use_xsave())) {
>> +		xstate_update_size(fpu);
>>  		os_xsave(fpu->fpstate);
>>  		update_avx_timestamp(fpu);
>>  		return;
>
> Have you considered what exactly happens when you hit that WARN_ON_FPU()
> which otherwise ignores the allocation error?  Have you considered what
> happens on the os_xsave() that follows it immediately?  How about what
> happens the next time this task runs after that failure?

Thank you for the catch.
This is a few questions that I don't have answer, so it's a RFC.

I thought it is unlikely to happen as kmalloc has emergency pool.
But in case it happens, I guess the best way to handle it is just
send SIGILL to corresponding user process or panic if it's kernel
fpu use?

Thanks.
-- 
- Jiaxun

  reply	other threads:[~2021-12-03 11:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03  0:36 [RFC PATCH 00/10] x86: Allocate AVX512 xstate ondemand Jiaxun Yang
2021-12-03  0:36 ` [RFC PATCH 01/10] x86/fpu: Remove duplicated declaration of __fpu_state_size_dynamic Jiaxun Yang
2021-12-03  0:36 ` [RFC PATCH 02/10] x86/fpu: Split fpu_xfd_enabled from fpu_state_size_dynamic Jiaxun Yang
2021-12-03  0:36 ` [RFC PATCH 03/10] x86/fpu: Calculate xsave state addr on fly Jiaxun Yang
2021-12-03  0:36 ` [RFC PATCH 04/10] x86/fpu: Remove xstate_comp_offsets cache Jiaxun Yang
2021-12-03  0:36 ` [RFC PATCH 05/10] x86/fpu: Cache xstate_is_aligned Jiaxun Yang
2021-12-03  0:36 ` [RFC PATCH 06/10] x86/fpu/xcr: Return all enabled xfeature if CPU doesn't support Jiaxun Yang
2021-12-03  0:36 ` [RFC PATCH 07/10] x86/fpu: Rellocate fpstate on save_fpregs_to_fpstate Jiaxun Yang
2021-12-03  0:44   ` Dave Hansen
2021-12-03 11:39     ` Jiaxun Yang [this message]
2021-12-03 15:18       ` Dave Hansen
2021-12-03 15:51         ` Jiaxun Yang
2021-12-03  0:36 ` [RFC PATCH 08/10] x86/fpu: Don't keep state_size in perm struct Jiaxun Yang
2021-12-03  0:36 ` [RFC PATCH 09/10] x86/fpu: Split out XFEATURE_MASK_KERNEL_DYNAMIC Jiaxun Yang
2021-12-03  0:36 ` [RFC PATCH 10/10] x86/fpu: Mark AVX512 xfeatures as kernel dynamic Jiaxun Yang
2021-12-03  0:40 ` [RFC PATCH 00/10] x86: Allocate AVX512 xstate ondemand Dave Hansen
2021-12-03  0:45   ` Jiaxun Yang
2021-12-03  0:58     ` Dave Hansen
2021-12-03  9:20       ` David Laight
2021-12-03 11:42       ` Jiaxun Yang
2021-12-03 11:51         ` Borislav Petkov
2021-12-03 11:55           ` Jiaxun Yang
2021-12-04 11:55 ` Peter Zijlstra

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=57665273-e56e-4b66-9dbd-003d592eb65d@www.fastmail.com \
    --to=jiaxun.yang@flygoat.com \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=j.yang-87@sms.ed.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.