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:	Sat, 03 May 2008 11:57:47 +0100
From:	James Courtier-Dutton <James@...erbug.co.uk>
To:	hadi@...erus.ca
CC:	Suresh Siddha <suresh.b.siddha@...el.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: i387/FPU init issues...

jamal wrote:
> Peoplez,
>
> Ive narrowed down a problem i am having with an old P2 to commit
> 61c4628b538608c1a85211ed8438136adfeb9a95 with subject "x86, fpu: split
> FPU state from task struct - v5" (Authored by Suresh and committed by
> Ingo on Apr/19).
>
> In the process i learnt how painfully time consuming and boring a blind
> git bisect feast could be (the last time a kernel worked on the P2 was
> back in 2.6.23). I literally spent no less than 10 hours tracking this
> (Ok, I was chewing tobbaco in between running git bisect bad/good,
> compile, copy over kernel, spit here, reboot, test).
> Also this patch is so huge that given my lack of knowledge in the area,
> i couldnt do better bisecting to be more exact on what is causing this.
> i.e the patch is not bisect-friendly. 
> So the best i can do is have other people take it from here.
>
> I am able to reproduce the issue consistently on my laptop using qemu
> (which helped speed debugging a bit). I have also narrowed it down to
> include/asm-x86/i387.h::__save_init_fpu in (32 bit version) - it dies
> somewhere in calling the following line:
>
> ----
>         alternative_input(
>                 "fnsave %[fx] ;fwait;" GENERIC_NOP8 GENERIC_NOP4,
>                 "fxsave %[fx]\n"
>                 "bt $7,%[fsw] ; jnc 1f ; fnclex\n1:",
>                 X86_FEATURE_FXSR,
>                 [fx] "m" (tsk->thread.xstate->fxsave),
>                 [fsw] "m" (tsk->thread.xstate->fxsave.swd) : "memory");
> ----------
>
> The only thing that has changed there compared to good version is the
> last two lines. But that looks sane to me given the struct naming has
> changed. So i am suspecting the calling path perhaps not setting
> something or other.
>
>   
My guess would be that the jnc 1f is now wrong.

--
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