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: Sun, 7 Jan 2007 18:39:46 +0000 From: Christoph Hellwig <hch@...radead.org> To: Christoph Hellwig <hch@...radead.org>, Rusty Russell <rusty@...tcorp.com.au>, Ingo Molnar <mingo@...e.hu>, Zachary Amsden <zach@...are.com>, Jeremy Fitzhardinge <jeremy@...source.com>, Chris Wright <chrisw@...s-sol.org>, Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org, Arjan van de Ven <arjan@...radead.org>, Adrian Bunk <bunk@...sta.de>, airlied@...ux.ie Subject: Re: [patch] paravirt: isolate module ops On Sat, Jan 06, 2007 at 07:31:52PM +0000, Christoph Hellwig wrote: > On Sun, Jan 07, 2007 at 03:18:45AM +1100, Rusty Russell wrote: > > PS. drm_memory.h has a "drm_follow_page": this forces us to uninline > > various page tables ops. Can this use follow_page() somehow, or do we > > need an "__follow_page" export for this case? > > Not if avoidable. And it seems avoidable as drm really should be using > vmalloc_to_page. Untested patch below: Even better we can actualy avid most of the page table walks completely. First there is a number of places that can never have the vmalloc case an may use ioremap/iounmap directly. Secondly drm_core_ioremap/ drm_core_ioremapfree already have the right drm_map to check wich kind of mapping we have - we just need to use it instead of discarding that information! The only leaves direct drm_ioremapfree in i810_dma.c and i830_dma.c which I don't quite manage to follow. Maybe Dave has an idea how to get rid of those aswell. View attachment "drm-avoid-drm_ioremap" of type "text/plain" (1987 bytes) View attachment "simplify-drm_core_ioremap" of type "text/plain" (2817 bytes)
Powered by blists - more mailing lists