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: <aWjvp85mp80JUyGo@horms.kernel.org>
Date: Thu, 15 Jan 2026 13:46:15 +0000
From: Simon Horman <horms@...nel.org>
To: Vimlesh Kumar <vimleshk@...vell.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Sathesh B Edara <sedara@...vell.com>,
	Shinas Rasheed <srasheed@...vell.com>,
	Haseeb Gani <hgani@...vell.com>,
	Veerasenareddy Burru <vburru@...vell.com>,
	Satananda Burla <sburla@...vell.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [EXTERNAL] Re: [PATCH net v3 3/3] octeon_ep_vf: ensure dbell
 BADDR updation

On Thu, Jan 15, 2026 at 09:34:23AM +0000, Vimlesh Kumar wrote:
> 
> 
> > -----Original Message-----
> > From: Simon Horman <horms@...nel.org>
> > Sent: Monday, January 12, 2026 8:10 PM
> > To: Vimlesh Kumar <vimleshk@...vell.com>
> > Cc: netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Sathesh B Edara
> > <sedara@...vell.com>; Shinas Rasheed <srasheed@...vell.com>; Haseeb
> > Gani <hgani@...vell.com>; Veerasenareddy Burru <vburru@...vell.com>;
> > Satananda Burla <sburla@...vell.com>; Andrew Lunn
> > <andrew+netdev@...n.ch>; David S. Miller <davem@...emloft.net>; Eric
> > Dumazet <edumazet@...gle.com>; Jakub Kicinski <kuba@...nel.org>; Paolo
> > Abeni <pabeni@...hat.com>
> > Subject: [EXTERNAL] Re: [PATCH net v3 3/3] octeon_ep_vf: ensure dbell
> > BADDR updation
> > 
> > On Wed, Jan 07, 2026 at 01: 18: 56PM +0000, Vimlesh Kumar wrote: > Make
> > sure the OUT DBELL base address reflects the > latest values written to it. > >
> > Fix: > Add a wait until the OUT DBELL base address register > is updated
> > On Wed, Jan 07, 2026 at 01:18:56PM +0000, Vimlesh Kumar wrote:
> > > Make sure the OUT DBELL base address reflects the latest values
> > > written to it.
> > >
> > > Fix:
> > > Add a wait until the OUT DBELL base address register is updated with
> > > the DMA ring descriptor address, and modify the setup_oq function to
> > > properly handle failures.
> > >
> > > Fixes: 2c0c32c72be29 ("octeon_ep_vf: add hardware configuration APIs")
> > > Signed-off-by: Sathesh Edara <sedara@...vell.com>
> > > Signed-off-by: Shinas Rasheed <srasheed@...vell.com>
> > > Signed-off-by: Vimlesh Kumar <vimleshk@...vell.com>
> > > ---
> > > V3:
> > > - Use reverse christmas tree order variable declaration.
> > > - Return error if timeout happens during setup oq.
> > 
> > ...
> > 
> > > diff --git a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> > > b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> > > index d70c8be3cfc4..6446f6bf0b90 100644
> > > --- a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> > > +++ b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> > > @@ -171,7 +171,9 @@ static int octep_vf_setup_oq(struct octep_vf_device
> > *oct, int q_no)
> > >  		goto oq_fill_buff_err;
> > >
> > >  	octep_vf_oq_reset_indices(oq);
> > > -	oct->hw_ops.setup_oq_regs(oct, q_no);
> > > +	if (oct->hw_ops.setup_oq_regs(oct, q_no))
> > > +		goto oq_fill_buff_err;
> > > +
> > 
> > Hi Vimlesh, all,
> > 
> > I think that a new label needs to be added to the unwind ladder such that
> > octep_vf_oq_free_ring_buffers() is called if the error condition above is met.
> > 
> > Likewise in patch 2/3.
> 
> Hi Simon, 
> 
> octep_vf_oq_free_ring_buffers() is being called from the caller function octep_vf_setup_oqs() in the error case and hence not required over here.

Ok. I'm not a big fan of asymmetric clean-up paths.
But I agree that would prevent leaks.

...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ