diff mbox series

[net,v2] ice: Fix incorrect locking in ice_vc_process_vf_msg()

Message ID 20220401104052.1711721-1-ivecera@redhat.com (mailing list archive)
State Awaiting Upstream
Delegated to: Netdev Maintainers
Headers show
Series [net,v2] ice: Fix incorrect locking in ice_vc_process_vf_msg() | expand

Checks

Context Check Description
netdev/tree_selection success Clearly marked for net
netdev/fixes_present success Fixes tag present in non-next series
netdev/subject_prefix success Link
netdev/cover_letter success Single patches do not need cover letters
netdev/patch_count success Link
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/cc_maintainers success CCed 8 of 8 maintainers
netdev/build_clang success Errors and warnings before: 0 this patch: 0
netdev/module_param success Was 0 now: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/verify_fixes success Fixes tag looks correct
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/checkpatch warning WARNING: 'acccess' may be misspelled - perhaps 'access'?
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Ivan Vecera April 1, 2022, 10:40 a.m. UTC
Usage of mutex_trylock() in ice_vc_process_vf_msg() is incorrect
because message sent from VF is ignored and never processed.

Use mutex_lock() instead to fix the issue. It is safe because this
mutex is used to prevent races between VF related NDOs and
handlers processing request messages from VF and these handlers
are running in ice_service_task() context. Additionally move this
mutex lock prior ice_vc_is_opcode_allowed() call to avoid potential
races during allowlist acccess.

Fixes: e6ba5273d4ed ("ice: Fix race conditions between virtchnl handling and VF ndo ops")
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
 drivers/net/ethernet/intel/ice/ice_virtchnl.c | 21 +++++++------------
 1 file changed, 7 insertions(+), 14 deletions(-)

Comments

Alexander Lobakin April 8, 2022, 1:47 p.m. UTC | #1
From: Ivan Vecera <ivecera@redhat.com>
Date: Fri,  1 Apr 2022 12:40:52 +0200

> Usage of mutex_trylock() in ice_vc_process_vf_msg() is incorrect
> because message sent from VF is ignored and never processed.
> 
> Use mutex_lock() instead to fix the issue. It is safe because this
> mutex is used to prevent races between VF related NDOs and
> handlers processing request messages from VF and these handlers
> are running in ice_service_task() context. Additionally move this
> mutex lock prior ice_vc_is_opcode_allowed() call to avoid potential
> races during allowlist acccess.
> 
> Fixes: e6ba5273d4ed ("ice: Fix race conditions between virtchnl handling and VF ndo ops")
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>

Hey Tony,

I guess you missed this one due to being on a vacation previously.
It's been previously reviewed IIRC, could you take it into
net-queue?

> ---
>  drivers/net/ethernet/intel/ice/ice_virtchnl.c | 21 +++++++------------
>  1 file changed, 7 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> index 3f1a63815bac..a465f3743ffc 100644
> --- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> @@ -3642,14 +3642,6 @@ void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
>  			err = -EINVAL;
>  	}
>  
> -	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);
> -		ice_put_vf(vf);
> -		return;
> -	}
> -
>  error_handler:
>  	if (err) {
>  		ice_vc_send_msg_to_vf(vf, v_opcode, VIRTCHNL_STATUS_ERR_PARAM,
> @@ -3660,12 +3652,13 @@ void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
>  		return;
>  	}
>  
> -	/* VF is being configured in another context that triggers a VFR, so no
> -	 * need to process this message
> -	 */
> -	if (!mutex_trylock(&vf->cfg_lock)) {
> -		dev_info(dev, "VF %u is being configured in another context that will trigger a VFR, so there is no need to handle this message\n",
> -			 vf->vf_id);
> +	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;
>  	}
> -- 
> 2.35.1

Thanks,
Al
Tony Nguyen April 8, 2022, 4:01 p.m. UTC | #2
On 4/8/2022 6:47 AM, Alexander Lobakin wrote:
> From: Ivan Vecera <ivecera@redhat.com>
> Date: Fri,  1 Apr 2022 12:40:52 +0200
>
>> Usage of mutex_trylock() in ice_vc_process_vf_msg() is incorrect
>> because message sent from VF is ignored and never processed.
>>
>> Use mutex_lock() instead to fix the issue. It is safe because this
>> mutex is used to prevent races between VF related NDOs and
>> handlers processing request messages from VF and these handlers
>> are running in ice_service_task() context. Additionally move this
>> mutex lock prior ice_vc_is_opcode_allowed() call to avoid potential
>> races during allowlist acccess.
>>
>> Fixes: e6ba5273d4ed ("ice: Fix race conditions between virtchnl handling and VF ndo ops")
>> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> Hey Tony,
>
> I guess you missed this one due to being on a vacation previously.
> It's been previously reviewed IIRC, could you take it into
> net-queue?

I remember applying this but I don't see it on the tree so I must be 
mistaken. :( I'll get it applied, thanks for catching.

-Tony

>> ---
>>   drivers/net/ethernet/intel/ice/ice_virtchnl.c | 21 +++++++------------
>>   1 file changed, 7 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
>> index 3f1a63815bac..a465f3743ffc 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
>> @@ -3642,14 +3642,6 @@ void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
>>   			err = -EINVAL;
>>   	}
>>   
>> -	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);
>> -		ice_put_vf(vf);
>> -		return;
>> -	}
>> -
>>   error_handler:
>>   	if (err) {
>>   		ice_vc_send_msg_to_vf(vf, v_opcode, VIRTCHNL_STATUS_ERR_PARAM,
>> @@ -3660,12 +3652,13 @@ void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
>>   		return;
>>   	}
>>   
>> -	/* VF is being configured in another context that triggers a VFR, so no
>> -	 * need to process this message
>> -	 */
>> -	if (!mutex_trylock(&vf->cfg_lock)) {
>> -		dev_info(dev, "VF %u is being configured in another context that will trigger a VFR, so there is no need to handle this message\n",
>> -			 vf->vf_id);
>> +	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;
>>   	}
>> -- 
>> 2.35.1
> Thanks,
> Al
Jankowski, Konrad0 April 12, 2022, 10:39 a.m. UTC | #3
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Tony Nguyen
> Sent: Friday, April 8, 2022 6:01 PM
> To: Lobakin, Alexandr <alexandr.lobakin@intel.com>
> Cc: ivecera <ivecera@redhat.com>; netdev@vger.kernel.org; mschmidt
> <mschmidt@redhat.com>; Brett Creeley <brett@pensando.io>; open list
> <linux-kernel@vger.kernel.org>; poros <poros@redhat.com>; moderated
> list:INTEL ETHERNET DRIVERS <intel-wired-lan@lists.osuosl.org>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S.
> Miller <davem@davemloft.net>
> Subject: Re: [Intel-wired-lan] [PATCH net v2] ice: Fix incorrect locking in
> ice_vc_process_vf_msg()
> 
> 
> On 4/8/2022 6:47 AM, Alexander Lobakin wrote:
> > From: Ivan Vecera <ivecera@redhat.com>
> > Date: Fri,  1 Apr 2022 12:40:52 +0200
> >
> >> Usage of mutex_trylock() in ice_vc_process_vf_msg() is incorrect
> >> because message sent from VF is ignored and never processed.
> >>
> >> Use mutex_lock() instead to fix the issue. It is safe because this
> >> mutex is used to prevent races between VF related NDOs and handlers
> >> processing request messages from VF and these handlers are running in
> >> ice_service_task() context. Additionally move this mutex lock prior
> >> ice_vc_is_opcode_allowed() call to avoid potential races during
> >> allowlist acccess.
> >>
> >> Fixes: e6ba5273d4ed ("ice: Fix race conditions between virtchnl
> >> handling and VF ndo ops")
> >> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> > Hey Tony,
> >
> > I guess you missed this one due to being on a vacation previously.
> > It's been previously reviewed IIRC, could you take it into net-queue?
> 
> I remember applying this but I don't see it on the tree so I must be mistaken.
> :( I'll get it applied, thanks for catching.
> 
> -Tony
> 
> >> ---
> >>   drivers/net/ethernet/intel/ice/ice_virtchnl.c | 21 +++++++------------
> >>   1 file changed, 7 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> >> b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> >> index 3f1a63815bac..a465f3743ffc 100644
> >> --- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> >> +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
> >> @@ -3642,14 +3642,6 @@ void ice_vc_process_vf_msg(struct ice_pf *pf,

Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
diff mbox series

Patch

diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
index 3f1a63815bac..a465f3743ffc 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
@@ -3642,14 +3642,6 @@  void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
 			err = -EINVAL;
 	}
 
-	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);
-		ice_put_vf(vf);
-		return;
-	}
-
 error_handler:
 	if (err) {
 		ice_vc_send_msg_to_vf(vf, v_opcode, VIRTCHNL_STATUS_ERR_PARAM,
@@ -3660,12 +3652,13 @@  void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
 		return;
 	}
 
-	/* VF is being configured in another context that triggers a VFR, so no
-	 * need to process this message
-	 */
-	if (!mutex_trylock(&vf->cfg_lock)) {
-		dev_info(dev, "VF %u is being configured in another context that will trigger a VFR, so there is no need to handle this message\n",
-			 vf->vf_id);
+	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;
 	}