* ptrace() behaviour when doing PTRACE_KILL [not found] <20110830133056.GA18302@redhat.com> @ 2011-08-30 21:02 ` Pablo Antonio 0 siblings, 0 replies; 4+ messages in thread From: Pablo Antonio @ 2011-08-30 21:02 UTC (permalink / raw) To: kernelnewbies Hi Oleg, On Tue, Aug 30, 2011 at 10:30 AM, Oleg Nesterov <oleg@redhat.com> wrote: > Pablo Antonio wrote: >> >> Hello, >> ? ?I was writing some user code that uses the ptrace() system call >> and found it wasn't behaving as I expected. Maybe this is simply >> because I don't know enough about ptrace()'s behaviour, so I'd like >> someone to enlighten me with some information. > > First of all, please never use PTRACE_KILL. it is more or less > equivalent to ptrace(PTRACE_CONT, pid, 0, SIGKILL) but doesn't return > the error. > >> So, here's the code: http://codepad.org/TJ7Lua4Q Basically, > > I assume you run it on 32bit machine... otherwise you need > "8 * ORIG_RAX" and "8 * RAX". Yes, x86-32. > >> I was >> expecting the parent process to kill the child when the later >> attempted to use the kill() system call, not letting it send signals >> to other processes. I had done this before with pretty much the same >> code, but instead of killing when kill() was called, I was doing it >> when a fork() or clone() was attempted. And it worked. > > Because do_fork() checks signal_pending() and aborts if the process > is killed (actually it aborts if any signal is pending). > >> But now that I'm doing the same thing with kill(), I'm seeing that the >> child process ends up killed, as expected, but the signal is sent >> nonetheless. I understand that when I do the PTRACE_KILL, a SIGKILL >> signal is sent to the child. And PTRACE_KILL is used on syscall >> entrance in that code. If the SIGKILL signal is delivered to the >> process before it continues executing the system call in kernelspace, > > In this particular case SIGKILL was already delivered, yes. > >> then I don't understand why this code doesn't work as expected. > > Because you didn't abort this syscall. The tracee calls sys_kill() > which doesn't check the signals, the pending SIGKILL will be noticed > later, when the tracee attampts to return to the user-mode. > > This is correct. Most of non-blocking syscalls do not check the > signals, this is pointless. Thanks for your answer, Oleg. What you are saying makes sense to me, but I must say that I talked with some people (one of them was a GDB developer, the other was Denys Vlasenko) and they tested the code I you saw with different kernels and the signal was inhibited. Both of them, I think, were using redhat/fedora kernels. Maybe there's a race condition happening, maybe redhat/fedora kernels have different behaviour, I don't know. But I guess that if there's a difference in behaviour between vanilla and fedora/redhat kernels, that should be fixed. Thanks for your time, -- Pablo Antonio (AKA crazy2k) http://www.pablo-a.com.ar/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* ptrace() behaviour when doing PTRACE_KILL @ 2011-08-28 18:43 Pablo Antonio [not found] ` <CAK1XTrvyEYOYWjv2pUp2bhaAWqnMGz_cxkAh=f7LYFhTigBJXg@mail.gmail.com> 0 siblings, 1 reply; 4+ messages in thread From: Pablo Antonio @ 2011-08-28 18:43 UTC (permalink / raw) To: linux-kernel Hello, I was writing some user code that uses the ptrace() system call and found it wasn't behaving as I expected. Maybe this is simply because I don't know enough about ptrace()'s behaviour, so I'd like someone to enlighten me with some information. So, here's the code: http://codepad.org/TJ7Lua4Q Basically, I was expecting the parent process to kill the child when the later attempted to use the kill() system call, not letting it send signals to other processes. I had done this before with pretty much the same code, but instead of killing when kill() was called, I was doing it when a fork() or clone() was attempted. And it worked. If the child process tried to create a new process via fork() or clone(), then it was immediately killed and no process was created. But now that I'm doing the same thing with kill(), I'm seeing that the child process ends up killed, as expected, but the signal is sent nonetheless. I understand that when I do the PTRACE_KILL, a SIGKILL signal is sent to the child. And PTRACE_KILL is used on syscall entrance in that code. If the SIGKILL signal is delivered to the process before it continues executing the system call in kernelspace, then I don't understand why this code doesn't work as expected. If the signal is delivered after the system call is completely executed, then I don't understand why this was working for the fork() and clone() case. I'd really appreciate if someone told me what's happening here, or what I'm not seeing. Thanks, -- Pablo Antonio (AKA crazy2k) http://www.pablo-a.com.ar/ ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <CAK1XTrvyEYOYWjv2pUp2bhaAWqnMGz_cxkAh=f7LYFhTigBJXg@mail.gmail.com>]
* ptrace() behaviour when doing PTRACE_KILL [not found] ` <CAK1XTrvyEYOYWjv2pUp2bhaAWqnMGz_cxkAh=f7LYFhTigBJXg@mail.gmail.com> @ 2011-08-29 7:47 ` Pablo Antonio 2011-08-29 14:58 ` Mulyadi Santosa 0 siblings, 1 reply; 4+ messages in thread From: Pablo Antonio @ 2011-08-29 7:47 UTC (permalink / raw) To: kernelnewbies Hello, ? ?I was writing some user code that uses the ptrace() system call and found it wasn't behaving as I expected. Maybe this is simply because I don't know enough about ptrace()'s behaviour, so I'd like someone to enlighten me with some information. So, here's the code: http://codepad.org/TJ7Lua4Q Basically, I was expecting the parent process to kill the child when the later attempted to use the kill() system call, not letting it send signals to other processes. I had done this before with pretty much the same code, but instead of killing when kill() was called, I was doing it when a fork() or clone() was attempted. And it worked. If the child process tried to create a new process via fork() or clone(), then it was immediately killed and no process was created. But now that I'm doing the same thing with kill(), I'm seeing that the child process ends up killed, as expected, but the signal is sent nonetheless. I understand that when I do the PTRACE_KILL, a SIGKILL signal is sent to the child. And PTRACE_KILL is used on syscall entrance in that code. If the SIGKILL signal is delivered to the process before it continues executing the system call in kernelspace, then I don't understand why this code doesn't work as expected. If the signal is delivered after the system call is completely executed, then I don't understand why this was working for the fork() and clone() case. I'd really appreciate if someone told me what's happening here, or what I'm not seeing. Thanks, -- Pablo Antonio (AKA crazy2k) http://www.pablo-a.com.ar/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* ptrace() behaviour when doing PTRACE_KILL 2011-08-29 7:47 ` Pablo Antonio @ 2011-08-29 14:58 ` Mulyadi Santosa 0 siblings, 0 replies; 4+ messages in thread From: Mulyadi Santosa @ 2011-08-29 14:58 UTC (permalink / raw) To: kernelnewbies Hi pablo.... On Mon, Aug 29, 2011 at 14:47, Pablo Antonio <pabloa@gmail.com> wrote: If the > signal is delivered after the system call is completely executed, then > I don't understand why this was working for the fork() and clone() > case. > > I'd really appreciate if someone told me what's happening here, or > what I'm not seeing. I don't really get your question perfectly, but I guess you're questioning about why kill() gets different result than fork()/clone in term of order? I guess that is the result of fork policy. Child, in Linux, AFAIK is executed after parent. This is controlled via /proc/sys/kernel/sched_child_runs_first. The effect is that, as you can imagine, that parent take control first on anything over child. If you change it, then child has a chance to do something ahead. Again, I don't claim I know your question perfectly, so as usual CMIIW. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-08-30 21:02 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20110830133056.GA18302@redhat.com> 2011-08-30 21:02 ` ptrace() behaviour when doing PTRACE_KILL Pablo Antonio 2011-08-28 18:43 Pablo Antonio [not found] ` <CAK1XTrvyEYOYWjv2pUp2bhaAWqnMGz_cxkAh=f7LYFhTigBJXg@mail.gmail.com> 2011-08-29 7:47 ` Pablo Antonio 2011-08-29 14:58 ` Mulyadi Santosa
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.