net/kgdb: Taking another crack at implementing kgdboe

net/kgdb: Taking another crack at implementing kgdboe

[Jordan Hand]

Hey folks,

I have been scouring patches from around 2005-2008 related to kgdboe
(kgdb over ethernet) and I am interested in taking a shot at getting it
into the mainline kernel.

I found an implementation from Tom Rini in 2005[1] and an out of tree
implementation[2].

So I have a couple questions before I dive in:

1. Is anyone actively working on this? From lkml archives it appears no
but I thought I'd ask.
2. Does anyone have an objection to this feature? From my reading it
seems that the reason it was never merged was due to reliability issues
but I just want to double check that people don't see some larger issue.

I don't have 100% of my time to devote to this so it will likely take me
a while but this is something I would like to see in the upstream kernel
so I thought I'd give it a try.

[1] https://lkml.org/lkml/2005/7/29/321
[2] https://github.com/sysprogs/kgdboe

Re: net/kgdb: Taking another crack at implementing kgdboe

[Jason Wessel]

On 2/21/20 6:33 PM, Jordan Hand wrote:
> Hey folks,
> 
> I have been scouring patches from around 2005-2008 related to kgdboe
> (kgdb over ethernet) and I am interested in taking a shot at getting it
> into the mainline kernel.
> 
> I found an implementation from Tom Rini in 2005[1] and an out of tree
> implementation[2].
> 
> So I have a couple questions before I dive in:
> 
> 1. Is anyone actively working on this? From lkml archives it appears no
> but I thought I'd ask.


I don't believe there is anyone working on this. 


> 2. Does anyone have an objection to this feature? From my reading it
> seems that the reason it was never merged was due to reliability issues
> but I just want to double check that people don't see some larger issue.


I think some of the biggest problems here are what it takes to stop
the ethernet hardware, use it for a bit, and then put it back
together.  The changes to the network stack and the ethernet drivers
were fairly invasive to get it work with any degree of reliability.

Long ago, in 2008 I had proposed perhaps using a second dedicated
ethernet queue, vs trying to put the driver back into a good state
after you have stopped the core kernel execution.  I still view this
to be the best approach to getting a reliable debugger if you are
facing some kind of situation that you must use something that is "in
kernel".  You really need a way that you can process inputs and
outputs safely without using any other function in the kernel except
for what is provided in the debug core.  This would also give us a
more reliable way to have a "netconsole" for dumping ftrace data and
oops logs. 


> 
> I don't have 100% of my time to devote to this so it will likely take me
> a while but this is something I would like to see in the upstream kernel
> so I thought I'd give it a try.
> 
> [1] https://lkml.org/lkml/2005/7/29/321

I definitely have a version from 2014 that is newer than what was
posted there, which relies on the netpoll controller part of which has
been removed from the mainline kernel.  I also have a pile of USB
patches which enable the use of KDB with a USB keyboard.  Quite a few
years have passed by since I tried to submit them to the USB
maintainers. It is a similar kind of situation as the ethernet.  It is
hard to talk to the drivers in a polling state and put them back to a
working state when you resume.  Stopping is the easy part.


> [2] https://github.com/sysprogs/kgdboe
> 

This is a much newer project than the implementation from Tom or myself.   

Cheers,
Jason.

Re: net/kgdb: Taking another crack at implementing kgdboe

[Daniel Thompson]

On Fri, Feb 21, 2020 at 04:33:48PM -0800, Jordan Hand wrote:
> Hey folks,
> 
> I have been scouring patches from around 2005-2008 related to kgdboe
> (kgdb over ethernet) and I am interested in taking a shot at getting it
> into the mainline kernel.
> 
> I found an implementation from Tom Rini in 2005[1] and an out of tree
> implementation[2].
> 
> So I have a couple questions before I dive in:
> 
> 1. Is anyone actively working on this? From lkml archives it appears no
> but I thought I'd ask.
> 2. Does anyone have an objection to this feature? From my reading it
> seems that the reason it was never merged was due to reliability issues
> but I just want to double check that people don't see some larger issue.

Like Jason said, I can't see any objections on the kgdb side but
integrating even with simple peripherals (UARTs for example) has it's
share of pitfalls so it may take a fair bit of work to make the net
developers comfortable!


Daniel.