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]
Message-Id: <20200609.130637.1015423291014478400.davem@davemloft.net>
Date:   Tue, 09 Jun 2020 13:06:37 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     snelson@...sando.io
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net 1/1] ionic: wait on queue start until after IFF_UP

From: Shannon Nelson <snelson@...sando.io>
Date: Tue, 9 Jun 2020 12:51:17 -0700

> On 6/9/20 12:47 PM, David Miller wrote:
>> From: Shannon Nelson <snelson@...sando.io>
>> Date: Mon,  8 Jun 2020 20:41:43 -0700
>>
>>> The netif_running() test looks at __LINK_STATE_START which
>>> gets set before ndo_open() is called, there is a window of
>>> time between that and when the queues are actually ready to
>>> be run.  If ionic_check_link_status() notices that the link is
>>> up very soon after netif_running() becomes true, it might try
>>> to run the queues before they are ready, causing all manner of
>>> potential issues.  Since the netdev->flags IFF_UP isn't set
>>> until after ndo_open() returns, we can wait for that before
>>> we allow ionic_check_link_status() to start the queues.
>>>
>>> On the way back to close, __LINK_STATE_START is cleared before
>>> calling ndo_stop(), and IFF_UP is cleared after.  Both of
>>> these need to be true in order to safely stop the queues
>>> from ionic_check_link_status().
>>>
>>> Fixes: 49d3b493673a ("ionic: disable the queues on link down")
>>> Signed-off-by: Shannon Nelson <snelson@...sando.io>
>> What will make sure the queues actually get started if this
>> event's queue start gets skipped in this scenerio?
>>
>> This code is only invoked when the link status changes or
>> when the firmware is started.
> 
> If the link is already seen as up before ionic_open() is called it
> starts the queues at that point.
> 
> If link isn't seen until after ionic_open(), then the queues are
> started in this periodic link check.

I'm saying if it happens in the race condition you mention that you
are protecting against, where running is true and IFF_UP is not.

The link check is periodic?  It looks like it triggers when the
link state changes to me.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ