linux-kernel - Re: [Q x86-64] on kernel

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1309863656.634.111.camel@zakaz.uk.xensource.com>
Date:	Tue, 05 Jul 2011 12:00:56 +0100
From:	Ian Campbell <ijc@...lion.org.uk>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, Brian Gerst <brgerst@...il.com>,
	Jan Beulich <JBeulich@...ell.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [Q x86-64] on kernel_eflags

On Tue, 2011-07-05 at 14:47 +0400, Cyrill Gorcunov wrote:
> While were looking into ret_from_fork code I somehow wondered
> about the global kernel_eflags variable here.
> 
> arch/x86/cpu/common.c
> ---------------------
> unsigned long kernel_eflags;
> 
> void __cpuinit cpu_init(void)
> {
> 	...
> 	raw_local_save_flags(kernel_eflags);
> }
> 
> arch/x86/kernel/entry_64.S
> --------------------------
> ENTRY(ret_from_fork)
> 	DEFAULT_FRAME
> 	LOCK ; btr $TIF_FORK,TI_flags(%r8)
> 	pushq_cfi kernel_eflags(%rip)
> 	popfq_cfi                               # reset kernel eflags
> 
> Every call to cpu_init renew global kernel_eflags
> and every task switching does use this variable in a
> sake of cleaning carry bit of flags register as far as
> I can tell.
> 
> Should not every cpu has own copy of kernel_eflags? Just
> to be consistent in style? Or this would be space waisting
> and an optimization is done here?

I noticed this a while ago and couldn't figure out why it was done this
way. On 32-bit the initial EFLAGS is simply hardcoded and that seems to
make sense to me since it's not clear that the specific value of EFLAGS
at the point it is saved in cpu_init() has any particular meaning.

I posted http://lkml.org/lkml/2010/2/9/155 to switch to the hardcoded
version for 64 bit too. Is it worth my rebasing and reposting that?

(http://lkml.org/lkml/2010/2/9/152 and http://lkml.org/lkml/2010/2/9/154
were followon cleanups).

Ian.

-- 
Ian Campbell
Current Noise: Kylesa - Drop Out

"... all the modern inconveniences ..."
		-- Mark Twain

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