Messages in this thread | | | Date | Tue, 25 Feb 2003 11:36:44 +0100 (CET) | From | fcorneli@elis ... | Subject | Re: [PATCH] ptrace PTRACE_READDATA/WRITEDATA, kernel 2.5.62 |
| |
Hi,
> >+ ret = 0; > >+ res = ptrace_readdata(child, addr, (void *)addr2, data); > >+ if (res == data) > >+ break; > > > > > You mention sparc - have you tested if that works on sparc? > ptrace_readdata assumes that addr2 is a pointer to kernel space, not > user space. It works by chance on i386, but that's not acceptable for > merging. > You must double buffer, check mem_read in fs/proc/base.c
I don't own a sparc so I couldn't test it. 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.
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.
As for that double buffering, it's already there. See usage of: kernel/ptrace.c:ptrace_readdata:char buf[128]; Please notice this double buffering can be eliminated as done in my exptrace patch, available at: http://www.elis.rug.ac.be/~fcorneli/downloads/devel/exptrace-0.3.6pre7-2.4.20.patch This speeds up everything... but the code needs some more testing, and a port to 2.5.
Regards, Frank.
- 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/
| |