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/
This archive was generated by hypermail 2b29 : Fri Feb 28 2003 - 22:00:27 EST