Re: [PATCH] x86: Drop KGDB support

[Peter Zijlstra <peterz@infradead.org>]

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?