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]
Date:	Fri, 10 Jan 2014 17:34:39 +0000
From:	"Williams, Mitch A" <mitch.a.williams@...el.com>
To:	Scott Feldman <sfeldma@...ulusnetworks.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
CC:	David Miller <davem@...emloft.net>,
	"Rose, Gregory V" <gregory.v.rose@...el.com>,
	Netdev <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>,
	"sassmann@...hat.com" <sassmann@...hat.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
Subject: RE: [net-next 05/15] i40e: add a comment on barrier and fix panic
 on reset



> -----Original Message-----
> From: Scott Feldman [mailto:sfeldma@...ulusnetworks.com]
> Sent: Thursday, January 09, 2014 2:17 PM
> To: Kirsher, Jeffrey T
> Cc: David Miller; Rose, Gregory V; Netdev; gospo@...hat.com;
> sassmann@...hat.com; Williams, Mitch A; Brandeburg, Jesse
> Subject: Re: [net-next 05/15] i40e: add a comment on barrier and fix panic
> on reset
> 
> 
> On Jan 9, 2014, at 4:52 AM, Jeff Kirsher <jeffrey.t.kirsher@...el.com>
> wrote:
> 
> > From: Greg Rose <gregory.v.rose@...el.com>
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > index ea76134..5cdc67c 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > @@ -422,7 +422,7 @@ void i40e_vsi_reset_stats(struct i40e_vsi *vsi)
> > 	memset(&vsi->net_stats_offsets, 0, sizeof(vsi->net_stats_offsets));
> > 	memset(&vsi->eth_stats, 0, sizeof(vsi->eth_stats));
> > 	memset(&vsi->eth_stats_offsets, 0, sizeof(vsi->eth_stats_offsets));
> > -	if (vsi->rx_rings)
> > +	if (vsi->rx_rings && vsi->rx_rings[0]) {
> 
> Any reason why just [0] is checked for !NULL here...
> 
> > 		for (i = 0; i < vsi->num_queue_pairs; i++) {
> > 			memset(&vsi->rx_rings[i]->stats, 0 ,
> > 			       sizeof(vsi->rx_rings[i]->stats));
> > @@ -433,6 +433,7 @@ void i40e_vsi_reset_stats(struct i40e_vsi *vsi)
> > 			memset(&vsi->tx_rings[i]->tx_stats, 0,
> > 			       sizeof(vsi->tx_rings[i]->tx_stats));
> > 		}
> > +	}
> > 	vsi->stat_offsets_loaded = false;
> > }
> >
> > @@ -2101,8 +2105,11 @@ static void i40e_vsi_free_rx_resources(struct
> i40e_vsi *vsi)
> > {
> > 	int i;
> >
> > +	if (!vsi->rx_rings)
> > +		return;
> > +
> > 	for (i = 0; i < vsi->num_queue_pairs; i++)
> > -		if (vsi->rx_rings[i]->desc)
> > +		if (vsi->rx_rings[i] && vsi->rx_rings[i]->desc)
> 
> but here every [i] is checked for !NULL here?
> 
> > 			i40e_free_rx_resources(vsi->rx_rings[i]);
> > }
> >
> 
> If [0] check is sufficient to know if array members are allocated, maybe an
> wrapper func would help document intent:
> 
> static bool i40e_vsi_rings_allocated(struct i40e_ring *ring)
> {
> 	return (ring && ring[0]);
> }
> 
> -scott
The assumption in vsi_reset_stats() is that the device is up and running normally, in which case all of the rings will be allocated, so we only need to check the first one.

OTOH, in free_rx_resources can be called in case of an allocation failure, in which case you could conceivably have some rings allocated and some not.

-Mitch
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ