linux-kernel - Re: [PATCH net] netrom: fix possible deadlock in nr_rt_device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <50676604-b8c9-cc57-1ce0-a4db4758b190@trinnet.net>
Date: Tue, 10 Jun 2025 10:00:05 -0700
From: David Ranch <linux-hams@...nnet.net>
To: Dan Cross <crossd@...il.com>
Cc: Jakub Kicinski <kuba@...nel.org>, Denis Arefev <arefev@...mel.ru>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
        Simon Horman <horms@...nel.org>, Nikita Marushkin <hfggklm@...il.com>,
        Ilya Shchipletsov <rabbelkin@...l.ru>,
        Hongbo Li <lihongbo22@...wei.com>, linux-hams@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        lvc-project@...uxtesting.org, stable@...r.kernel.org,
        syzbot+ccdfb85a561b973219c7@...kaller.appspotmail.com
Subject: Re: [PATCH net] netrom: fix possible deadlock in nr_rt_device_down

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@...nnet.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?
>>>
>>