Lijun Pan [ljp@linux.ibm.com] wrote:
The reset path will call ibmvnic_cleanup->ibmvnic_napi_disable
->napi_disable(). This is supposed to stop the polling.
Commit 21ecba6c48f9 ("ibmvnic: Exit polling routine correctly
during adapter reset") reported that the during device reset,
polling routine never completed and napi_disable slept indefinitely.
In order to solve that problem, resetting bit was checked and
napi_complete_done was called before dev->poll::ibmvnic_poll exited.
Checking for resetting bit in dev->poll is racy because resetting
bit may be false while being checked, but turns true immediately
afterwards.
Yes, have been testing a fix for that.
Hence we call napi_complete in ibmvnic_napi_disable, which avoids
the racing with resetting, and makes sure dev->poll and napi_disalbe
napi_complete() will prevent a new call to ibmvnic_poll() but what if
ibmvnic_poll() is already executing and attempting to access the scrqs
while the reset path is freeing them?
Sukadev