> -----Original Message----- > From: Intel-wired-lan <[email protected]> On Behalf Of Simon > Horman > Sent: Friday, May 31, 2024 8:12 PM > To: Zaki, Ahmed <[email protected]> > Cc: Guo, Junfeng <[email protected]>; [email protected]; Marcin > Szycik <[email protected]>; Nguyen, Anthony L > <[email protected]>; Keller, Jacob E <[email protected]>; > intel- > [email protected] > Subject: Re: [Intel-wired-lan] [PATCH iwl-next v2 11/13] ice: enable FDIR > filters > from raw binary patterns for VFs > > On Fri, May 31, 2024 at 09:47:47AM -0600, Ahmed Zaki wrote: > > > > > > 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 <[email protected]> > > > > > > > > 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 <[email protected]> > > > > Signed-off-by: Junfeng Guo <[email protected]> > > > > Co-developed-by: Ahmed Zaki <[email protected]> > > > > Signed-off-by: Ahmed Zaki <[email protected]> > > > > > > ... > > > > > > > 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? > > Yes, sorry for missing that. > > ... > > > > > 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. > > Thanks. > > ... > > > > > +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. > > No, sorry. Somehow I missed the __free. > I think we are good here.
Tested-by: Rafal Romanowski <[email protected]>
