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] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2cf6650-a164-4d3c-a3d9-cc57c66069a5@intel.com>
Date: Fri, 31 May 2024 09:47:47 -0600
From: Ahmed Zaki <ahmed.zaki@...el.com>
To: Simon Horman <horms@...nel.org>
CC: <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
	<jacob.e.keller@...el.com>, <anthony.l.nguyen@...el.com>, Junfeng Guo
	<junfeng.guo@...el.com>, Marcin Szycik <marcin.szycik@...ux.intel.com>
Subject: Re: [PATCH iwl-next v2 11/13] ice: enable FDIR filters from raw
 binary patterns for VFs



On 2024-05-31 7:18 a.m., Simon Horman wrote:
> On Mon, May 27, 2024 at 12:58:08PM -0600, Ahmed Zaki wrote:
>> From: Junfeng Guo <junfeng.guo@...el.com>
>>
>> Enable VFs to create FDIR filters from raw binary patterns.
>> The corresponding processes for raw flow are added in the
>> Parse / Create / Destroy stages.
>>
>> Reviewed-by: Marcin Szycik <marcin.szycik@...ux.intel.com>
>> Signed-off-by: Junfeng Guo <junfeng.guo@...el.com>
>> Co-developed-by: Ahmed Zaki <ahmed.zaki@...el.com>
>> Signed-off-by: Ahmed Zaki <ahmed.zaki@...el.com>
> 
> ...
> 
>> diff --git a/drivers/net/ethernet/intel/ice/ice_flow.c b/drivers/net/ethernet/intel/ice/ice_flow.c
> 
> ...
> 
>> +/**
>> + * ice_flow_set_parser_prof - Set flow profile based on the parsed profile info
>> + * @hw: pointer to the HW struct
>> + * @dest_vsi: dest VSI
>> + * @fdir_vsi: fdir programming VSI
>> + * @prof: stores parsed profile info from raw flow
>> + * @blk: classification blk
>> + */
>> +int
>> +ice_flow_set_parser_prof(struct ice_hw *hw, u16 dest_vsi, u16 fdir_vsi,
>> +			 struct ice_parser_profile *prof, enum ice_block blk)
>> +{
>> +	u64 id = find_first_bit(prof->ptypes, ICE_FLOW_PTYPE_MAX);
>> +	struct ice_flow_prof_params *params __free(kfree);
>> +	u8 fv_words = hw->blk[blk].es.fvw;
>> +	int status;
>> +	int i, idx;
>> +
>> +	params = kzalloc(sizeof(*params), GFP_KERNEL);
>> +	if (!params)
>> +		return -ENOMEM;
> 
> 
> params seems to be leaked when this function returns below,
> in both error and non-error cases.

Shouldn't the __free guard take care of this?

> 
>> +
>> +	for (i = 0; i < ICE_MAX_FV_WORDS; i++) {
>> +		params->es[i].prot_id = ICE_PROT_INVALID;
>> +		params->es[i].off = ICE_FV_OFFSET_INVAL;
>> +	}
>> +
>> +	for (i = 0; i < prof->fv_num; i++) {
>> +		if (hw->blk[blk].es.reverse)
>> +			idx = fv_words - i - 1;
>> +		else
>> +			idx = i;
>> +		params->es[idx].prot_id = prof->fv[i].proto_id;
>> +		params->es[idx].off = prof->fv[i].offset;
>> +		params->mask[idx] = (((prof->fv[i].msk) << BITS_PER_BYTE) &
>> +				      HI_BYTE_IN_WORD) |
>> +				    (((prof->fv[i].msk) >> BITS_PER_BYTE) &
>> +				      LO_BYTE_IN_WORD);
>> +	}
>> +
>> +	switch (prof->flags) {
>> +	case FLAG_GTPU_DW:
>> +		params->attr = ice_attr_gtpu_down;
>> +		params->attr_cnt = ARRAY_SIZE(ice_attr_gtpu_down);
>> +		break;
>> +	case FLAG_GTPU_UP:
>> +		params->attr = ice_attr_gtpu_up;
>> +		params->attr_cnt = ARRAY_SIZE(ice_attr_gtpu_up);
>> +		break;
>> +	default:
>> +		if (prof->flags_msk & FLAG_GTPU_MSK) {
>> +			params->attr = ice_attr_gtpu_session;
>> +			params->attr_cnt = ARRAY_SIZE(ice_attr_gtpu_session);
>> +		}
>> +		break;
>> +	}
>> +
>> +	status = ice_add_prof(hw, blk, id, (u8 *)prof->ptypes,
>> +			      params->attr, params->attr_cnt,
>> +			      params->es, params->mask, false, false);
>> +	if (status)
>> +		return status;
>> +
>> +	status = ice_flow_assoc_fdir_prof(hw, blk, dest_vsi, fdir_vsi, id);
>> +	if (status)
>> +		ice_rem_prof(hw, blk, id);
>> +
>> +	return status;
>> +}
> 
> ...
> 
>> diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
>> index 5635e9da2212..9138f7783da0 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
>> @@ -1,8 +1,8 @@
>>   // SPDX-License-Identifier: GPL-2.0
>>   /* Copyright (C) 2022, Intel Corporation. */
>>   
>> -#include "ice_vf_lib_private.h"
>>   #include "ice.h"
>> +#include "ice_vf_lib_private.h"
>>   #include "ice_lib.h"
>>   #include "ice_fltr.h"
>>   #include "ice_virtchnl_allowlist.h"
> 
> To me tweaking the order of includes seems to indicate
> that something isn't quite right. Is there some sort of
> dependency loop being juggled here?

This was needed because of the changes in ice_flow.h, struct ice_vsi is 
now used. I will check if there is a better fix.


> 
>> diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.h b/drivers/net/ethernet/intel/ice/ice_vf_lib.h
>> index fec16919ec19..be4266899690 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.h
>> +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.h
>> @@ -12,6 +12,7 @@
>>   #include <net/devlink.h>
>>   #include <linux/avf/virtchnl.h>
>>   #include "ice_type.h"
>> +#include "ice_flow.h"
>>   #include "ice_virtchnl_fdir.h"
>>   #include "ice_vsi_vlan_ops.h"
>>   
> 
> ...
> 
>> diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
>> index 1c6ce0c4ed4e..886869648c91 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
>> @@ -1,9 +1,9 @@
>>   // SPDX-License-Identifier: GPL-2.0
>>   /* Copyright (C) 2022, Intel Corporation. */
>>   
>> +#include "ice.h"
>>   #include "ice_virtchnl.h"
>>   #include "ice_vf_lib_private.h"
>> -#include "ice.h"
>>   #include "ice_base.h"
>>   #include "ice_lib.h"
>>   #include "ice_fltr.h"
> 
> ...
> 
>> @@ -784,6 +798,106 @@ ice_vc_fdir_config_input_set(struct ice_vf *vf, struct virtchnl_fdir_add *fltr,
>>   	return ret;
>>   }
>>   
>> +/**
>> + * ice_vc_fdir_is_raw_flow
>> + * @proto: virtchnl protocol headers
>> + *
>> + * Check if the FDIR rule is raw flow (protocol agnostic flow) or not.
>> + * Note that common FDIR rule must have non-zero proto->count.
>> + * Thus, we choose the tunnel_level and count of proto as the indicators.
>> + * If both tunnel_level and count of proto are zeros, this FDIR rule will
>> + * be regarded as raw flow.
>> + *
>> + * Returns wheater headers describe raw flow or not.
>> + */
>> +static bool
>> +ice_vc_fdir_is_raw_flow(struct virtchnl_proto_hdrs *proto)
>> +{
>> +	return (proto->tunnel_level == 0 && proto->count == 0);
> 
> nit: Parentheses are not needed here.
>       Likewise elsewhere >
>> +
>> +/**
>> + * ice_vc_fdir_parse_raw
>> + * @vf: pointer to the VF info
>> + * @proto: virtchnl protocol headers
>> + * @conf: FDIR configuration for each filter
>> + *
>> + * Parse the virtual channel filter's raw flow and store it in @conf
>> + *
>> + * Return: 0 on success, and other on error.
>> + */
>> +static int
>> +ice_vc_fdir_parse_raw(struct ice_vf *vf,
>> +		      struct virtchnl_proto_hdrs *proto,
>> +		      struct virtchnl_fdir_fltr_conf *conf)
>> +{
>> +	u8 *pkt_buf, *msk_buf __free(kfree);
>> +	struct ice_parser_result rslt;
>> +	struct ice_pf *pf = vf->pf;
>> +	struct ice_parser *psr;
>> +	int status = -ENOMEM;
>> +	struct ice_hw *hw;
>> +	u16 udp_port = 0;
>> +
>> +	pkt_buf = kzalloc(proto->raw.pkt_len, GFP_KERNEL);
>> +	msk_buf = kzalloc(proto->raw.pkt_len, GFP_KERNEL);
> 
> msk_buf appears to be leaked both in when this function
> returns for both error and non-error cases.

Same, guarded by __free. I am new to these guards myself, pls let me 
know if I am missing something.

Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ