Messages in this thread | | | Date | Mon, 3 Apr 2023 16:08:20 +0300 | From | Leon Romanovsky <> | Subject | Re: [EXT] Re: [net PATCH 1/7] octeontx2-af: Secure APR table update with the lock |
| |
On Fri, Mar 31, 2023 at 08:56:59AM +0000, Geethasowjanya Akula wrote: > > > >-----Original Message----- > >From: Leon Romanovsky <leon@kernel.org> > >Sent: Thursday, March 30, 2023 12:46 PM > >To: Geethasowjanya Akula <gakula@marvell.com> > >Cc: Sai Krishna Gajula <saikrishnag@marvell.com>; davem@davemloft.net; edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Sunil >Kovvuri Goutham <sgoutham@marvell.com>; richardcochran@gmail.com > >Subject: Re: [EXT] Re: [net PATCH 1/7] octeontx2-af: Secure APR table update with the lock > > > >On Thu, Mar 30, 2023 at 06:56:54AM +0000, Geethasowjanya Akula wrote: > >> > >> >-----Original Message----- > >> >From: Leon Romanovsky <leon@kernel.org> > >> >Sent: Thursday, March 30, 2023 11:26 AM > >> >To: Sai Krishna Gajula <saikrishnag@marvell.com> > >> >Cc: davem@davemloft.net; edumazet@google.com; kuba@kernel.org; > >> >pabeni@redhat.com; netdev@vger.kernel.org; > >> >linux-kernel@vger.kernel.org; Sunil Kovvuri Goutham > >> ><sgoutham@marvell.com>; >richardcochran@gmail.com; Geethasowjanya > >> >Akula <gakula@marvell.com> > >> >Subject: [EXT] Re: [net PATCH 1/7] octeontx2-af: Secure APR table > >> >update with the lock > >> > >> >External Email > >> > >> >--------------------------------------------------------------------- > >> >- On Wed, Mar 29, 2023 at 10:36:13PM +0530, Sai Krishna wrote: > >> >> From: Geetha sowjanya <gakula@marvell.com> > >> >> > >> >> APR table contains the lmtst base address of PF/VFs. > >> >> These entries are updated by the PF/VF during the device probe. Due > >> >> to race condition while updating the entries are getting corrupted. > >> >> Hence secure the APR table update with the lock. > >> > >> >However, I don't see rsrc_lock in probe path. > >> >otx2_probe() > >> >-> cn10k_lmtst_init() > >> > -> lmt_base/lmstst is updated with and without mbox.lock. > >> > >> >Where did you take rsrc_lock in probe flow? > >> > >> rsrc_lock is initialized in AF driver. PF/VF driver in cn10k_lmtst_init() send a mbox request to AF to update the lmtst table. > >> mbox handler in AF takes rsrc_lock to update lmtst table. > > >Can you please present the stack trace of such flow? What are the actual variables/struct rsrc_lock is protecting? > > The lock tries to protect the request and response register at line#73 and line#83 in below function, from getting overwritten when > Multiple PFs invokes rvu_get_lmtaddr() simultaneously. > For example, if PF1 submit the request at line#73 and got permitted before it reads the response at line#80. > PF2 got scheduled submit the request then the response of PF1 is overwritten by the PF2 response. > When PF1 gets reschedule, it reads wrong data.
I see, thanks
| |