Yes, this seems like a reasonable approach though I understand all this 
code is old, overly complicated, and when proposed changes are 
available, little to no proper testing is done before it's commited and 
it takes a very long time to get properly fixed.

I only bring this all up as the Linux AX.25 community has been badly 
bitten by similar commits in the last few years.  I've tried to help 
find a new maintainer and/or find somewhere to possibly create and run 
CI tests to catch issues but I've been unsuccessful so far.

I am happy to try helping on the testing side once I know what the test 
harness is but I'm out of my league when it comes to the code side.

--David
KI6ZHD


On 06/10/2025 06:36 AM, Dan Cross wrote:

On Mon, Jun 9, 2025 at 7:31 PM David Ranch [off-list ref] wrote:

quoted

That's unclear to me but maybe someone else knowing the code better than
myself can chime in.  I have to assume having these locks present
are for a reason.

The suggestion was not to remove locking, but rather, to fold multiple
separate locks into one. That is, have a single lock that covers both
the neighbor list and the node list. Naturally, there would be more
contention around a single lock in contrast to multiple, more granular
locks. But given that NETROM has very low performance requirements,
and that the data that these locks protect doesn't change that often,
that's probably fine and would eliminate the possibility of deadlock
due to lock ordering issues.

        - Dan C.

quoted

On 06/09/2025 04:26 PM, Jakub Kicinski wrote:

quoted

On Mon, 9 Jun 2025 16:16:32 -0700 David Ranch wrote:

quoted

I'm not sure what you mean by "the only user of this code".  There are
many people using the Linux AX.25 + NETROM stack but we unfortunately
don't have a active kernel maintainer for this code today.

Alright, sorry. Either way - these locks are not performance critical
for you, right?