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: <4D51985B.7080003@goop.org>
Date:	Tue, 08 Feb 2011 11:24:11 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.Com>
CC:	Yinghai Lu <yinghai@...nel.org>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"x86@...nel.org" <x86@...nel.org>,
	Jan Beulich <JBeulich@...ell.com>
Subject: Re: [PATCH] x86/mm/init: respect memblock reserved regions when destroying
 mappings

On 02/08/2011 06:55 AM, Konrad Rzeszutek Wilk wrote:
>>>> could be used to skip clear highmap for xen path?
>>> Seems pretty ad-hoc.
>>>
>> then what is size for mfn-list after _end...
> 8 bytes * nr_pages. For 4GB, 2048 pages. For 32GB, 8192 pages. For 128GB,
> 32768 pages, and so on.
>> could be copied or move to BRK.
> The _brk size is determined during build-time. We don't know what the
> memory size will be during bootup time and would have to select the
> highest values (128MB) which is quite a large amount to be reserved
> in _brk area.

If the brk is guaranteed to be the last thing in the kernel, we could
remove the static allocation of brk space, and just make it dynamic, and
then use the dynamic end-of-brk instead of _end.

That would require mapping the brk space at runtime, which would require
a (conservative) runtime estimate of how much space we would end up
needing, I guess by adding together the static allocations and then
adding any dynamic ones we need.

For Xen, specifically, we could just extend brk to include all the stuff
the domain builder sticks after the kernel, so it would both be brk
allocated and left in-situ.

But I'm not sure if this would work in the native case - would there be
a guarantee that there's enough space after the kernel to fit any brk usage?

    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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ