On 6/9/20 1:06 PM, David Miller wrote:
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.
Yes, the link check is triggered by the periodic watchdog
ionic_watchdog_cb(), every 5 seconds.
sln
