On Fri, Mar 5, 2021 at 12:44 PM Sukadev Bhattiprolu
<suka...@linux.ibm.com> wrote:
>
> 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?
>
napi_complete() and napi_disable() are called in the earlier stages of
reset path, i.e. before reset path actually calls the functions to
freeing scrqs.
So I don't think this is a issue here.
