[lvc-project] [PATCH net] netrom: fix possible deadlock in nr_rt_device_down

David Ranch linux-hams at trinnet.net
Tue Jun 10 20:00:05 MSK 2025


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 <linux-hams at trinnet.net> wrote:
>> 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.
>
>> On 06/09/2025 04:26 PM, Jakub Kicinski wrote:
>>> On Mon, 9 Jun 2025 16:16:32 -0700 David Ranch wrote:
>>>> 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?
>>>
>>




More information about the lvc-project mailing list