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: <20250407150358.GN395307@horms.kernel.org>
Date: Mon, 7 Apr 2025 16:03:58 +0100
From: Simon Horman <horms@...nel.org>
To: Subbaraya Sundeep <sbhatta@...vell.com>
Cc: Wentao Liang <vulab@...as.ac.cn>,
	Sunil Kovvuri Goutham <sgoutham@...vell.com>,
	Geethasowjanya Akula <gakula@...vell.com>,
	Hariprasad Kelam <hkelam@...vell.com>,
	"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] octeontx2-pf:  Add error handling for
 cn10k_map_unmap_rq_policer().

On Mon, Apr 07, 2025 at 05:57:14AM +0000, Subbaraya Sundeep wrote:
> On 2025-04-04 at 11:11:38, Simon Horman (horms@...nel.org) wrote:
> > On Fri, Apr 04, 2025 at 05:22:16AM +0000, Subbaraya Sundeep Bhatta wrote:
> > > Hi,
> > > 
> > > From: Wentao Liang <vulab@...as.ac.cn> 
> > > Sent: Thursday, April 3, 2025 8:43 PM
> > > To: Sunil Kovvuri Goutham <sgoutham@...vell.com>; Geethasowjanya Akula <gakula@...vell.com>; Subbaraya Sundeep Bhatta <sbhatta@...vell.com>; Hariprasad Kelam <hkelam@...vell.com>; andrew+netdev@...n.ch; davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org; pabeni@...hat.com
> > > Cc: netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Wentao Liang <vulab@...as.ac.cn>
> > > Subject: [PATCH] octeontx2-pf: Add error handling for cn10k_map_unmap_rq_policer().
> > > 
> > > The cn10k_free_matchall_ipolicer() calls the cn10k_map_unmap_rq_policer()
> > > for each queue in a for loop without checking for any errors. A proper
> > > implementation can be found in cn10k_set_matchall_ipolicer_rate().
> > > 
> > > Check the return value of the cn10k_map_unmap_rq_policer() function during
> > > each loop. Jump to unlock function and return the error code if the
> > > funciton fails to unmap policer.
> > > 
> > > Fixes: 2ca89a2c3752 ("octeontx2-pf: TC_MATCHALL ingress ratelimiting offload")
> > > Signed-off-by: Wentao Liang <mailto:vulab@...as.ac.cn>
> > > ---
> > >  drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c | 6 ++++--
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
> > > index a15cc86635d6..ce58ad61198e 100644
> > > --- a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
> > > +++ b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
> > > @@ -353,11 +353,13 @@ int cn10k_free_matchall_ipolicer(struct otx2_nic *pfvf)
> > >  
> > >  	/* Remove RQ's policer mapping */
> > >  	for (qidx = 0; qidx < hw->rx_queues; qidx++)
> > > -		cn10k_map_unmap_rq_policer(pfvf, qidx,
> > > -					   hw->matchall_ipolicer, false);
> > > +		rc = cn10k_map_unmap_rq_policer(pfvf, qidx, hw->matchall_ipolicer, false);
> > > +		if (rc)
> > > +			goto out;
> > >  
> > > Intentionally we do not bail out when unmapping one of the queues is failed. The reason is during teardown if one of the queues is failed then
> > > we end up not tearing down rest of the queues and those queues cannot be used later which is bad. So leave whatever queues have failed and proceed
> > > with tearing down the rest. Hence all we can do is print an error for the failed queue and continue.
> > 
> > Hi Sundeep,
> > 
> > Sorry that I didn't notice your response before sending my own to Wentao.
> > 
> > I do agree that bailing out here is not a good idea.  But I wonder if there
> > is any value in the function should propagate some error reporting if any
> > call to cn10k_map_unmap_rq_policer fails - e.g. the first failure - while
> > still iterating aver all elements.
> > 
> > Just an idea.
> > 
> Hi Simon,
> 
> We can do but it gets compilcated if more than one queue failed and
> reasons are different. Hence just print error and continue.

Yes, understood. I did think about this some more and I think that
reporting an error is the best we can do, else as you say it gets complex.
So if there is already a log made, then I think that is sufficient.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ