Re: Kernel 6.9.1 AX.25 Crash

[David Ranch <linux-hams@trinnet.net>]

Hello Lars,

> Well, partly because you're the first person to confirm that it works
> for someone besides me :). Dan (Cross) has offered to test it out as
> well; if I can get a couple of confirmations that it's working, I'll
> probably go ahead and submit it to netdev.
>
> The bigger issue has been that there are very few people interested in
> the ax.25 support in the kernel; there's not a real maintainer, so it's
> difficult to get code approved. There were some concerns expressed that
> maybe this isn't the *correct* fix, but I would argue that even if it's
> not the most correct fix we should try to get it in anyway, since
> otherwise ax.25 is completely broken.

First off, Lars, I wanted to thank you for getting some of these REAL 
fixes actually committed into the mainline.  You've done something that 
many others could not!  That said, I wanted to chime in here about your 
commend about "very few people interested in the a.25 support in the 
kernel".  That's definitely not true.

I and several others tried for many quarters and years to try to get 
some of these initial toxic commits that came in around the 4.19.x 
timeframe fixed but there was never any real meaningful responses and 
fixes.  I do agree that the lack of a real maintainer aka steward for 
the mkiss / ax25 / netrom / rose kernel code really hurts the ongoing 
health of the stack.  I wish I could take up that job but I don't have 
the required skillset.  The larger issue here is that random Linux 
kernel developers are periodically changing various parts of kernel 
infrastructure and when they try to make "updates" to the AX.25 code, 
the mindset is that they only consider a successful kernel compile as a 
"code pass".  That's VERY bad.  The other significant issue is that the 
kernel branch maintainers / powers at be seem to just accept these 
changes without any real scrutiny and don't require any real testing 
results to confirm things still work.  I had previously asked how some 
of these developers had really tested their code when they offered 
official patches here on the vger list and never received *any* 
meaningful responses.  I've asked if there is some form of a per-commit 
or daily CI build and regression test environment that I could offer up 
some basic toxicity test scenarios to.  No response.  It's been hugely 
frustrating for YEARS now and all of the "silently suffering" Linux 
packet users have resorted to still run ancient Linux distros like 
Debian Wheezy to keep their systems fully operational.

I am hugely grateful to you (Lars) on being able to submit some 
meaningful fixes and was able to get them committed to the mainline.  
The next major hurdle that I would love to get feedback on is how to get 
these new changes but also create a set of backported fixes committed 
into various Linux distributions kernels that don't strictly follow the 
mainline kernel.  My personal interest is in the Raspberry Pi OS kernel 
and the Canonical Ubuntu 22.04 / 20.04 kernels.  If people have 
recommendations / contacts to try / etc...please contact me offline and 
I will work on trying to get these fixes committed.

--David
KI6ZHD
Maintainer of the Linpac AX.25 terminal program
Advocate of the Direwolf multi-platform AX.25 software based TNC
AMPR 44-net Coordinator for the Silicon Valley, USA region