linux-kernel - Re: [PATCH 1/4] x86, gart: Don't enforce GART aperture lower-bound by alignment

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: <4DAC93BA.4030108@zytor.com>
Date:	Mon, 18 Apr 2011 12:40:42 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Joerg Roedel <joro@...tes.org>
CC:	"Roedel, Joerg" <Joerg.Roedel@....com>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH 1/4] x86, gart: Don't enforce GART aperture lower-bound
 by alignment

On 04/18/2011 12:06 PM, Joerg Roedel wrote:
> On Mon, Apr 18, 2011 at 10:39:05AM -0700, H. Peter Anvin wrote:
>> I'm going to apply your patch as-is, based on the notion that this is a
>> change of mechanism, and a change of policy is a separate thing.
>> However, we should address the shutdown of the GART first, and then we
>> can move the start address to zero (again, two separate patches.)
> 
> Hmm, thinking again about this, setting the lower-bound to 0 may break
> kdump setups. The kdump kernel is then able to allocate an aperture too
> and that may use half of the memory from the kdump-system so that the
> dump-process triggers OOM.
> As it is now, the GART is automatically disabled when the BIOS doesn't
> setup it correctly and the machine has not more than 512MB of memory.
> Either we keep it as is or, with the changes suggested above, we handle
> it like soft-iotlb and don't use gart for dma-api at all when
> max_pfn is smaller than 4G.
> 

OK, kdump is no longer limited to 512 MiB and so that number is spurious
in the context of kdump.  If that is broken it is already broken.  Thus
the 512 MiB number already is looking spurious.

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