From: Shannon Nelson <snel...@pensando.io>
Date: Tue, 9 Jun 2020 12:51:17 -0700
> On 6/9/20 12:47 PM, David Miller wrote:
>> From: Shannon Nelson <snel...@pensando.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 <snel...@pensando.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.
