netdev - RE: [PATCH iwl-next] ice: alter feature support check for SRIOV and LAG

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: <MW5PR11MB581150E2535B00AD04A37913DD8AA@MW5PR11MB5811.namprd11.prod.outlook.com>
Date: Fri, 8 Dec 2023 22:24:06 +0000
From: "Ertman, David M" <david.m.ertman@...el.com>
To: "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Brandeburg, Jesse"
	<jesse.brandeburg@...el.com>
Subject: RE: [PATCH iwl-next] ice: alter feature support check for SRIOV and
 LAG

> -----Original Message-----
> From: Nguyen, Anthony L <anthony.l.nguyen@...el.com>
> Sent: Friday, December 8, 2023 1:18 PM
> To: Ertman, David M <david.m.ertman@...el.com>; intel-wired-
> lan@...ts.osuosl.org
> Cc: netdev@...r.kernel.org; Brandeburg, Jesse
> <jesse.brandeburg@...el.com>
> Subject: Re: [PATCH iwl-next] ice: alter feature support check for SRIOV and
> LAG
> 
> 
> 
> On 12/7/2023 10:21 AM, Dave Ertman wrote:
> > Previously, the ice driver had support for using a hanldler for bonding
> > netdev events to ensure that conflicting features were not allowed to be
> > activated at the same time.  While this was still in place, additional
> > support was added to specifically support SRIOV and LAG together.  These
> > both utilized the netdev event handler, but the SRIOV and LAG feature was
> > behind a capabilities feature check to make sure the current NVM has
> > support.
> >
> > The exclusion part of the event handler should be removed since there are
> > users who have custom made solutions that depend on the non-exclusion
> of
> > features.
> >
> > Wrap the creation/registration and cleanup of the event handler and
> > associated structs in the probe flow with a feature check so that the
> > only systems that support the full implementation of LAG features will
> > initialize support.  This will leave other systems unhindered with
> > functionality as it existed before any LAG code was added.
> 
> This sounds like a bug fix? Should it be for iwl-net?
>

To my knowledge, this issue has not been reported by any users and was found
through code inspection.  Would you still recommend iwl-net?

DaveE
 
> > Reviewed-by: Jesse Brandeburg <jesse.brandeburg@...el.com>
> > Signed-off-by: Dave Ertman <david.m.ertman@...el.com>
> > ---
> >   drivers/net/ethernet/intel/ice/ice_lag.c | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_lag.c
> b/drivers/net/ethernet/intel/ice/ice_lag.c
> > index 280994ee5933..b47cd43ae871 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_lag.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_lag.c
> > @@ -1981,6 +1981,8 @@ int ice_init_lag(struct ice_pf *pf)
> >   	int n, err;
> >
> >   	ice_lag_init_feature_support_flag(pf);
> > +	if (!ice_is_feature_supported(pf, ICE_F_SRIOV_LAG))
> > +		return 0;
> >
> >   	pf->lag = kzalloc(sizeof(*lag), GFP_KERNEL);
> >   	if (!pf->lag)