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
| ||
|
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/
Powered by blists - more mailing lists