On 05/02/2016 03:17 PM, Yu-cheng Yu wrote:
> @@ -167,7 +168,7 @@ int copy_fpstate_to_sigframe(void __user *buf, void
> __user *buf_fx, int size)
> sizeof(struct user_i387_ia32_struct), NULL,
> (struct _fpstate_32 __user *) buf) ? -1 : 1;
>
> - if (
On Mon, May 02, 2016 at 02:32:14PM -0700, Dave Hansen wrote:
>
> I think we're off in the weeds here.
>
> Please just send an updated patch for what you want to do here.
>From 43134a773d23ae8bab9f158d143c5cfb76bc0e9c Mon Sep 17 00:00:00 2001
From: Yu-cheng Yu
Date: Sat, 14 Nov 2015 16:59:45 -08
On 05/02/2016 02:24 PM, Yu-cheng Yu wrote:
> On Mon, May 02, 2016 at 02:18:17PM -0700, Yu-cheng Yu wrote:
>> > Before Linux gets into copy_fpstate_to_sigframe(),
>> > current->thread.fpu.fpstate_active must be true.
>> > For eagerfpu, fpregs_active() must also be true.
>> > For lazyfpu, once we try
On Mon, May 02, 2016 at 02:18:17PM -0700, Yu-cheng Yu wrote:
> Before Linux gets into copy_fpstate_to_sigframe(),
> current->thread.fpu.fpstate_active must be true.
> For eagerfpu, fpregs_active() must also be true.
> For lazyfpu, once we try to do FSAVE/FXSAVE/XSAVE,
> fpregs_active() will become
On Mon, May 02, 2016 at 10:33:10AM -0700, Dave Hansen wrote:
> On 05/02/2016 10:19 AM, Yu-cheng Yu wrote:
> > On Mon, May 02, 2016 at 09:43:47AM -0700, Dave Hansen wrote:
> >>> If (fpu.fpstate_active == 0), then the task does not use FPU; we don't
> >>> want to save these registers, right?
> >>
>
On 05/02/2016 10:19 AM, Yu-cheng Yu wrote:
> On Mon, May 02, 2016 at 09:43:47AM -0700, Dave Hansen wrote:
>>> If (fpu.fpstate_active == 0), then the task does not use FPU; we don't
>>> want to save these registers, right?
>>
>> No. It's possible to have fpstate_active=0 while fpregs_active=1. S
On Mon, May 02, 2016 at 09:43:47AM -0700, Dave Hansen wrote:
> > If (fpu.fpstate_active == 0), then the task does not use FPU; we don't
> > want to save these registers, right?
>
> No. It's possible to have fpstate_active=0 while fpregs_active=1. Such
> a task uses the FPU, but just hasn't don
On 05/02/2016 09:34 AM, Yu-cheng Yu wrote:
> On Mon, May 02, 2016 at 09:06:41AM -0700, Dave Hansen wrote:
>> On 05/02/2016 08:57 AM, Yu-cheng Yu wrote:
>>> On Fri, Apr 29, 2016 at 05:36:48PM -0700, Dave Hansen wrote:
If may_copy_fpregs_to_sigframe() were called from a slightly different
c
On Mon, May 02, 2016 at 09:06:41AM -0700, Dave Hansen wrote:
> On 05/02/2016 08:57 AM, Yu-cheng Yu wrote:
> > On Fri, Apr 29, 2016 at 05:36:48PM -0700, Dave Hansen wrote:
> >> If may_copy_fpregs_to_sigframe() were called from a slightly different
> >> context, or if we change the call-site, what br
On 05/02/2016 08:57 AM, Yu-cheng Yu wrote:
> On Fri, Apr 29, 2016 at 05:36:48PM -0700, Dave Hansen wrote:
>> If may_copy_fpregs_to_sigframe() were called from a slightly different
>> context, or if we change the call-site, what breaks?
>>
>> In other words. if we can still "may_copy_fpregs_to_sigfr
On Fri, Apr 29, 2016 at 05:36:48PM -0700, Dave Hansen wrote:
> If may_copy_fpregs_to_sigframe() were called from a slightly different
> context, or if we change the call-site, what breaks?
>
> In other words. if we can still "may_copy_fpregs_to_sigframe()" no
> matter the state of fpu.fpstate_acti
On 04/29/2016 03:43 PM, Yu-cheng Yu wrote:
> On Fri, Apr 29, 2016 at 01:09:07PM -0700, Dave Hansen wrote:
>> On 03/04/2016 10:12 AM, Yu-cheng Yu wrote:
>>> +static int may_copy_fpregs_to_sigframe(void)
>>> +{
>>> + /*
>>> +* In signal handling path, the kernel already checks if
>>> +* FPU
On Fri, Apr 29, 2016 at 01:09:07PM -0700, Dave Hansen wrote:
> On 03/04/2016 10:12 AM, Yu-cheng Yu wrote:
> > diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
> > index 0fbf60c..09945f1 100644
> > --- a/arch/x86/kernel/fpu/signal.c
> > +++ b/arch/x86/kernel/fpu/signal.c
> >
On 03/04/2016 10:12 AM, Yu-cheng Yu wrote:
> diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
> index 0fbf60c..09945f1 100644
> --- a/arch/x86/kernel/fpu/signal.c
> +++ b/arch/x86/kernel/fpu/signal.c
> @@ -130,6 +130,45 @@ static inline int copy_fpregs_to_sigframe(struct
>
XSAVES is a kernel instruction and uses a compacted format. When
working with user space, the kernel should provide standard-format,
non-supervisor state data. We cannot do __copy_to_user() from a compacted-
format kernel xstate area to a signal frame.
Note that the path to copy_fpstate_to_sigfram
15 matches
Mail list logo
