linux-kernel - Re: unified percpu stuff

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]

Message-ID: <73c1f2160901271107n55509844xd02592bf9ed00038@mail.gmail.com>
Date:	Tue, 27 Jan 2009 14:07:49 -0500
From:	Brian Gerst <brgerst@...il.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Tejun Heo <htejun@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: unified percpu stuff

On Tue, Jan 27, 2009 at 12:50 PM, Jeremy Fitzhardinge <jeremy@...p.org> wrote:
> Brian Gerst wrote:
>>>
>>> BTW, does the initial cpu0 percpu area get reallocated and moved during
>>> boot, or does cpu0 keep using the same memory forever?
>>>
>>
>> It is reallocated in setup_per_cpu_areas().
>>
>
> Hm, OK.  What's the reason we need to move cpu 0's percpu area?  Its always
> seemed a bit awkward.
>
> Once it has been moved, how can I find the address of a variable in the
> original boot-time cpu 0 percpu area?  There's a couple of pages which Xen
> will have marked RO which need to be made RW if they're being freed back
> into the kernel pool.  Currently I use per_cpu_var(gdt_page), but guess
> that's a small offset rather than a directly usable address.

The fact that the boot cpu area is moved isn't new.  It's been that
way for a while.  The reason it is moved is so that extra space can be
allocated at the end for dynamic allocations.  It looks like Xen just
avoided it by not loading the per-cpu GDT until after the copy.  I
guess you could get by without reloading the GDT, but you would still
need to set MSR_GS_BASE for 64-bit.  32-bit happens to work because
%fs is probably initialized to the same segment as %ds.  If 32-bit
were ever to switch to zero-based per-cpu like 64-bit, that assumption
would fail.

You need to add __per_cpu_load to the offset to get the address of the
variable in the original boot per-cpu area.

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