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: <21390.1702078254@famine>
Date: Fri, 08 Dec 2023 15:30:54 -0800
From: Jay Vosburgh <jay.vosburgh@...onical.com>
To: "Ertman, David M" <david.m.ertman@...el.com>
cc: "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
    "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
    "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
    "Brandeburg,
    Jesse" <jesse.brandeburg@...el.com>,
    Robert Malz <robert.malz@...onical.com>,
    Heitor Alves de Siqueira <heitor.de.siqueira@...onical.com>
Subject: Re: [PATCH iwl-next] ice: alter feature support check for SRIOV and LAG

Ertman, David M <david.m.ertman@...el.com> wrote:

>> -----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?

	We have a customer experiencing intermittent issues with
transmit timeouts that go away if we disable the LAG integration as
suggested at [0] (or don't use bonding).  This is on the Ubuntu 5.15
based distro kernel, not upstream, but it does not manifest with the OOT
driver, and seems somehow related to the LAG offloading functionality.

	There was also a post to the list describing similar effects
last month [1], that one seems to be on an Ubuntu 6.2 distro kernel.

	Could these issues be plausibly related to the change in this
patch?

	-J
	
[0]
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2036239/comments/40
[1]
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20231120/038096.html



>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)

---
	-Jay Vosburgh, jay.vosburgh@...onical.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ