linux-kernel - Re: Linux 2.6.39-rc3

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:	Thu, 14 Apr 2011 10:59:25 +0200
From:	Joerg Roedel <joro@...tes.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Alex Deucher <alexdeucher@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.freedesktop.org,
	Thomas Gleixner <tglx@...utronix.de>, Tejun Heo <tj@...nel.org>
Subject: Re: Linux 2.6.39-rc3

On Wed, Apr 13, 2011 at 03:31:09PM -0700, H. Peter Anvin wrote:
> On 04/13/2011 03:22 PM, Joerg Roedel wrote:
> > On Wed, Apr 13, 2011 at 03:01:10PM -0700, H. Peter Anvin wrote:
> >> On 04/13/2011 02:50 PM, Joerg Roedel wrote:
> >>> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
> >>>> -	addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
> >>>> +	addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
> >>>
> >>> Btw, while looking at this code I wondered why the 512M goal is enforced
> >>> by the alignment. Start could be set to 512M instead and the alignment
> >>> can be aper_size as it should. Any reason for such a big alignment?
> >>>
> >>> 	Joerg
> >>>
> >>> P.S.: The box is still in the office, I will try this debug-patch
> >>>       tomorrow.
> >>
> >> The only reason that I can think of is that the aperture itself can be
> >> huge, and perhaps 512 MiB is the biggest such known. 
> > 
> > Well, that would work as well by just using aper_size as alignment, the
> > aperture needs to be aligned on its size anyway. This code only runs
> > when Linux allocates the aperture itself and if I am mistaken is uses
> > always 64MB when doing this.
> 
> Yes, I would agree with that.  The sane thing would be to set the base
> to whatever address needs to be guarded against (WHICH SHOULD BE
> MOTIVATED), and use aper_size as alignment, *unless* we are only using
> the initial portion of a much larger hardware structure that needs
> natural alignment (which isn't clear to me, I do know we sometimes use
> only a fraction of the GART, but that doesn't mean we need to
> naturally-align the entire thing, nor that 512 MiB is sufficient to do so.)

Whats allocated here is the address-space for the aperture. The code
actually allocates the memory but all it needs is the physical address
range. This range is later programmed into hardware as the GART aperture
(the area the GART remaps).
The Linux code can split the aperture if necessary for DMA-API usage and
AGP usage. In that case both users get a half of the aperture and manage
them itself.

	Joerg

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