Re: [PATCH] x86: Drop KGDB support

[David Laight <david.laight.linux@gmail.com>]

On Fri, 30 Oct 2026 11:00:29 +0900
"Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:

> On Thu, 29 Oct 2026 10:34:38 +0000, David Laight <david.laight.linux@gmail.com> wrote:
> > On Thu, 29 Oct 2026 09:46:06 +0100
> > Peter Zijlstra <peterz@infradead.org> 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@fb.com>
> > > > > 	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.

Just writing all the stacks to a serial terminal is likely to be griefsome.
It will take ages and would probably have to be done from a context
where you can neither (sensibly) spin or have enough buffers space
to cache everything.

Assuming the system is partially working something like using a IPI
to get the stack copied into a memory buffer/page which can then be
dealt with in a more normal context before requesting the stack of
the next cpu.
Yes, it won't be as good a snapshot as absolutely possible, but is
likely to be good enough.

David


> 
> Thank you,
>