All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH net] ice: Protect vf_state check by cfg_lock in ice_vc_process_vf_msg()
Date: Fri, 15 Apr 2022 13:57:37 +0200	[thread overview]
Message-ID: <YlldsfrRJURXpp5d@boxer> (raw)
In-Reply-To: <YlldFriBVkKEgbBs@boxer>

On Fri, Apr 15, 2022 at 01:55:10PM +0200, Maciej Fijalkowski wrote:
> On Wed, Apr 13, 2022 at 09:22:59AM +0200, Ivan Vecera wrote:
> > Previous patch labelled "ice: Fix incorrect locking in
> > ice_vc_process_vf_msg()"  fixed an issue with ignored messages
> 
> tiny tiny nit: double space after "
> Also, has mentioned patch landed onto some tree so that we could provide
> SHA-1 of it? If not, then maybe squashing this one with the mentioned one
> would make sense?

Again, Brett's Intel address is bouncing, so:
CC: Brett Creeley <brett@pensando.io>

> 
> > sent by VF driver but a small race window still left.
> > 
> > Recently caught trace during 'ip link set ... vf 0 vlan ...' operation:
> > 
> > [ 7332.995625] ice 0000:3b:00.0: Clearing port VLAN on VF 0
> > [ 7333.001023] iavf 0000:3b:01.0: Reset indication received from the PF
> > [ 7333.007391] iavf 0000:3b:01.0: Scheduling reset task
> > [ 7333.059575] iavf 0000:3b:01.0: PF returned error -5 (IAVF_ERR_PARAM) to our request 3
> > [ 7333.059626] ice 0000:3b:00.0: Invalid message from VF 0, opcode 3, len 4, error -1
> > 
> > Setting of VLAN for VF causes a reset of the affected VF using
> > ice_reset_vf() function that runs with cfg_lock taken:
> > 
> > 1. ice_notify_vf_reset() informs IAVF driver that reset is needed and
> >    IAVF schedules its own reset procedure
> > 2. Bit ICE_VF_STATE_DIS is set in vf->vf_state
> > 3. Misc initialization steps
> > 4. ice_sriov_post_vsi_rebuild() -> ice_vf_set_initialized() and that
> >    clears ICE_VF_STATE_DIS in vf->vf_state
> > 
> > Step 3 is mentioned race window because IAVF reset procedure runs in
> > parallel and one of its step is sending of VIRTCHNL_OP_GET_VF_RESOURCES
> > message (opcode==3). This message is handled in ice_vc_process_vf_msg()
> > and if it is received during the mentioned race window then it's
> > marked as invalid and error is returned to VF driver.
> > 
> > Protect vf_state check in ice_vc_process_vf_msg() by cfg_lock to avoid
> > this race condition.
> > 
> > Fixes: e6ba5273d4ed ("ice: Fix race conditions between virtchnl handling and VF ndo ops")
> > Tested-by: Fei Liu <feliu@redhat.com>
> > Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> > ---
> >  drivers/net/ethernet/intel/ice/ice_virtchnl.c | 38 +++++++++----------
> >  1 file changed, 17 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> > index 5612c032f15a..553287a75b50 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> > @@ -3625,44 +3625,39 @@ void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
> >  		return;
> >  	}
> >  
> > +	mutex_lock(&vf->cfg_lock);
> > +
> >  	/* Check if VF is disabled. */
> >  	if (test_bit(ICE_VF_STATE_DIS, vf->vf_states)) {
> >  		err = -EPERM;
> > -		goto error_handler;
> > -	}
> > -
> > -	ops = vf->virtchnl_ops;
> > -
> > -	/* Perform basic checks on the msg */
> > -	err = virtchnl_vc_validate_vf_msg(&vf->vf_ver, v_opcode, msg, msglen);
> > -	if (err) {
> > -		if (err == VIRTCHNL_STATUS_ERR_PARAM)
> > -			err = -EPERM;
> > -		else
> > -			err = -EINVAL;
> > +	} else {
> > +		/* Perform basic checks on the msg */
> > +		err = virtchnl_vc_validate_vf_msg(&vf->vf_ver, v_opcode, msg,
> > +						  msglen);
> > +		if (err) {
> > +			if (err == VIRTCHNL_STATUS_ERR_PARAM)
> > +				err = -EPERM;
> > +			else
> > +				err = -EINVAL;
> > +		}
> 
> The chunk above feels a bit like unnecessary churn, no?
> Couldn't this patch be simply focused only on extending critical section?
> 
> >  	}
> > -
> > -error_handler:
> >  	if (err) {
> >  		ice_vc_send_msg_to_vf(vf, v_opcode, VIRTCHNL_STATUS_ERR_PARAM,
> >  				      NULL, 0);
> >  		dev_err(dev, "Invalid message from VF %d, opcode %d, len %d, error %d\n",
> >  			vf_id, v_opcode, msglen, err);
> > -		ice_put_vf(vf);
> > -		return;
> > +		goto finish;
> >  	}
> >  
> > -	mutex_lock(&vf->cfg_lock);
> > -
> >  	if (!ice_vc_is_opcode_allowed(vf, v_opcode)) {
> >  		ice_vc_send_msg_to_vf(vf, v_opcode,
> >  				      VIRTCHNL_STATUS_ERR_NOT_SUPPORTED, NULL,
> >  				      0);
> > -		mutex_unlock(&vf->cfg_lock);
> > -		ice_put_vf(vf);
> > -		return;
> > +		goto finish;
> >  	}
> >  
> > +	ops = vf->virtchnl_ops;
> > +
> >  	switch (v_opcode) {
> >  	case VIRTCHNL_OP_VERSION:
> >  		err = ops->get_ver_msg(vf, msg);
> > @@ -3773,6 +3768,7 @@ void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
> >  			 vf_id, v_opcode, err);
> >  	}
> >  
> > +finish:
> >  	mutex_unlock(&vf->cfg_lock);
> >  	ice_put_vf(vf);
> >  }
> > -- 
> > 2.35.1
> > 
> > _______________________________________________
> > Intel-wired-lan mailing list
> > Intel-wired-lan at osuosl.org
> > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

WARNING: multiple messages have this Message-ID (diff)
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Ivan Vecera <ivecera@redhat.com>
Cc: netdev@vger.kernel.org, Fei Liu <feliu@redhat.com>,
	"moderated list:INTEL ETHERNET DRIVERS" 
	<intel-wired-lan@lists.osuosl.org>,
	mschmidt@redhat.com, Brett Creeley <brett@pensando.io>,
	open list <linux-kernel@vger.kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Intel-wired-lan] [PATCH net] ice: Protect vf_state check by cfg_lock in ice_vc_process_vf_msg()
Date: Fri, 15 Apr 2022 13:57:37 +0200	[thread overview]
Message-ID: <YlldsfrRJURXpp5d@boxer> (raw)
In-Reply-To: <YlldFriBVkKEgbBs@boxer>

On Fri, Apr 15, 2022 at 01:55:10PM +0200, Maciej Fijalkowski wrote:
> On Wed, Apr 13, 2022 at 09:22:59AM +0200, Ivan Vecera wrote:
> > Previous patch labelled "ice: Fix incorrect locking in
> > ice_vc_process_vf_msg()"  fixed an issue with ignored messages
> 
> tiny tiny nit: double space after "
> Also, has mentioned patch landed onto some tree so that we could provide
> SHA-1 of it? If not, then maybe squashing this one with the mentioned one
> would make sense?

Again, Brett's Intel address is bouncing, so:
CC: Brett Creeley <brett@pensando.io>

> 
> > sent by VF driver but a small race window still left.
> > 
> > Recently caught trace during 'ip link set ... vf 0 vlan ...' operation:
> > 
> > [ 7332.995625] ice 0000:3b:00.0: Clearing port VLAN on VF 0
> > [ 7333.001023] iavf 0000:3b:01.0: Reset indication received from the PF
> > [ 7333.007391] iavf 0000:3b:01.0: Scheduling reset task
> > [ 7333.059575] iavf 0000:3b:01.0: PF returned error -5 (IAVF_ERR_PARAM) to our request 3
> > [ 7333.059626] ice 0000:3b:00.0: Invalid message from VF 0, opcode 3, len 4, error -1
> > 
> > Setting of VLAN for VF causes a reset of the affected VF using
> > ice_reset_vf() function that runs with cfg_lock taken:
> > 
> > 1. ice_notify_vf_reset() informs IAVF driver that reset is needed and
> >    IAVF schedules its own reset procedure
> > 2. Bit ICE_VF_STATE_DIS is set in vf->vf_state
> > 3. Misc initialization steps
> > 4. ice_sriov_post_vsi_rebuild() -> ice_vf_set_initialized() and that
> >    clears ICE_VF_STATE_DIS in vf->vf_state
> > 
> > Step 3 is mentioned race window because IAVF reset procedure runs in
> > parallel and one of its step is sending of VIRTCHNL_OP_GET_VF_RESOURCES
> > message (opcode==3). This message is handled in ice_vc_process_vf_msg()
> > and if it is received during the mentioned race window then it's
> > marked as invalid and error is returned to VF driver.
> > 
> > Protect vf_state check in ice_vc_process_vf_msg() by cfg_lock to avoid
> > this race condition.
> > 
> > Fixes: e6ba5273d4ed ("ice: Fix race conditions between virtchnl handling and VF ndo ops")
> > Tested-by: Fei Liu <feliu@redhat.com>
> > Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> > ---
> >  drivers/net/ethernet/intel/ice/ice_virtchnl.c | 38 +++++++++----------
> >  1 file changed, 17 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> > index 5612c032f15a..553287a75b50 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> > @@ -3625,44 +3625,39 @@ void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
> >  		return;
> >  	}
> >  
> > +	mutex_lock(&vf->cfg_lock);
> > +
> >  	/* Check if VF is disabled. */
> >  	if (test_bit(ICE_VF_STATE_DIS, vf->vf_states)) {
> >  		err = -EPERM;
> > -		goto error_handler;
> > -	}
> > -
> > -	ops = vf->virtchnl_ops;
> > -
> > -	/* Perform basic checks on the msg */
> > -	err = virtchnl_vc_validate_vf_msg(&vf->vf_ver, v_opcode, msg, msglen);
> > -	if (err) {
> > -		if (err == VIRTCHNL_STATUS_ERR_PARAM)
> > -			err = -EPERM;
> > -		else
> > -			err = -EINVAL;
> > +	} else {
> > +		/* Perform basic checks on the msg */
> > +		err = virtchnl_vc_validate_vf_msg(&vf->vf_ver, v_opcode, msg,
> > +						  msglen);
> > +		if (err) {
> > +			if (err == VIRTCHNL_STATUS_ERR_PARAM)
> > +				err = -EPERM;
> > +			else
> > +				err = -EINVAL;
> > +		}
> 
> The chunk above feels a bit like unnecessary churn, no?
> Couldn't this patch be simply focused only on extending critical section?
> 
> >  	}
> > -
> > -error_handler:
> >  	if (err) {
> >  		ice_vc_send_msg_to_vf(vf, v_opcode, VIRTCHNL_STATUS_ERR_PARAM,
> >  				      NULL, 0);
> >  		dev_err(dev, "Invalid message from VF %d, opcode %d, len %d, error %d\n",
> >  			vf_id, v_opcode, msglen, err);
> > -		ice_put_vf(vf);
> > -		return;
> > +		goto finish;
> >  	}
> >  
> > -	mutex_lock(&vf->cfg_lock);
> > -
> >  	if (!ice_vc_is_opcode_allowed(vf, v_opcode)) {
> >  		ice_vc_send_msg_to_vf(vf, v_opcode,
> >  				      VIRTCHNL_STATUS_ERR_NOT_SUPPORTED, NULL,
> >  				      0);
> > -		mutex_unlock(&vf->cfg_lock);
> > -		ice_put_vf(vf);
> > -		return;
> > +		goto finish;
> >  	}
> >  
> > +	ops = vf->virtchnl_ops;
> > +
> >  	switch (v_opcode) {
> >  	case VIRTCHNL_OP_VERSION:
> >  		err = ops->get_ver_msg(vf, msg);
> > @@ -3773,6 +3768,7 @@ void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
> >  			 vf_id, v_opcode, err);
> >  	}
> >  
> > +finish:
> >  	mutex_unlock(&vf->cfg_lock);
> >  	ice_put_vf(vf);
> >  }
> > -- 
> > 2.35.1
> > 
> > _______________________________________________
> > Intel-wired-lan mailing list
> > Intel-wired-lan@osuosl.org
> > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  reply	other threads:[~2022-04-15 11:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-13  7:22 [Intel-wired-lan] [PATCH net] ice: Protect vf_state check by cfg_lock in ice_vc_process_vf_msg() Ivan Vecera
2022-04-13  7:22 ` Ivan Vecera
2022-04-15 11:55 ` [Intel-wired-lan] " Maciej Fijalkowski
2022-04-15 11:55   ` Maciej Fijalkowski
2022-04-15 11:57   ` Maciej Fijalkowski [this message]
2022-04-15 11:57     ` Maciej Fijalkowski
2022-04-15 13:53     ` Alexander Lobakin
2022-04-15 13:53       ` Alexander Lobakin
2022-04-15 20:55     ` Tony Nguyen
2022-04-15 20:55       ` Tony Nguyen
2022-04-16 11:30       ` Ivan Vecera
2022-04-16 11:30         ` Ivan Vecera
2022-04-18 18:10         ` Tony Nguyen
2022-04-18 18:10           ` Tony Nguyen
2022-04-19 14:23           ` Ivan Vecera
2022-04-19 14:23             ` Ivan Vecera
2022-04-15 16:38   ` Ivan Vecera
2022-04-15 16:38     ` Ivan Vecera
2022-04-15 18:31     ` Keller, Jacob E
2022-04-15 18:31       ` Keller, Jacob E
2022-04-15 20:53       ` Tony Nguyen
2022-04-15 20:53         ` Tony Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YlldsfrRJURXpp5d@boxer \
    --to=maciej.fijalkowski@intel.com \
    --cc=intel-wired-lan@osuosl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.