From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 10 Oct 2006 13:31:28 +0100 From: Christoph Hellwig Subject: Re: ptrace and pfn mappings Message-ID: <20061010123128.GA23775@infradead.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1160442987.32237.34.camel@localhost.localdomain> Sender: owner-linux-mm@kvack.org Return-Path: To: Benjamin Herrenschmidt Cc: Nick Piggin , Nick Piggin , Hugh Dickins , Linux Memory Management , Andrew Morton , Jes Sorensen , Linux Kernel , Ingo Molnar List-ID: On Tue, Oct 10, 2006 at 11:16:27AM +1000, Benjamin Herrenschmidt wrote: > And the last of my "issues" here: > > get_user_pages() can't handle pfn mappings, thus access_process_vm() > can't, and thus ptrace can't. When they were limited to dodgy /dev/mem > things, it was probably ok. But with more drivers needing that, like the > DRM, sound drivers, and now with SPU problem state registers and local > store mapped that way, it's becoming a real issues to be unable to > access any of those mappings from gdb. > > The "easy" way out I can see, but it may have all sort of bad side > effects I haven't thought about at this point, is to switch the mm in > access_process_vm (at least if it's hitting such a VMA). Switching the mm is definitly no acceptable. Too many things could break when violating the existing assumptions. > 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.... I think the best idea is to add a new ->access method to the vm_operations that's called by access_process_vm() when it exists and VM_IO or VM_PFNMAP are set. ->access would take the required object locks and copy out the data manually. This should work both for spufs and drm. -- 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