All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Andy Lutomirski <luto@kernel.org>,
	Borislav Petkov <bp@suse.de>, Fenghua Yu <fenghua.yu@intel.com>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>
Subject: Re: [PATCH] x86/fpu: Fix invalid FPU ptrace state after execve
Date: Mon, 21 Nov 2016 10:40:51 +0100	[thread overview]
Message-ID: <20161121094051.GA24331@gmail.com> (raw)
In-Reply-To: <97ba2918-dbc8-82bf-c017-9837b731f0f1@linux.intel.com>


* Dave Hansen <dave.hansen@linux.intel.com> wrote:

> On 11/16/2016 08:56 AM, Yu-cheng Yu wrote:
> > Robert O'Callahan reported that after an execve PTRACE_GETREGSET
> > NT_X86_XSTATE continues to return the pre-exec register values
> > until the exec'ed task modifies FPU state.  The test code is at
> > https://bugzilla.redhat.com/attachment.cgi?id=1164286.
> > 
> > What is happening is when eagerfpu is enabled, fpu__clear() did
> > not properly clear fpstate.  Fix it by doing just that.
> 
> Functionally, I think the patch is fine.  just a few
> comment/documentation nits.
> 
> I think fpu__clear()'s comments are a bit out of date.  Could we make it
> clear that it is invalidating both fpregs *and* fpstate?
> 
> I also think the
> 
> 	/* FPU state will be reallocated lazily at the first use. */"
> 
> comment was fairly valuable.  Could we find some way to keep it?
> 
> The new comment:
> 
> > +	/*
> > +	 * When eagerfpu is used, make sure fpstate is cleared and initialized.
> > +	 */
> 
> also kinda implies that the if() block is only messing with fpstate.
> Could we make that more clear?  Maybe by commenting the individual lines
> inside the if():
> 
> > +	if (use_eager_fpu()) {
> > +		fpu__activate_curr(fpu);
> > +		user_fpu_begin();
> 
> instead of having it above?  Maybe something like:
> 
> 	if (use_eager_fpu()) {
> 		/* activate and load init fpstate into 'fpu' */
> 		fpu__activate_curr(fpu);
> 		/* re-activate fpregs: */
> 		user_fpu_begin();
> 		/* take new init fpstate and place in fpregs: */
>  		copy_init_fpstate_to_fpregs();
>  	}

I agree with these suggestions - but I'll apply the simple patch to x86/urgent - 
which can then be backported as far as necessary, and then resolve the conflict 
with the v4.10 tip:x86/fpu branch, and on top of that we can fix these details, 
ok?

In particular I don't like it how non-obvious the semantics are from the function 
names. I think we should try to improve the nomenclature instead of adding 
comments to every line.

Thanks,

	Ingo

      parent reply	other threads:[~2016-11-21  9:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-16 16:56 [PATCH] x86/fpu: Fix invalid FPU ptrace state after execve Yu-cheng Yu
2016-11-16 17:54 ` Borislav Petkov
2016-11-17 21:31 ` Dave Hansen
2016-11-17 22:18   ` Yu-cheng Yu
2016-11-21  9:40   ` Ingo Molnar [this message]

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=20161121094051.GA24331@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@suse.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /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.