[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54B548EA.7020005@redhat.com>
Date: Tue, 13 Jan 2015 11:33:46 -0500
From: Rik van Riel <riel@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>
CC: linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
matt.fleming@...el.com, bp@...e.de, pbonzini@...hat.com,
tglx@...utronix.de, luto@...capital.net
Subject: Re: [RFC PATCH 05/11] x86,fpu: ensure FPU state is reloaded from
memory if task is traced
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/13/2015 11:19 AM, Oleg Nesterov wrote:
> On 01/11, riel@...hat.com wrote:
>>
>> @@ -412,8 +412,14 @@ static inline void switch_fpu_prepare(struct
>> task_struct *old, struct task_struc bool preload =
>> tsk_used_math(new) && (use_eager_fpu() || new->thread.fpu_counter
>> > 5); if (__thread_has_fpu(old)) { - if (!__save_init_fpu(old))
>> + /* + * Make sure the FPU state is restored from memory next
>> time, + * if the task has an FPU exception pending, or the
>> task's in + * memory FPU state could be changed by a debugger.
>> + */ + if (!__save_init_fpu(old) ||
>> task_is_stopped_or_traced(old)) cpu = ~0;
>
> Well, if debugger wants to change FPU state, it should call
> init_fpu() which resets .last_cpu ?
Does the ptrace (and utrace, and ... ) code actually do that?
> Plus "is_stopped" is not needed, ptracer no longer can do STOPPED
> -> TRACED transition.
I will remove _is_stopped.
- --
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUtUjqAAoJEM553pKExN6DtXIIAKzZj0zbQq4cQ08oKr6zMZqn
qz0MyTD91+1phywX+CFOoQ45tQUzAzpAw2k+2yGUFWhMsdEQEaANirK3stZj2Lte
Jh/VTlX1Y2ZpjoHFH69S6+5jy6nAqHaUTsMQ3jiXvi4YkzjYn9JGYY/N1E7BgRV/
T2HozdKD9+h27NetPaVPymZOwgIP5Qykbl77mH3SqwFaah/8DI3K3rMem5Ze88op
hlk3FFAgB4n8WsHDKtDXOARnF1dYCnxyR9f+3mRIuLgCdYDvktXOizTUumsbojE6
hMN9lwM/r469kVh3L20asAbXNdCAAG6U/tZcoQOizGrj/L9M4V5ACAzn7w+y+kE=
=8971
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists