Re: [PATCH] x86: Drop KGDB support

[Steve Wahl]

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?

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.

It's a much lighter weight tool than taking a kdump and bringing it
up under crash, and the additional information you can gather from a
live debugger is sometimes useful.

For an example, I recently used this method to discover that at
least one version of Intel's MPI library likes to read up
/proc/kallsyms from each of the processes it starts, and somewhere
north of 1000's of processors the atomic increment on opening
kallsyms, implemented with a compare-exchange, becomes a hot lock
and initialization that takes little time on a smaller number of
processors, suddenly balloons to half an hour.

There may be other tools I could use to get the same information,
but certainly the existence of the uv_nmi kdb is quite useful and
expedient.  I don't want to see the kdb action removed from
uv_nmi.c.

Thanks for consideration,

--> Steve Wahl
-- 
Steve Wahl, Hewlett Packard Enterprise