lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTik_Jey_PtRmr530FVckA6RXHESeX+CyoJC=ZTkR@mail.gmail.com>
Date:	Mon, 14 Feb 2011 10:35:37 -0800
From:	Colin Cross <ccross@...roid.com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Russell King <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: vfp: Always save VFP state in vfp_pm_suspend

On Mon, Feb 14, 2011 at 3:42 AM, Catalin Marinas
<catalin.marinas@....com> wrote:
> On Sun, 2011-02-13 at 23:13 +0000, Colin Cross wrote:
>> vfp_pm_suspend should save the VFP state any time there is
>> a last_VFP_context.  If it only saves when the VFP is enabled,
>> the state can get lost when, on a UP system:
>>    Thread 1 uses the VFP
>>    Context switch occurs to thread 2, VFP is disabled but the
>>       VFP context is not saved to allow lazy save and restore
>>    Thread 2 initiates suspend
>>    vfp_pm_suspend is called with the VFP disabled, but the
>>       context has not been saved.
>
> At this point is it guaranteed that the thread won't migrate to another
> CPU? If not, we should use get/put_cpu.

Yes, VFP suspend is implemented with a sysdev, which is suspended
after disable_nonboot_cpus.

>> --- a/arch/arm/vfp/vfpmodule.c
>> +++ b/arch/arm/vfp/vfpmodule.c
>> @@ -415,13 +415,12 @@ static int vfp_pm_suspend(struct sys_device *dev, pm_message_t state)
>>         struct thread_info *ti = current_thread_info();
>>         u32 fpexc = fmrx(FPEXC);
>>
>> -       /* if vfp is on, then save state for resumption */
>> -       if (fpexc & FPEXC_EN) {
>> +       /* save state for resume */
>> +       if (last_VFP_context[ti->cpu]) {
>>                 printk(KERN_DEBUG "%s: saving vfp state\n", __func__);
>> -               vfp_save_state(&ti->vfpstate, fpexc);
>> -
>> -               /* disable, just in case */
>> -               fmxr(FPEXC, fmrx(FPEXC) & ~FPEXC_EN);
>> +               fmxr(FPEXC, fpexc | FPEXC_EN);
>> +               vfp_save_state(last_VFP_context[ti->cpu], fpexc);
>> +               fmxr(FPEXC, fpexc & ~FPEXC_EN);
>>         }
>
> We may want to set the last_VFP_context to NULL so that after resuming
> (to the same thread) we force the VFP reload from the vfpstate
> structure. The vfp_support_entry code ignores the reloading if the
> last_VFP_context is the same as vfpstate.

Right, will fix.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ