Rusty Russell wrote:
> So, is everyone happy with this smerge of Ingo and Gerd's work?
Yes.
> I'm not against it, but it needs tons of testing in -mm first.
>
> Since the vsyscall page has been at a fixed address, there might be
> real programs that hardcoded it etc.
Exploits *grin*?
Well, given that xen kernels currently have the vsyscall page at another
(fixed) address I don't expect stuff break due to a hardcoded vsyscall
page address.
> I'd also want sign-off from Gerd and
> Ingo, obviously.
Fine with me.
Signed-off-by: Gerd Hoffmann <kraxel@xxxxxxx>
> +static int nr_fixmaps = 0;
> +unsigned long __FIXADDR_TOP = 0xfffff000;
> +EXPORT_SYMBOL(__FIXADDR_TOP);
> +
> void __set_fixmap (enum fixed_addresses idx, unsigned long phys, pgprot_t flags)
> {
> unsigned long address = __fix_to_virt(idx);
> @@ -147,6 +152,13 @@ void __set_fixmap (enum fixed_addresses
> return;
> }
> set_pte_pfn(address, phys >> PAGE_SHIFT, flags);
> + nr_fixmaps++;
> +}
> +
> +void set_fixaddr_top(unsigned long top)
> +{
> + BUG_ON(nr_fixmaps > 0);
> + __FIXADDR_TOP = top - PAGE_SIZE;
> }
Is this intentional?
That are the bits which make the fixmap runtime-movable (by calling
set_fixaddr_top early enougth at boot time) to make room for the
hypervisor address space hole. Not used (yet).
We surely want to have that in the long run. It's not mentioned in the
patch description though. It also used to be a separate patch on top of
the move-vsyscall-out-of-fixmap patch.
cheers,
Gerd
--
Gerd Hoffmann <kraxel@xxxxxxx>
Erst mal heiraten, ein, zwei Kinder, und wenn alles läuft
geh' ich nach drei Jahren mit der Familie an die Börse.
http://www.suse.de/~kraxel/julika-dora.jpeg
