Re: [RFC] [PATCH] selective signal ptracing
On Mon, 2007-06-18 at 08:15 -0500, Josh Boyer wrote: > On 6/16/07, Roland McGrath <[EMAIL PROTECTED]> wrote: > > > What are the issues with arch like ARM ? > > > > The interesting class ARM belongs to is machines that don't (or don't > > always) have hardware support for single-step. Maintaining the status quo > > of how PTRACE_SINGLESTEP functions on these machines is different in > > implementation under utrace than it is for machines that always use > > hardware support. That is the only special complication for ARM, and it is > > not really very complicated. Apparently the way I described the issue in > > the past was easily misunderstood. > > That isn't just ARM. There are some embedded PowerPC chips that lack > an easily usable hardware single step. Just an FYI. Note that we could use xmon infrastructure for that ... Paul has the whole shebang done in there, including emulating branches etc... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
> Subject: Re: [RFC] [PATCH] selective signal ptracing
> From: Oleg Nesterov <[EMAIL PROTECTED]>
> Date: Sat, 16 Jun 2007 13:24:15 +0400
> To: John Blackwood <[EMAIL PROTECTED]>
> CC: Alan Cox <[EMAIL PROTECTED]>, Roland McGrath
<[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org
>
> John Blackwood wrote:
> > >
> > > By default all signals are ptraced as before. However, a debugger
> > > may now modify the set of per-task ptraced signals, where only the
> > > signals in this ptrace signal mask will be ptraced.
>
> I must admit, I agree with Roland...
>
> > > +void ptrace_update_traced_signals(struct task_struct *child,
> > > +sigset_t
*new_smaskp)
> > > +{
> > > [...snip...]
> > > +
> > > +spin_lock_irqsave(>sighand->siglock, flags);
> > > +
> > > +if (child->sighand == NULL) {
>
> How so?
>
> Oleg.
Hi Oleg.
Right, this above is not a good check for a NULL sighand.
Possibly, this routine could use something like the
rcu_read_lock()/lock_task_sighand() sequences used elsewhere
(shown below).
The whole ptrace_update_traced_signals() where we drain ignored signals
is not dealt with today by ptraced tasks when the debugger exits or
detaches from a target task. So this whole routine is not entirely
related just to selective signal ptracing.
Thanks for you input.
diff -rup linux-2.6.22-rc4-git5.old/kernel/exit.c
linux-2.6.22-rc4-git5.new/kernel/exit.c
--- linux-2.6.22-rc4-git5.old/kernel/exit.c 2007-06-18
14:36:09.0 -0400
+++ linux-2.6.22-rc4-git5.new/kernel/exit.c 2007-06-18
14:31:16.0 -0400
+/*
+ * void ptrace_update_traced_signals(
+ * struct task_struct *child, sigset_t *new_smaskp)
+ *
+ * Update the signal mask of ptraced signals, removing any ignored
+ * pending signals that are no longer ptraced. 'new_smaskp' points
+ * to the new ptrace signal mask which will be stored into
+ * child->ptrace_sigmask.
+ */
+void ptrace_update_traced_signals(struct task_struct *child,
+ sigset_t *new_smaskp)
+{
+ int sig = 0, index = 0;
+ unsigned long int flags;
+ sigset_t prev_smask;
+
+ /* Get signals that were previously, but no longer ptraced. */
+ signandsets(_smask, >ptrace_sigmask, new_smaskp);
+ child->ptrace_sigmask = *new_smaskp;
+ rcu_read_lock();
+ while (!sigisemptyset(_smask)) {
+ while (index < _NSIG_WORDS) {
+ if (prev_smask.sig[index]) {
+ sig = ffz(~prev_smask.sig[index]) +
+ (index * _NSIG_BPW) + 1;
+ break;
+ }
+ index++;
+ }
+ /* Remove signal from the previously ptraced signal mask. */
+ sigdelset(_smask, sig);
+
+ if (!lock_task_sighand(child, )) {
+ /* This task is exiting, so just return. */
+ unlock_task_sighand(child, );
+ rcu_read_unlock();
+ return;
+ }
+ if (!sig_ignored(child, sig)) {
+ unlock_task_sighand(child, );
+ continue;
+ }
+ /* Remove any queued signals - they should now be ignored. */
+ rm_from_queue(sigmask(sig), >pending);
+ rm_from_queue(sigmask(sig), >signal->shared_pending);
+ unlock_task_sighand(child, );
+ }
+ rcu_read_unlock();
+}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
On 6/16/07, Roland McGrath <[EMAIL PROTECTED]> wrote: > What are the issues with arch like ARM ? The interesting class ARM belongs to is machines that don't (or don't always) have hardware support for single-step. Maintaining the status quo of how PTRACE_SINGLESTEP functions on these machines is different in implementation under utrace than it is for machines that always use hardware support. That is the only special complication for ARM, and it is not really very complicated. Apparently the way I described the issue in the past was easily misunderstood. That isn't just ARM. There are some embedded PowerPC chips that lack an easily usable hardware single step. Just an FYI. josh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
On 6/16/07, Roland McGrath [EMAIL PROTECTED] wrote: What are the issues with arch like ARM ? The interesting class ARM belongs to is machines that don't (or don't always) have hardware support for single-step. Maintaining the status quo of how PTRACE_SINGLESTEP functions on these machines is different in implementation under utrace than it is for machines that always use hardware support. That is the only special complication for ARM, and it is not really very complicated. Apparently the way I described the issue in the past was easily misunderstood. That isn't just ARM. There are some embedded PowerPC chips that lack an easily usable hardware single step. Just an FYI. josh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
Subject: Re: [RFC] [PATCH] selective signal ptracing
From: Oleg Nesterov [EMAIL PROTECTED]
Date: Sat, 16 Jun 2007 13:24:15 +0400
To: John Blackwood [EMAIL PROTECTED]
CC: Alan Cox [EMAIL PROTECTED], Roland McGrath
[EMAIL PROTECTED], linux-kernel@vger.kernel.org
John Blackwood wrote:
By default all signals are ptraced as before. However, a debugger
may now modify the set of per-task ptraced signals, where only the
signals in this ptrace signal mask will be ptraced.
I must admit, I agree with Roland...
+void ptrace_update_traced_signals(struct task_struct *child,
+sigset_t
*new_smaskp)
+{
[...snip...]
+
+spin_lock_irqsave(child-sighand-siglock, flags);
+
+if (child-sighand == NULL) {
How so?
Oleg.
Hi Oleg.
Right, this above is not a good check for a NULL sighand.
Possibly, this routine could use something like the
rcu_read_lock()/lock_task_sighand() sequences used elsewhere
(shown below).
The whole ptrace_update_traced_signals() where we drain ignored signals
is not dealt with today by ptraced tasks when the debugger exits or
detaches from a target task. So this whole routine is not entirely
related just to selective signal ptracing.
Thanks for you input.
diff -rup linux-2.6.22-rc4-git5.old/kernel/exit.c
linux-2.6.22-rc4-git5.new/kernel/exit.c
--- linux-2.6.22-rc4-git5.old/kernel/exit.c 2007-06-18
14:36:09.0 -0400
+++ linux-2.6.22-rc4-git5.new/kernel/exit.c 2007-06-18
14:31:16.0 -0400
+/*
+ * void ptrace_update_traced_signals(
+ * struct task_struct *child, sigset_t *new_smaskp)
+ *
+ * Update the signal mask of ptraced signals, removing any ignored
+ * pending signals that are no longer ptraced. 'new_smaskp' points
+ * to the new ptrace signal mask which will be stored into
+ * child-ptrace_sigmask.
+ */
+void ptrace_update_traced_signals(struct task_struct *child,
+ sigset_t *new_smaskp)
+{
+ int sig = 0, index = 0;
+ unsigned long int flags;
+ sigset_t prev_smask;
+
+ /* Get signals that were previously, but no longer ptraced. */
+ signandsets(prev_smask, child-ptrace_sigmask, new_smaskp);
+ child-ptrace_sigmask = *new_smaskp;
+ rcu_read_lock();
+ while (!sigisemptyset(prev_smask)) {
+ while (index _NSIG_WORDS) {
+ if (prev_smask.sig[index]) {
+ sig = ffz(~prev_smask.sig[index]) +
+ (index * _NSIG_BPW) + 1;
+ break;
+ }
+ index++;
+ }
+ /* Remove signal from the previously ptraced signal mask. */
+ sigdelset(prev_smask, sig);
+
+ if (!lock_task_sighand(child, flags)) {
+ /* This task is exiting, so just return. */
+ unlock_task_sighand(child, flags);
+ rcu_read_unlock();
+ return;
+ }
+ if (!sig_ignored(child, sig)) {
+ unlock_task_sighand(child, flags);
+ continue;
+ }
+ /* Remove any queued signals - they should now be ignored. */
+ rm_from_queue(sigmask(sig), child-pending);
+ rm_from_queue(sigmask(sig), child-signal-shared_pending);
+ unlock_task_sighand(child, flags);
+ }
+ rcu_read_unlock();
+}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
On Mon, 2007-06-18 at 08:15 -0500, Josh Boyer wrote: On 6/16/07, Roland McGrath [EMAIL PROTECTED] wrote: What are the issues with arch like ARM ? The interesting class ARM belongs to is machines that don't (or don't always) have hardware support for single-step. Maintaining the status quo of how PTRACE_SINGLESTEP functions on these machines is different in implementation under utrace than it is for machines that always use hardware support. That is the only special complication for ARM, and it is not really very complicated. Apparently the way I described the issue in the past was easily misunderstood. That isn't just ARM. There are some embedded PowerPC chips that lack an easily usable hardware single step. Just an FYI. Note that we could use xmon infrastructure for that ... Paul has the whole shebang done in there, including emulating branches etc... Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
> What are the issues with arch like ARM ? The interesting class ARM belongs to is machines that don't (or don't always) have hardware support for single-step. Maintaining the status quo of how PTRACE_SINGLESTEP functions on these machines is different in implementation under utrace than it is for machines that always use hardware support. That is the only special complication for ARM, and it is not really very complicated. Apparently the way I described the issue in the past was easily misunderstood. > Also, is there a mail thread or paper somewhere describing utrace, its > interfaces and what's needed to hook it up on a platform ? See http://redhat.com/~roland/utrace/ for the patches and a porting howto. The patches add a Documentation/ file and kerneldoc stuff for the interfaces. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
On Sat, 2007-06-16 at 00:26 +0100, Alan Cox wrote: > On Fri, 15 Jun 2007 12:42:29 -0700 (PDT) > Roland McGrath <[EMAIL PROTECTED]> wrote: > > > I am not in favor of any enhancements to the ptrace interface. > > It is a terrible interface and just needs to die. > > That might make sense if utrace ever looked like it would solve the > questions about platforms like ARM What are the issues with arch like ARM ? Also, is there a mail thread or paper somewhere describing utrace, its interfaces and what's needed to hook it up on a platform ? /me mostly missed that train Thanks ! Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
John Blackwood wrote:
>
> By default all signals are ptraced as before. However, a debugger
> may now modify the set of per-task ptraced signals, where only the
> signals in this ptrace signal mask will be ptraced.
I must admit, I agree with Roland...
> +void ptrace_update_traced_signals(struct task_struct *child,
> + sigset_t *new_smaskp)
> +{
> [...snip...]
> +
> + spin_lock_irqsave(>sighand->siglock, flags);
> +
> + if (child->sighand == NULL) {
How so?
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
John Blackwood wrote:
By default all signals are ptraced as before. However, a debugger
may now modify the set of per-task ptraced signals, where only the
signals in this ptrace signal mask will be ptraced.
I must admit, I agree with Roland...
+void ptrace_update_traced_signals(struct task_struct *child,
+ sigset_t *new_smaskp)
+{
[...snip...]
+
+ spin_lock_irqsave(child-sighand-siglock, flags);
+
+ if (child-sighand == NULL) {
How so?
Oleg.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
On Sat, 2007-06-16 at 00:26 +0100, Alan Cox wrote: On Fri, 15 Jun 2007 12:42:29 -0700 (PDT) Roland McGrath [EMAIL PROTECTED] wrote: I am not in favor of any enhancements to the ptrace interface. It is a terrible interface and just needs to die. That might make sense if utrace ever looked like it would solve the questions about platforms like ARM What are the issues with arch like ARM ? Also, is there a mail thread or paper somewhere describing utrace, its interfaces and what's needed to hook it up on a platform ? /me mostly missed that train Thanks ! Cheers, Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
What are the issues with arch like ARM ? The interesting class ARM belongs to is machines that don't (or don't always) have hardware support for single-step. Maintaining the status quo of how PTRACE_SINGLESTEP functions on these machines is different in implementation under utrace than it is for machines that always use hardware support. That is the only special complication for ARM, and it is not really very complicated. Apparently the way I described the issue in the past was easily misunderstood. Also, is there a mail thread or paper somewhere describing utrace, its interfaces and what's needed to hook it up on a platform ? See http://redhat.com/~roland/utrace/ for the patches and a porting howto. The patches add a Documentation/ file and kerneldoc stuff for the interfaces. Thanks, Roland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
> That might make sense if utrace ever looked like it would solve the > questions about platforms like ARM It certainly will. The only difficult limitations have been in communication and understanding. Please don't perpetuate a generic red herring without adding any content to the subject. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
On Fri, 15 Jun 2007 12:42:29 -0700 (PDT) Roland McGrath <[EMAIL PROTECTED]> wrote: > I am not in favor of any enhancements to the ptrace interface. > It is a terrible interface and just needs to die. That might make sense if utrace ever looked like it would solve the questions about platforms like ARM - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
I am not in favor of any enhancements to the ptrace interface. It is a terrible interface and just needs to die. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] [PATCH] selective signal ptracing
Selective Ptraced Signal Support - A proposed enhancement
This is a proposal for a ptrace enhancement that adds two new ptrace(2)
commands that let a debugger view and modify the set of signals that
are being ptraced.
By default all signals are ptraced as before. However, a debugger
may now modify the set of per-task ptraced signals, where only the
signals in this ptrace signal mask will be ptraced.
Signals that are not being ptraced will be handled normally by the ptraced
process, and no notification will be passed on to the debugger process.
Only ptraced signals that are received by the ptraced task will cause
that task to stop and notify the debugger.
This new ptrace selective signal support provides a method for improving
debug session performance and for reducing the amount of ptrace-related
interference of a ptraced process, particularly when an an application
is making use of one or more signals that are not currently of interest
to the debug session, but are occuring frequently.
The command interfaces are:
long int ptrace(enum __ptrace_request request,
pid_t target_pid, void *addr, void *data)
request:
When PTRACE_SETSIGTRACE is specified, then the set of signals
in the sigset_t structure (pointed to by the data
parameter) will become the set of signals that are ptraced for
the target process.
When PTRACE_GETSIGTRACE is specified, then the current set
of ptraced signals will be returned at the sigset_t structure
location (pointed to by the data parameter).
pid: pid of the target/ptraced task
addr: not used
data: pointer to a sigset_t structure
Tasks that have the PTRACE_O_TRACEFORK, PTRACE_O_TRACECLONE
or PTRACE_O_TRACECLONE option set at the time of a fork, vfork or clone
call that are currently being ptraced will yield child tasks
that inherited their parent task's ptrace signal mask.
When single-stepping and a user's signal handler is executed, the ptraced
task only single-steps/stops in the signal handler if that signal is in
the ptraced signal mask. Otherwise, the ptraced task will execute the
entire signal handler and then stop at the next instruction in the normal
(non-signal related) execution flow.
The proposed patch below implements ptrace selective signal ptracing
for the i386 and x86_64 architecutres. Other architectures will ptrace
all signals, in the same way as before.
diff -rup linux-2.6.22-rc4-git5.orig/arch/i386/kernel/ptrace.c
linux-2.6.22-rc4-git5.new/arch/i386/kernel/ptrace.c
--- linux-2.6.22-rc4-git5.orig/arch/i386/kernel/ptrace.c 2007-06-13
09:46:37.0 -0400
+++ linux-2.6.22-rc4-git5.new/arch/i386/kernel/ptrace.c 2007-06-13
17:00:38.0 -0400
@@ -620,6 +620,44 @@ long arch_ptrace(struct task_struct *chi
(struct user_desc __user *) data);
break;
+ case PTRACE_GETSIGTRACE: { /* Get the set of ptraced signals. */
+ int i;
+
+ if (!access_ok(VERIFY_WRITE, datap, sizeof(sigset_t))) {
+ ret = -EIO;
+ break;
+ }
+ for (i = 0; i < _NSIG_WORDS; i++) {
+ ret = __put_user(child->ptrace_sigmask.sig[i], datap);
+ if (ret)
+ break;
+ datap++;
+ }
+ break;
+ }
+
+ case PTRACE_SETSIGTRACE: { /* Set ptraced signal mask. */
+ int i;
+ sigset_t new_smask;
+
+ if (!access_ok( VERIFY_READ, datap, sizeof(sigset_t))) {
+ ret = -EIO;
+ break;
+ }
+ for (i = 0; i < _NSIG_WORDS; i++) {
+ ret = __get_user(new_smask.sig[i], datap);
+ if (ret)
+ break;
+ datap++;
+ }
+ if (ret)
+ break;
+
+ /* Update child task's ptrace signal mask. */
+ ptrace_update_traced_signals(child, _smask);
+ break;
+ }
+
default:
ret = ptrace_request(child, request, addr, data);
break;
diff -rup linux-2.6.22-rc4-git5.orig/arch/i386/kernel/signal.c
linux-2.6.22-rc4-git5.new/arch/i386/kernel/signal.c
--- linux-2.6.22-rc4-git5.orig/arch/i386/kernel/signal.c 2007-06-13
09:46:37.0 -0400
+++ linux-2.6.22-rc4-git5.new/arch/i386/kernel/signal.c 2007-06-13
17:00:38.0 -0400
@@ -393,8 +393,12 @@ static int setup_frame(int sig, struct k
* handler too.
*/
regs->eflags &= ~TF_MASK;
- if (test_thread_flag(TIF_SINGLESTEP))
- ptrace_notify(SIGTRAP);
+ if (test_thread_flag(TIF_SINGLESTEP)) {
+ if (sigismember(>ptrace_sigmask, sig))
+ ptrace_notify(SIGTRAP);
+
[RFC] [PATCH] selective signal ptracing
Selective Ptraced Signal Support - A proposed enhancement
This is a proposal for a ptrace enhancement that adds two new ptrace(2)
commands that let a debugger view and modify the set of signals that
are being ptraced.
By default all signals are ptraced as before. However, a debugger
may now modify the set of per-task ptraced signals, where only the
signals in this ptrace signal mask will be ptraced.
Signals that are not being ptraced will be handled normally by the ptraced
process, and no notification will be passed on to the debugger process.
Only ptraced signals that are received by the ptraced task will cause
that task to stop and notify the debugger.
This new ptrace selective signal support provides a method for improving
debug session performance and for reducing the amount of ptrace-related
interference of a ptraced process, particularly when an an application
is making use of one or more signals that are not currently of interest
to the debug session, but are occuring frequently.
The command interfaces are:
long int ptrace(enum __ptrace_request request,
pid_t target_pid, void *addr, void *data)
request:
When PTRACE_SETSIGTRACE is specified, then the set of signals
in the sigset_t structure (pointed to by the data
parameter) will become the set of signals that are ptraced for
the target process.
When PTRACE_GETSIGTRACE is specified, then the current set
of ptraced signals will be returned at the sigset_t structure
location (pointed to by the data parameter).
pid: pid of the target/ptraced task
addr: not used
data: pointer to a sigset_t structure
Tasks that have the PTRACE_O_TRACEFORK, PTRACE_O_TRACECLONE
or PTRACE_O_TRACECLONE option set at the time of a fork, vfork or clone
call that are currently being ptraced will yield child tasks
that inherited their parent task's ptrace signal mask.
When single-stepping and a user's signal handler is executed, the ptraced
task only single-steps/stops in the signal handler if that signal is in
the ptraced signal mask. Otherwise, the ptraced task will execute the
entire signal handler and then stop at the next instruction in the normal
(non-signal related) execution flow.
The proposed patch below implements ptrace selective signal ptracing
for the i386 and x86_64 architecutres. Other architectures will ptrace
all signals, in the same way as before.
diff -rup linux-2.6.22-rc4-git5.orig/arch/i386/kernel/ptrace.c
linux-2.6.22-rc4-git5.new/arch/i386/kernel/ptrace.c
--- linux-2.6.22-rc4-git5.orig/arch/i386/kernel/ptrace.c 2007-06-13
09:46:37.0 -0400
+++ linux-2.6.22-rc4-git5.new/arch/i386/kernel/ptrace.c 2007-06-13
17:00:38.0 -0400
@@ -620,6 +620,44 @@ long arch_ptrace(struct task_struct *chi
(struct user_desc __user *) data);
break;
+ case PTRACE_GETSIGTRACE: { /* Get the set of ptraced signals. */
+ int i;
+
+ if (!access_ok(VERIFY_WRITE, datap, sizeof(sigset_t))) {
+ ret = -EIO;
+ break;
+ }
+ for (i = 0; i _NSIG_WORDS; i++) {
+ ret = __put_user(child-ptrace_sigmask.sig[i], datap);
+ if (ret)
+ break;
+ datap++;
+ }
+ break;
+ }
+
+ case PTRACE_SETSIGTRACE: { /* Set ptraced signal mask. */
+ int i;
+ sigset_t new_smask;
+
+ if (!access_ok( VERIFY_READ, datap, sizeof(sigset_t))) {
+ ret = -EIO;
+ break;
+ }
+ for (i = 0; i _NSIG_WORDS; i++) {
+ ret = __get_user(new_smask.sig[i], datap);
+ if (ret)
+ break;
+ datap++;
+ }
+ if (ret)
+ break;
+
+ /* Update child task's ptrace signal mask. */
+ ptrace_update_traced_signals(child, new_smask);
+ break;
+ }
+
default:
ret = ptrace_request(child, request, addr, data);
break;
diff -rup linux-2.6.22-rc4-git5.orig/arch/i386/kernel/signal.c
linux-2.6.22-rc4-git5.new/arch/i386/kernel/signal.c
--- linux-2.6.22-rc4-git5.orig/arch/i386/kernel/signal.c 2007-06-13
09:46:37.0 -0400
+++ linux-2.6.22-rc4-git5.new/arch/i386/kernel/signal.c 2007-06-13
17:00:38.0 -0400
@@ -393,8 +393,12 @@ static int setup_frame(int sig, struct k
* handler too.
*/
regs-eflags = ~TF_MASK;
- if (test_thread_flag(TIF_SINGLESTEP))
- ptrace_notify(SIGTRAP);
+ if (test_thread_flag(TIF_SINGLESTEP)) {
+ if (sigismember(current-ptrace_sigmask, sig))
+ ptrace_notify(SIGTRAP);
+
Re: [RFC] [PATCH] selective signal ptracing
I am not in favor of any enhancements to the ptrace interface. It is a terrible interface and just needs to die. Thanks, Roland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
On Fri, 15 Jun 2007 12:42:29 -0700 (PDT) Roland McGrath [EMAIL PROTECTED] wrote: I am not in favor of any enhancements to the ptrace interface. It is a terrible interface and just needs to die. That might make sense if utrace ever looked like it would solve the questions about platforms like ARM - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] selective signal ptracing
That might make sense if utrace ever looked like it would solve the questions about platforms like ARM It certainly will. The only difficult limitations have been in communication and understanding. Please don't perpetuate a generic red herring without adding any content to the subject. Thanks, Roland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
