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?
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.
--David KI6ZHD
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?
On Mon, Jun 9, 2025 at 7:31 PM David Ranch linux-hams@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?
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@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?
linux-stable-mirror@lists.linaro.org
-
Dan Cross -
David Ranch -
Jakub Kicinski