On Fri, Jul 17, 2020 at 03:39:58PM -0700, Doug Anderson wrote: > Hi, > > On Thu, Jul 16, 2020 at 8:20 AM Daniel Thompson > <daniel.thomp...@linaro.org> wrote: > > > > Currently kgdb honours the kprobe blocklist but doesn't place its own > > trap handling code on the list. Add labels to discourage attempting to > > use kgdb to debug itself. > > > > These changes do not make it impossible to provoke recursive trapping > > since they do not cover all the calls that can be made on kgdb's entry > > logic. However going much further whilst we are sharing the kprobe > > blocklist risks reducing the capabilities of kprobe and this would be a > > bad trade off (especially so given kgdb's users are currently conditioned > > to avoid recursive traps). > > > > Signed-off-by: Daniel Thompson <daniel.thomp...@linaro.org> > > --- > > kernel/debug/debug_core.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > I could just be missing something, but... > > I understand not adding "NOKPROBE_SYMBOL" to generic kernel functions > that kgdb happens to call, but I'm not quite sure I understand why all > of the kdb / kgdb code itself shouldn't be in the blocklist. I > certainly don't object to the functions you added to the blocklist, I > guess I'm must trying to understand why it's a bad idea to add more or > how you came up with the list of functions that you did.
Relatively early in the trap handler execution (just after we bring the other CPUs to a halt) all breakpoints are replaced with the original opcodes. Therefore I only marked up functions that run between the trap firing and the breakpoints being removed (and also between the breakpoints being reinstated and trap exit). Daniel. _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
