netdev - Re: [PATCH net-next 4/6] ionic: add queue lock around open and stop

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 Aug 2021 22:12:36 -0700
From:   Shannon Nelson <snelson@...sando.io>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, drivers@...sando.io,
        jtoppins@...hat.com
Subject: Re: [PATCH net-next 4/6] ionic: add queue lock around open and stop

On 8/27/21 5:39 PM, Jakub Kicinski wrote:
> On Fri, 27 Aug 2021 11:55:10 -0700 Shannon Nelson wrote:
>> Add the queue configuration lock to ionic_open() and
>> ionic_stop() so that they don't collide with other in parallel
>> queue configuration actions such as MTU changes as can be
>> demonstrated with a tight loop of ifup/change-mtu/ifdown.
> Say more? how are up/down/change mtu not under rtnl_lock?
Sorry, that commit message didn't get updated as it should have. The MTU 
change played with the timing of actions just right, but wasn't the 
culprit.  The actual issue was that the watchdog and the ionic_stop 
collided: ionic_stop had started taking the queues down but without 
grabbing the mutex, and the watchdog timer went off and ran the 
link_check which grabbed the mutex and tried to bring them back up 
again.  This didn't break anything in the driver, but confused the NIC 
firmware and left the interface non-operational. This was cleared with 
another ifdown/ifup cycle.

I can repost with a better commit description.

sln