On Tue, Sep 27, 2005 at 08:45:07AM -0600, Davda, Bhavesh P (Bhavesh) wrote:
> > No way! It needs to work the other way: allow the debugger to
> > short-circuit a signal for performance reasons if it wants to. Ptrace
> > is supposed to report all signals and debuggers expect it to do so.
> > It'd be pretty confusing if, say, you were trying to debug the SIGSEGV
> > handler in an application which did this.
> Then propose an alternative way where a real-time (SCHED_FIFO/SCHED_RR)
> CPU bound application getting lots of SEGVs for normal operation doesn't
> cause a priority inversion with the debugger getting SIGCHLDs for every
> SEGV and deciding to ignore it?
Read my reply above again, please. I did. It needs to be under
control of the tracer.
Also, this is far from the only problem you're going to have if you run
your debugger with lower priority than your debuggee.
> This way avoids the unnecessary context switch to the debugger, and is
> intended for use only by someone who knows darn sure that s/he will
> handle the signal safely, and don't mind if the debugger is not notified
> (in fact would love it if that's the case) on specific signals.
>
> IMHO this is a perfectly safe capability...
No. Ptrace is considered a security barrier; the tracee should not be
able to control what the tracer sees.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |