From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: ptrace and pfn mappings From: Benjamin Herrenschmidt In-Reply-To: <20061010022310.GC15822@wotan.suse.de> References: <20061009140354.13840.71273.sendpatchset@linux.site> <20061009140447.13840.20975.sendpatchset@linux.site> <1160427785.7752.19.camel@localhost.localdomain> <452AEC8B.2070008@yahoo.com.au> <1160442987.32237.34.camel@localhost.localdomain> <20061010022310.GC15822@wotan.suse.de> Content-Type: text/plain Date: Tue, 10 Oct 2006 12:47:46 +1000 Message-Id: <1160448466.32237.59.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Nick Piggin , Hugh Dickins , Linux Memory Management , Andrew Morton , Jes Sorensen , Linux Kernel , Ingo Molnar List-ID: > Switch the mm and do a copy_from_user? (rather than the GUP). > Sounds pretty ugly :P > > Can you do a get_user_pfns, and do a copy_from_user on the pfn > addresses? In other words, is the memory / mmio at the end of a > given address the same from the perspective of any process? It > is for physical memory of course, which is why get_user_pages > works... Doesn't help with the racyness. > > That means that the ptracing process will temporarily be running in the > > kernel using a task->active_mm different from task->mm which might have > > funny side effects due to assumptions that this won't happen here or > > there, though I don't see any fundamental reasons why it couldn't be > > made to work. > > > > That do you guys think ? Any better idea ? The problem with mappings > > like what SPUfs or the DRM want is that they can change (be remapped > > between HW and backup memory, as described in previous emails), thus we > > don't want to get struct pages even if available and peek at them as > > they might not be valid anymore, same with PFNs (we could imagine > > ioremap'ing those PFN's but that would be racy too). The only way that > > is guaranteed not to be racy is to do exactly what a user do, that is do > > user accesses via the target process vm itself.... > > What if you hold your per-object lock over the operation? (I guess > it would have to nest *inside* mmap_sem, but that should be OK). Over the ptrace operation ? how so ? Ben. -- 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