linux-kernel - Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn

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]

Date:	Mon, 11 Mar 2013 23:09:02 +0000
From:	Chris Wilson <chris@...is-wilson.co.uk>
To:	"H. Peter Anvin" <hpa@...or.com>, Tejun Heo <tj@...nel.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Renninger <trenn@...e.de>,
	Tang Chen <tangchen@...fujitsu.com>,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	David Airlie <airlied@...ux.ie>,
	Jacob Shin <jacob.shin@....com>, linux-acpi@...r.kernel.org,
	dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

On Mon, Mar 11, 2013 at 11:50:48PM +0100, Daniel Vetter wrote:
> On Thu, Mar 07, 2013 at 10:09:26PM -0800, H. Peter Anvin wrote:
> > On 03/07/2013 09:28 PM, Tejun Heo wrote:
> > > On Thu, Mar 7, 2013 at 9:27 PM, Yinghai Lu <yinghai@...nel.org> wrote:
> > >> They are not using memblock_find_in_range(), so 1ULL<< will not help.
> > >>
> > >> Really hope i915 drm guys could clean that hacks.
> > > 
> > > The code isn't being used.  Just leave it alone.  Maybe add a comment.
> > >  The change is just making things more confusing.
> > > 
> > 
> > Indeed, but...
> > 
> > Daniel: can you guys clean this up or can we just remove the #if 0 clause?
> 
> I guess we could just put this into a comment explaining where stolen
> memory for the gfx devices is at on gen2. But tbh I don't mind if we just
> keep the #if 0 code around. For all newer platforms we can get at that
> offset through mch bar registers, so I don't really care.

If you want to keep the comment accurate
s/max_low_pfn_mapped/max_pfn_mapped/ as the machines in question don't
support more than 4GiB anyway. Or you can help address the underlying
issue of figuring out how we can derive the location of the stolen
memory which is reserved by the BIOS but not communicated to the OS.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
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/