On 1/29/08, Ananth N Mavinakayanahalli <ananth@in.ibm.com> wrote:May be I'm completely off the mark here, but shouldn't a small subset of this section simply be 'breakpoint-free' rather than 'kprobe-free'? Placing a breakpoint on kprobe_handler (say) can loop into a recursive trap without allowing the debugger's notifier chain to be invoked. I'm assuming that non-kprobe exception notifiers may (or even should) run after kprobe's notifier callback (kprobe_exceptions_notify). This will still happen. It doesn't stop non-kprobe breakpoints from being handled, wherever they may be. Here's what seems to be happening currently: int3 (non-kprobe) -> do_int3 ->kprobe_exceptions_notify -> kprobe_handler (passes the buck to the kernel) -> non-krpobe/debugger exception handler. Here's what the patch will do: int3 (non-kprobe) -> do_int3 ->kprobe_exceptions_notify -> WARN_ON/kprobe_handler -> non-kprobe/debugger exception handler. The WARN_ON (and not a BUG_ON) will be hit iff: (in_kprobes_functions(addr) && !is_jprobe_bkpt(addr)) I hope I've understood the point you were making, or at least came close :-). -- Thanks, Abhishek --
| Jeremy Fitzhardinge | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Mike Galbraith | Re: regression: CD burning (k3b) went broke |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Linus Torvalds | Re: [GIT]: Networking |
| Michael Grollman | Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945... |
