Messages in this thread | | | Date | Tue, 25 Feb 2003 18:35:37 +0100 | From | Manfred Spraul <> | Subject | Re: [PATCH] ptrace PTRACE_READDATA/WRITEDATA, kernel 2.5.62 |
| |
fcorneli@elis.rug.ac.be wrote:
>But since the ptrace_readdata >lives in the kernel tree for some time now and nobody is complaining about >it I assume the sparc usage of ptrace_readdata is OK. I did test it on >i386 and it works just fine. > > Sorry, my fault. I remembered that someone must do double buffering. I've overlooked that ptrace_readdata does the double buffering.
>When I look at the implementation of ptrace_readdata the dst (3th arg) has >to be a pointer to user space; see: copy_to_user(dst, buf, retval). Only >access_process_vm wants a kernel pointer. Anyway access_process_vm has >some known issues, see: >http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.62/2.5.62-mm3/broken-out/ptrace-flush.patch >but it's getting fixed I hope. > > This patch seems to be wrong. flush_dcache_page is not a replacement for flush_page_to_ram(): It's an optimized cache flush function, only valid for page cache pages: If a page is mapped only once, then no aliasing can occur and the flush is not required. For page cache pages, "mapped once" is equivalient to an empty page->mapping->i_mmap{,_shared}. The pages are mapped once in the page cache, and _if_ they are mapped in user space, then page->mapping->i_mmap{,_shared} is not empty.
ptrace can be called on random addresses - sysv shm, anonymous pages, etc. page->mapping->i_mmap{,_shared} is meaningless. If you think about it, if ptrace accesses a page, then it's guaranteed to be mapped twice: once in user space, once by the kmap_atomic() for the kernel space access.
-- Manfred
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |