Re: [PATCH] x86: Drop KGDB support

[Masami Hiramatsu (Google)]

On Thu, 29 Oct 2026 10:34:38 +0000, David Laight <david.laight.linux@xxxxxxxxx> wrote:
> On Thu, 29 Oct 2026 09:46:06 +0100
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> 
> > On Wed, Oct 28, 2026 at 02:58:12PM -0500, Steve Wahl wrote:
> > > On Wed, Oct 28, 2026 at 08:10:54AM -0700, Dave Hansen wrote:  
> > > > On 10/28/26 07:26, Peter Zijlstra wrote:
> > > > ...  
> > > > > Also, when was the last time you used KGDB? I think I've tried it once,
> > > > > some 20 years ago, and haven't bothered since -- it was *that* good 🙂  
> > > > 
> > > > I can't remember the last time I used it. I also grepped through all of
> > > > my stashed-away kernel configs I've been using for the past 15 or so
> > > > years. The only place I even see it configured in is in distro-derived
> > > > configs. None of my trimmed down debug configs.
> > > > 
> > > > There seems to be approximately one clear commit that shows anyone using
> > > > the x86 kgdb.c in the last decade:
> > > > 
> > > > 	commit 71ab8323cc357c68985a2d6fc6cfc22b1dbbc1c3
> > > > 	Author: Matt Mullins <mmullins@xxxxxx>
> > > > 	Date:   Fri May 31 12:47:54 2019 -0700
> > > > 
> > > > 	    x86/kgdb: Return 0 from kgdb_arch_set_breakpoint()
> > > > 
> > > > The only question for me at this point would be whether we should just
> > > > config it out for a couple of releases rather than removing it outright.  
> > > 
> > > I have never used kgdb, but kdb is a different story.  I originally
> > > reacted quite poorly to this patch, assuming from what was changed
> > > in uv_nmi.c that both kgdb and kdb were being removed.
> > > 
> > > I would like to see the kdb action remain in uv_nmi.c, even when
> > > removing kgdb.  Is there a good reason why both were removed?  
> > 
> > kdb is just a local wrapper around the kgdb gunk. If we kept that, we'd
> > still have all of kgdb.
> > 
> > > There have been a number of times over the past few years, on large
> > > cpu count systems that aren't easy to configure for VM usage, where
> > > I have a problem that wedges the system or leaves it unresponsive,
> > > and I enable kdb, reproduce the problem, enter kdb via uv_nmi, just
> > > to dump the stack of all processors and find out what they are
> > > doing, and check other things that I can get to with kdb.  
> > 
> > So this uv_nmi thing looks a lot like sysrq; you could wire up one of
> > them things to use lib/nmi_backtrace.c to dump stacks for all CPUs, no?
> 
> Where would the output go to?
> The kernel message buffer is too short to be useful.
> For a smaller number of cpu something used IPI to get each cpu
> to dump_stack() in turn might be useful as a sysreq command.
> But I've usually resorted to cat '/proc/*/task/*/stack' (or a subset
> thereof) to find where processes are stuck.

Isn't it possible to use another external monitor like capturing
serial output to store the dump results (for logging all dumps)?

If this is intended solely for performing an in-memory post-mortem
analysis (without generating a crash dump) by leveraging KDB’s
debugging information interface, it might be possible to restrict
the functionality to just that purpose by new kconfig. (In this
scenario, the kernel should trigger a panic at the moment of the
interrupt to ensure no further processing occurs.)

IIUC, the core issue here is that intrusive KGDB interrupts—such
as breakpoints and watchpoints—disrupt the assumptions regarding
kernel consistency while the system is running. For examining
the state of an active, running system, tracing is a more
appropriate approach.

Thank you,

-- 
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>