linux-kernel - Re: memblock and bootmem problems if start + size = 4GB

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: <4EFC995A.5090904@monstr.eu>
Date:	Thu, 29 Dec 2011 17:46:18 +0100
From:	Michal Simek <monstr@...str.eu>
To:	Tejun Heo <tj@...nel.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Sam Ravnborg <sam@...nborg.org>, linux-mm@...ck.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: memblock and bootmem problems if start + size = 4GB

Tejun Heo wrote:
> Hello,
> 
> On Tue, Dec 20, 2011 at 10:19:18AM +0100, Michal Simek wrote:
>>> Yeah, that's an inherent problem in using [) ranges but I think
>>> chopping off the last page probably is simpler and more robust
>>> solution.  Currently, memblock_add_region() would simply ignore if
>>> address range overflows but making it just ignore the last page is
>>> several lines of addition.  Wouldn't that be effective enough while
>>> staying very simple?
>> The main problem is with PFN_DOWN/UP macros and it is in __init section.
>> The result will be definitely u32 type (for 32bit archs) anyway and seems to me
>> better solution than ignoring the last page.
> 
> Other than being able to use one more 4k page, is there any other
> benefit? Maybe others had different experiences but in my exprience
> trying to extend range coverages - be it stack top/end pointers,
> address ranges or whatnot - using [] ranges or special flag usually
> ended up adding complexity while adding almost nothing tangible.

First of all I don't like to use your term "extend range coverages".
We don't want to extend any ranges - we just wanted to place memory to the end
of address space and be able to work with. It is limitation which should be fixed somehow.
And I would expect that PFN_XX(base + size) will be in u32 range.

Probably the best solution will be to use PFN macro in one place and do not covert
addresses in common code.

+ change parameters in bootmem code because some arch do
free_bootmem_node(..., PFN_PHYS(), ...)
and
reserve_bootmem_node(..., PFN_PHYS(), ...)

and then in that functions(free/reseve_bootmem_code) are used PFN_DOWN/PFN_UP macros.
If alignment is handled by architecture code (which I believe is) then should be possible to change parameters.

For example:
void __init free_bootmem_node(pg_data_t *pgdat, unsigned long start_pfn,
			      unsigned long end_pfn)

int __init reserve_bootmem_node(pg_data_t *pgdat, unsigned long start_pfn,
				 unsigned long end_pfn, int flags)

Is there any reason to use use physical addresses instead of pfns in bootmem code?

 >  On
> extreme cases, people even carry separate valid flag to use %NULL as
> valid address, which is pretty silly, IMHO.  So, unless there's some
> benefit that I'm missing, I still think it's an overkill.  It's more
> complex and difficult to test and verify.  Why bother for a single
> page?

Where do you think this page should be placed? In common code or in architecture memory
code where one page from the top of 4G should be subtract?

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
--
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/