linux-kernel - Re: agp/intel: Fix the pre-9xx chipset flush

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: <871v8oufwm.fsf@pollan.anholt.net>
Date:	Mon, 20 Sep 2010 16:57:45 -0700
From:	Eric Anholt <eric@...olt.net>
To:	Jan Beulich <JBeulich@...ell.com>
Cc:	Brice.Goglin@...-lyon.org, airlied@...ux.ie,
	linux-kernel@...r.kernel.org
Subject: Re: agp/intel: Fix the pre-9xx chipset flush

On Thu, 16 Sep 2010 13:40:48 +0100, "Jan Beulich" <JBeulich@...ell.com> wrote:
> Eric,
> 
> in this patch you removed from intel_i830_setup_flush() a call to
> map_page_into_agp(), but you left in place the counterpart call from
> intel_i830_fini_flush() to unmap_page_from_agp()? Isn't it mere luck
> that on x86 this is only a call to set_pages_wb()?

Sounds like just an oversight.

> Further, is there really a point in doing the respective allocation
> with GFP_DMA32? Nor does __GFP_ZERO seem really necessary...

The hardware in question doesn't have memory above 32 bits, so either
way doesn't matter much.  Yeah, GFP_ZERO doesn't seem needed.

If you've got patches for agp, Chris Wilson's the kernel module
maintainer now, and Daniel Vetter's got a huge changeset queued to -next
to clean up the disaster that is the "agp" code for integrated graphics.

Content of type "application/pgp-signature" skipped