netdev - RE: [net-next v3 13/15] iecm: Add ethtool

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: <MW3PR11MB45229B97B3B6AC861CA2267B8F650@MW3PR11MB4522.namprd11.prod.outlook.com>
Date:   Fri, 10 Jul 2020 20:16:59 +0000
From:   "Brady, Alan" <alan.brady@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "Michael, Alice" <alice.michael@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "Burra, Phani R" <phani.r.burra@...el.com>,
        "Hay, Joshua A" <joshua.a.hay@...el.com>,
        "Chittim, Madhu" <madhu.chittim@...el.com>,
        "Linga, Pavan Kumar" <pavan.kumar.linga@...el.com>,
        "Skidmore, Donald C" <donald.c.skidmore@...el.com>,
        "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
        "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Subject: RE: [net-next v3 13/15] iecm: Add ethtool

> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Friday, June 26, 2020 12:30 PM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@...el.com>
> Cc: davem@...emloft.net; Michael, Alice <alice.michael@...el.com>;
> netdev@...r.kernel.org; nhorman@...hat.com; sassmann@...hat.com;
> Brady, Alan <alan.brady@...el.com>; Burra, Phani R <phani.r.burra@...el.com>;
> Hay, Joshua A <joshua.a.hay@...el.com>; Chittim, Madhu
> <madhu.chittim@...el.com>; Linga, Pavan Kumar
> <pavan.kumar.linga@...el.com>; Skidmore, Donald C
> <donald.c.skidmore@...el.com>; Brandeburg, Jesse
> <jesse.brandeburg@...el.com>; Samudrala, Sridhar
> <sridhar.samudrala@...el.com>
> Subject: Re: [net-next v3 13/15] iecm: Add ethtool
> 
> On Thu, 25 Jun 2020 19:07:35 -0700 Jeff Kirsher wrote:
> > @@ -794,7 +824,57 @@ static void iecm_vc_event_task(struct work_struct
> > *work)  int iecm_initiate_soft_reset(struct iecm_vport *vport,
> >  			     enum iecm_flags reset_cause)
> >  {
> > -	/* stub */
> > +	struct iecm_adapter *adapter = vport->adapter;
> > +	enum iecm_state current_state;
> > +	enum iecm_status status;
> > +	int err = 0;
> > +
> > +	/* Make sure we do not end up in initiating multiple resets */
> > +	mutex_lock(&adapter->reset_lock);
> > +
> > +	current_state = vport->adapter->state;
> > +	switch (reset_cause) {
> > +	case __IECM_SR_Q_CHANGE:
> > +		/* If we're changing number of queues requested, we need to
> > +		 * send a 'delete' message before freeing the queue resources.
> > +		 * We'll send an 'add' message in adjust_qs which doesn't
> > +		 * require the queue resources to be reallocated yet.
> > +		 */
> > +		if (current_state <= __IECM_DOWN) {
> > +			iecm_send_delete_queues_msg(vport);
> > +		} else {
> > +			set_bit(__IECM_DEL_QUEUES, adapter->flags);
> > +			iecm_vport_stop(vport);
> > +		}
> > +		iecm_deinit_rss(vport);
> > +		status = adapter->dev_ops.vc_ops.adjust_qs(vport);
> > +		if (status) {
> > +			err = -EFAULT;
> > +			goto reset_failure;
> > +		}
> > +		iecm_intr_rel(adapter);
> > +		iecm_vport_calc_num_q_vec(vport);
> > +		iecm_intr_req(adapter);
> > +		break;
> > +	case __IECM_SR_Q_DESC_CHANGE:
> > +		iecm_vport_stop(vport);
> > +		iecm_vport_calc_num_q_desc(vport);
> > +		break;
> > +	case __IECM_SR_Q_SCH_CHANGE:
> > +	case __IECM_SR_MTU_CHANGE:
> > +		iecm_vport_stop(vport);
> > +		break;
> > +	default:
> > +		dev_err(&adapter->pdev->dev, "Unhandled soft reset
> cause\n");
> > +		err = -EINVAL;
> > +		goto reset_failure;
> > +	}
> > +
> > +	if (current_state == __IECM_UP)
> > +		err = iecm_vport_open(vport);
> > +reset_failure:
> > +	mutex_unlock(&adapter->reset_lock);
> > +	return err;
> >  }
> 
> The close then open mode of operation will not cut it in 21st century.
> 
> You can't free all the resources and then fail to open if system is tight on
> memory.

We will refactor this flow to take memory allocations into account. We're planning to push another version next week with this fixed.  Thanks.

Alan