Skip to contentSkip to conversation

ia64 find thread for user rbs address

PATCH Superseded bibo,mao 2 participants 4 messages Nov 16, 2006 – Nov 17, 2006 ptrace support

lore
Share & tools
lore

bibo,mao

author
#0 lore raw

PATCH 1/1 ia64 find thread for user rbs address

hi,
I encountered one problem when running ptrace test case, the
situation is this: traced process's syscall parameter needs to be accessed, but for sys_clone system call with clone_flag (CLONE_VFORK | CLONE_VM | SIGCHLD) parameter. this syscall's parameter accessing result is wrong.
The reason is that with clone_flag(CLONE_VFORK | CLONE_VM | SIGCHLD),
cloned thread's mm point is the same, but tgid is different. without this patch find_thread_for_addr will return cloned thread, but not the thread which call sys_clone syscall.

thanks
bibo,mao

arch/ia64/kernel/ptrace.c +1 -1
@@ -607,7 +607,7 @@ find_thread_for_addr (struct task_struct
 	 */
  	list_for_each_safe(this, next, &current->children) {
 		p = list_entry(this, struct task_struct, sibling);
-		if (p->mm != mm)
+		if (p->tgid != child->tgid)
 			continue;
 		if (thread_matches(p, addr)) {
 			child = p;
author
#1 lore raw

Tony,
please discard this patch. It can not fix completely. If ptrace caller wants to access vforked child process's user rbs, there will be problem.

thanks
bibo,mao

Quoted 30 lines · bibo,mao

hi,
I encountered one problem when running ptrace test case, the
situation is this: traced process's syscall parameter needs to be accessed, but for sys_clone system call with clone_flag (CLONE_VFORK | CLONE_VM | SIGCHLD) parameter. this syscall's parameter accessing result is wrong.
The reason is that with clone_flag(CLONE_VFORK | CLONE_VM | SIGCHLD),
cloned thread's mm point is the same, but tgid is different. without this patch find_thread_for_addr will return cloned thread, but not the thread which call sys_clone syscall.

thanks
bibo,mao

arch/ia64/kernel/ptrace.c 2006-11-16 16:25:07.000000000 +0800 renamed from arch/ia64/kernel/ptrace.c 2006-11-16 16:23:31.000000000 +0800 +1 -2
@@ -607,7 +607,7 @@ find_thread_for_addr (struct task_struct
         */
        list_for_each_safe(this, next, &current->children) {
                p = list_entry(this, struct task_struct, sibling);
-               if (p->mm != mm)
+               if (p->tgid != child->tgid)
                        continue;
                if (thread_matches(p, addr)) {
                        child = p;
-

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
In reply to bibo,mao
Quoted 4 lines · bibo,mao

Tony,
please discard this patch. It can not fix completely. If ptrace caller wants to access vforked child process's user rbs, there will be problem.

The patch is correct.

If ptracer wants to access vforked child process's user rbs, find_thread_for_addr's first parameter, child, will points to the vforked task_struct instead of vforker's.

Quoted 31 lines

thanks
bibo,mao

Quoted 26 lines · bibo,mao

hi,
I encountered one problem when running ptrace test case, the
situation is this: traced process's syscall parameter needs to be accessed, but for sys_clone system call with clone_flag (CLONE_VFORK | CLONE_VM | SIGCHLD) parameter. this syscall's parameter accessing result is wrong.
The reason is that with clone_flag(CLONE_VFORK | CLONE_VM | SIGCHLD),
cloned thread's mm point is the same, but tgid is different. without this patch find_thread_for_addr will return cloned thread, but not the thread which call sys_clone syscall.

thanks
bibo,mao

arch/ia64/kernel/ptrace.c 2006-11-16 16:25:07.000000000 +0800 renamed from arch/ia64/kernel/ptrace.c 2006-11-16 16:23:31.000000000 +0800 +1 -2
@@ -607,7 +607,7 @@ find_thread_for_addr (struct task_struct
         */
        list_for_each_safe(this, next, &current->children) {
                p = list_entry(this, struct task_struct, sibling);
-               if (p->mm != mm)
+               if (p->tgid != child->tgid)
                        continue;
                if (thread_matches(p, addr)) {
                        child = p;
-
author
#3 lore raw
In reply to bibo,mao
Quoted 10 lines · Yanmin
Quoted 4 lines · bibo,mao

Tony,
please discard this patch. It can not fix completely. If ptrace caller wants to access vforked child process's user rbs, there will be problem.

The patch is correct.

If ptracer wants to access vforked child process's user rbs, find_thread_for_addr's first parameter, child, will points to the vforked task_struct instead of vforker's.

oh, I get messed with it. If ptracer wants to trace vforked child process, then pid should be vforked process's pid but not vforker parent process's pid. Then this parch is corrent.

thanks
bibo,mao

Quoted 32 lines
Quoted 31 lines

thanks
bibo,mao

Quoted 26 lines · bibo,mao

hi,
I encountered one problem when running ptrace test case, the
situation is this: traced process's syscall parameter needs to be accessed, but for sys_clone system call with clone_flag (CLONE_VFORK | CLONE_VM | SIGCHLD) parameter. this syscall's parameter accessing result is wrong.
The reason is that with clone_flag(CLONE_VFORK | CLONE_VM | SIGCHLD),
cloned thread's mm point is the same, but tgid is different. without this patch find_thread_for_addr will return cloned thread, but not the thread which call sys_clone syscall.

thanks
bibo,mao

arch/ia64/kernel/ptrace.c 2006-11-16 16:25:07.000000000 +0800 renamed from arch/ia64/kernel/ptrace.c 2006-11-16 16:23:31.000000000 +0800 +1 -2
@@ -607,7 +607,7 @@ find_thread_for_addr (struct task_struct
         */
        list_for_each_safe(this, next, &current->children) {
                p = list_entry(this, struct task_struct, sibling);
-               if (p->mm != mm)
+               if (p->tgid != child->tgid)
                        continue;
                if (thread_matches(p, addr)) {
                        child = p;
-