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]
Date:	Thu, 21 May 2015 16:11:18 +0000
From:	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>
To:	Paul Burton <Paul.Burton@...tec.com>
CC:	"linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
	"rusty@...tcorp.com.au" <rusty@...tcorp.com.au>,
	"alexinbeijing@...il.com" <alexinbeijing@...il.com>,
	"david.daney@...ium.com" <david.daney@...ium.com>,
	"alex@...x-smith.me.uk" <alex@...x-smith.me.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ralf@...ux-mips.org" <ralf@...ux-mips.org>,
	James Hogan <James.Hogan@...tec.com>,
	Markos Chandras <Markos.Chandras@...tec.com>,
	"macro@...ux-mips.org" <macro@...ux-mips.org>,
	"eunb.song@...sung.com" <eunb.song@...sung.com>,
	"manuel.lauss@...il.com" <manuel.lauss@...il.com>,
	"andreas.herrmann@...iumnetworks.com" 
	<andreas.herrmann@...iumnetworks.com>
Subject: Re: [PATCH 1/2] MIPS: MSA: bugfix - disable MSA during thread
 switch correctly

Yes, I have a program but it is binary only.

If you want to understand why disable_DMA() after resume() doesn't work,
search for restoring RA register in resume() after changing SP.

- Leonid.


Paul Burton <Paul.Burton@...tec.com> wrote:


On Tue, May 19, 2015 at 02:13:51PM -0700, Leonid Yegoshin wrote:
> During thread cloning the new (child) thread should have MSA disabled even
> at first thread entry. So, the code to disable MSA is moved from macro
> 'switch_to' to assembler function 'resume' before it switches kernel stack
> to 'next' (new) thread. Call of 'disable_msa' after 'resume' in 'switch_to'
> macro never called a first time entry into thread.

Hi Leonid,

I'm not sure I understand what you're trying to say here. Do you have an
example of a program that demonstrates the behaviour you believe to be
broken?

Thanks,
    Paul

> Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@...tec.com>
> ---
>  arch/mips/include/asm/switch_to.h |    1 -
>  arch/mips/kernel/r4k_switch.S     |    6 ++++++
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/include/asm/switch_to.h b/arch/mips/include/asm/switch_to.h
> index e92d6c4b5ed1..0d0f7f8f8b3a 100644
> --- a/arch/mips/include/asm/switch_to.h
> +++ b/arch/mips/include/asm/switch_to.h
> @@ -104,7 +104,6 @@ do {                                                                      \
>       if (test_and_clear_tsk_thread_flag(prev, TIF_USEDMSA))          \
>               __fpsave = FP_SAVE_VECTOR;                              \
>       (last) = resume(prev, next, task_thread_info(next), __fpsave);  \
> -     disable_msa();                                                  \
>  } while (0)
>
>  #define finish_arch_switch(prev)                                     \
> diff --git a/arch/mips/kernel/r4k_switch.S b/arch/mips/kernel/r4k_switch.S
> index 04cbbde3521b..7dbb64656bfe 100644
> --- a/arch/mips/kernel/r4k_switch.S
> +++ b/arch/mips/kernel/r4k_switch.S
> @@ -25,6 +25,7 @@
>  /* preprocessor replaces the fp in ".set fp=64" with $30 otherwise */
>  #undef fp
>
> +#define t4  $12
>  /*
>   * Offset to the current process status flags, the first 32 bytes of the
>   * stack are not used.
> @@ -73,6 +74,11 @@
>       cfc1    t1, fcr31
>       msa_save_all    a0
>       .set pop        /* SET_HARDFLOAT */
> +     li      t4, MIPS_CONF5_MSAEN
> +     mfc0    t3, CP0_CONFIG, 5
> +     or      t3, t3, t4
> +     xor     t3, t3, t4
> +     mtc0    t3, CP0_CONFIG, 5
>
>       sw      t1, THREAD_FCR31(a0)
>       b       2f
>
--
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