netdev - Re: [RFC PATCH net] ibmvnic: complete dev->poll nicely during adapter reset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210305190530.GB1411314@us.ibm.com>
Date:   Fri, 5 Mar 2021 11:05:30 -0800
From:   Sukadev Bhattiprolu <sukadev@...ux.ibm.com>
To:     Lijun Pan <lijunp213@...il.com>
Cc:     Lijun Pan <ljp@...ux.ibm.com>, netdev@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Dany Madden <drt@...ux.ibm.com>, tlfalcon@...ux.ibm.com
Subject: Re: [RFC PATCH net] ibmvnic: complete dev->poll nicely during
 adapter reset

Lijun Pan [lijunp213@...il.com] wrote:
> On Fri, Mar 5, 2021 at 12:44 PM Sukadev Bhattiprolu
> <sukadev@...ux.ibm.com> wrote:
> >
> > Lijun Pan [ljp@...ux.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.

Yes, those will prevent a _new_ call to poll right?

But what if poll is already executing? What prevents it from accessing
an scrq that the reset path will free?

> So I don't think this is a issue here.