linux-kernel - Re: [PATCH v6] ARM: vfp: Always save VFP state in vfp_pm

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] [day] [month] [year] [list]

Message-ID: <CAMbhsRQVrmia_FHwwWbVcrzNh5s24PYPqGCXuH1r1MvMnpYSzA@mail.gmail.com>
Date:	Mon, 16 Jul 2012 12:42:53 -0700
From:	Colin Cross <ccross@...roid.com>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Russell King <linux@....linux.org.uk>,
	Barry Song <bs14@....com>, Ido Yariv <ido@...ery.com>,
	Daniel Drake <dsd@...top.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6] ARM: vfp: Always save VFP state in vfp_pm_suspend on UP

On Mon, Jul 16, 2012 at 11:34 AM, Nicolas Pitre
<nicolas.pitre@...aro.org> wrote:
> On Mon, 16 Jul 2012, Colin Cross wrote:
>
>> vfp_pm_suspend should save the VFP state in suspend after
>> any lazy context switch.  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
>>   Thread 2 initiates suspend
>>   vfp_pm_suspend is called with the VFP disabled, and the unsaved
>>      VFP context of Thread 1 in the registers
>>
>> Modify vfp_pm_suspend to save the VFP context whenever
>> vfp_current_hw_state is not NULL.
>>
>> Includes a fix from Ido Yariv <ido@...ery.com>, who pointed out that on
>> SMP systems, the state pointer can be pointing to a freed task struct if
>> a task exited on another cpu, fixed by using #ifdef CONFIG_SMP in the
>> new if clause.
>>
>> Cc: Russell King <linux@....linux.org.uk>
>> Cc: Barry Song <bs14@....com>
>> Cc: Catalin Marinas <catalin.marinas@....com>
>> Cc: Ido Yariv <ido@...ery.com>
>> Cc: Daniel Drake <dsd@...top.org>
>> Cc: Will Deacon <will.deacon@....com>
>> Signed-off-by: Colin Cross <ccross@...roid.com>
>> ---
>>  arch/arm/vfp/vfpmodule.c |    6 ++++++
>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
>> index 58696192..ce55f05 100644
>> --- a/arch/arm/vfp/vfpmodule.c
>> +++ b/arch/arm/vfp/vfpmodule.c
>> @@ -457,6 +457,12 @@ static int vfp_pm_suspend(void)
>>
>>               /* disable, just in case */
>>               fmxr(FPEXC, fmrx(FPEXC) & ~FPEXC_EN);
>> +     } else if (vfp_current_hw_state[ti->cpu]) {
>> +#ifndef CONFIG_SMP
>> +             fmxr(FPEXC, fpexc | FPEXC_EN);
>> +             vfp_save_state(vfp_current_hw_state[ti->cpu], fpexc);
>> +             fmxr(FPEXC, fpexc);
>> +#endif
>>       }
>
> Couldn't vfp_sync_hwstate() be used here instead?

Not easily, we don't have the thread struct of the thread that is in
the vfp hardware.  We would have to read vfp_current_hw_state for the
current cpu and use container_of to get from  struct vfpstate to
struct thread_info, and then pass that back in to vfp_sync_hwstate.
--
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/