From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <452AEDAB.5080109@yahoo.com.au> Date: Tue, 10 Oct 2006 10:47:39 +1000 From: Nick Piggin MIME-Version: 1.0 Subject: Re: Driver-driven paging? References: <452A68E9.3000707@tungstengraphics.com> <452A7AD3.5050006@yahoo.com.au> <452A8AC6.2080203@tungstengraphics.com> In-Reply-To: <452A8AC6.2080203@tungstengraphics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org Return-Path: To: =?ISO-8859-1?Q?Thomas_Hellstr=F6m?= Cc: linux-mm@kvack.org List-ID: Thomas Hellstrom wrote: > Nick Piggin wrote: >> If you need for the driver to *then* export these pages out to be mapped >> by other processes in userspace, I think you run into problems if trying >> to use nopage. You'll need to go the nopfn route (and thus your mappings >> must disallow PROT_WRITE && MAP_PRIVATE). >> >> But I think that might just work? >> > Yes, possibly. What kind of problems would I expect if using nopage? Is > it, in particular, legal for a process to call get_user_pages() with the > tsk and mm arguments of another process? Oh that is legal. What I'm thinking you'd have problems with is one process having its pages imported to the kernel via get_user_pages, then exported again via an mmap()able device node. If another process mmaps these pages, you could easily get various problems like PageAnon being set for a file backed page, or rmap structures set up incorrectly for the page. It has been a while since I tried to look at the details, but I would just steer clear of that case. Using a nopfn handler (instead of nopage) means that the kernel will not look at the backing pages at all. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org