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

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

Chuck Ebbert wrote:
> Nevermind.  I thought because you changed struct pt_regs in ptrace_abi.h
> it meant a user ABI change.
>   

Yes, that header seems pretty badly misnamed.  The user-visible 
structure is user_pt_regs.

> But they can get out of sync, e.g. when switch_to() restores the new
> task's esp, the PDA still contains the old pcurrent and they don't get
> synchronized until the write_pda() in __switch_to().
>   

Yes, that's true, but the window is fairly small.  More importantly, the 
question of "what task is currently running" is fundamentally 
ill-defined while you're in the middle of a context switch, so I don't 
think this is a big issue.  __switch_to runs on the new task's stack, so 
that's effectively where current_thread_info()->task changes value 
(aside from the few instructions in switch_to() between the %esp update 
and the jmp to __switch_to).  I could put the write_pda() earlier in 
__switch_to so the window is smaller.  But again, for it to make a 
difference, someone would want to be using current *within* __switch_to, 
which is just silly.

>> 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.
>>     
>
> Would it make any sense to replace the 'cpu' field in thread_info with
> a pointer to a PDA-like structure?  We could even embed the static per_cpu
> data directly into that struct instead of chasing pointers...
>   

I don't think so.  The whole point is to make the pda easily accessible 
with simple addressing modes based on %gs:.   I have been wondering if 
we can modify the percpu mechanism to get the linker to construct the 
layout of the pda, so that all the existing percpu stuff can be 
transparently moved into the pda and accessed efficiently.  I think it 
would be pretty tricky to get it all working though...

But the PDA isn't really intended for *all* per-cpu data; its mostly for 
stuff which is accessed often, or needs to be quickly and easily 
accessibly.  My specific motivation is to use the PDA for easy access to 
Xen per-cpu data, which needs to be accessible with short instructions 
which can be inlined.

    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/