Re: [PATCH] x86: Drop KGDB support

[David Laight]

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.

David