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

Message-ID: <CAOS58YPtNRK3mhAp26585+nWFL44kghfAh8vfiB=kdEYmn_8bg@mail.gmail.com>
Date:	Sat, 31 Dec 2011 02:45:37 +0900
From:	Tejun Heo <tj@...nel.org>
To:	monstr@...str.eu
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

Hello,

On Fri, Dec 30, 2011 at 4:58 PM, Michal Simek <monstr@...str.eu> wrote:
> I haven't said to replace phys_addr_t!
> My point was something like this (just as example on parisc and
> free_bootmem_node).
> The problematic part is kmemleak code which could be good reason not to
> change it.

I think it's still a bad idea and you haven't provided any
justification for it.  Think about it - any user which uses pa() may
get that last page and if that user is using [start,end) range, it may
overflow.  It doesn't even matter how you implement it.  I just can't
understand why you obsess about that last page.  It doesn't matter.
Just add those few lines to exclude the last single page and be done
with it.  Unless you're gonna provide rationale for why adding such
risk and more complexity makes sense for that single last page which
most BIOSes wouldn't even map, I don't really think this thread is
going anywhere.

Thanks.

-- 
tejun
--
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/