do_bp() is running notify_die() for certain break codes, then invokes do_trap_or_bp() which is going to run notify_die() yet again. So it is possible that notify_die() gets invoked twice. This has caused some issues for my current project me but I'm wondering especially about the existing code base, what is the intent here, what notifiers do debuggers or tracers actually expect to be run, in what order? Another observation is that the die notifier can be a relativly busy place because the kernel FP software is running it for every instruction emulated in a branch delay slot which is bad in particular when a distribution built for hard floating point is running on FPU-less hardware, as in my case Debian on an Octeon. The increasing number of die notifier functions has been silently slowing down the kernel fp software over the years. Which nobody has looked at because the FPU emulator has been so reliable that nobody ever looked at it. I'm wondering, should we create a fast path for the FPU emulator only by skipping the die notifier? Ralf