linux-kernel - Re: [PATCH RFC 0/6] Implement per-processor data areas for i386.

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: <44F557A8.1030605@goop.org>
Date:	Wed, 30 Aug 2006 02:17:28 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Chuck Ebbert <76306.1226@...puserve.com>
CC:	Andrew Morton <akpm@...l.org>, Andi Kleen <ak@...e.de>,
	Jan Beulich <jbeulich@...ell.com>,
	Zachary Amsden <zach@...are.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC 0/6] Implement per-processor data areas for i386.

Chuck Ebbert wrote:
>> This patch implements per-processor data areas by using %gs as the
>> base segment of the per-processor memory.
>>     
> This changes the ABI for signals and ptrace() and that seems like
> a bad idea to me.
>   

I don't believe it does; it certainly shouldn't change the usermode 
ABI.  How do you see it changing?

> And the way things are done now is so ingrained into the i386
> kernel that I'm not sure it can be done.  E.g. I found two
> open-coded implementations of current, one in kernel_fpu_begin()
> and one in math_state_restore().
>   

That's OK.  The current task will still be available in thread_info; 
this is needed for very early CPU bringup anyway, before the PDA has 
been set up.  The vast majority of "get current task" operations can be 
swept up by changing "current" however.

> Can you describe what it is about the way things work now that
> prevents dynamic allocation?
>   

To be honest, I haven't looked at percpu.h in great detail.  I was 
making assumptions about how it works, but it looks like they were wrong.

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