[lkml]   [2003]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] ptrace PTRACE_READDATA/WRITEDATA, kernel 2.5.62

> >+ 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:
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:
This speeds up everything... but the code needs some more testing, and a
port to 2.5.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.073 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site