Lijun Pan [l...@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
