netdev - Re: sr-iov related bonding regression (two regressions in one report)

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: <7AC9E8F6-B229-47AA-84CE-1149F45D7E0F@gmail.com>
Date: Wed, 15 Nov 2023 12:48:51 -0800
From: Anil Choudhary <anilchabba@...il.com>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Jay Vosburgh <jay.vosburgh@...onical.com>,
 Bagas Sanjaya <bagasdotme@...il.com>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Linux Networking <netdev@...r.kernel.org>,
 Linux Intel Wired LAN <intel-wired-lan@...ts.osuosl.org>,
 Andy Gospodarek <andy@...yhouse.net>,
 Ivan Vecera <ivecera@...hat.com>,
 Jesse Brandeburg <jesse.brandeburg@...el.com>,
 Tony Nguyen <anthony.l.nguyen@...el.com>,
 Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>
Subject: Re: sr-iov related bonding regression (two regressions in one report)

We are getting errorError subscribing to SWID 0x0000.
 from following code
root@...ash-r1-c2-m1:~/linux# grep -rn -e "subscribing to " .
grep: ./debian/linux-image/lib/modules/6.6.1-vdx/kernel/drivers/net/ethernet/intel/ice/ice.ko: binary file matches
./samples/connector/ucon.c:149: ulog("subscribing to %u.%u\n", CN_TEST_IDX, CN_TEST_VAL);
./Documentation/driver-api/media/v4l2-event.rst:117:add      called when a new listener gets added (subscribing to the same
./Documentation/driver-api/media/v4l2-event.rst:130:Unsubscribing to an event is via:
./Documentation/maintainer/feature-and-driver-maintainers.rst:44:mailing list. Either by subscribing to the whole list or using more
grep: ./drivers/net/ethernet/intel/ice/ice_lag.o: binary file matches
grep: ./drivers/net/ethernet/intel/ice/ice.o: binary file matches
grep: ./drivers/net/ethernet/intel/ice/ice.ko: binary file matches
./drivers/net/ethernet/intel/ice/ice_lag.c:1007:                dev_err(ice_pf_to_dev(local_lag->pf), "Error subscribing to SWID 0x%04X\n",
root@...ash-r1-c2-m1:~/linux#


Thanks,
Anil



> On Nov 14, 2023, at 10:19 PM, Anil Choudhary <anilchabba@...il.com> wrote:
> 
> <PastedGraphic-1.png>
> 
> 
> Following error error scribing to said is also new
> 
>> On Nov 14, 2023, at 9:50 PM, Linux regression tracking (Thorsten Leemhuis) <regressions@...mhuis.info> wrote:
>> 
>> On 15.11.23 01:54, Jay Vosburgh wrote:
>>> Bagas Sanjaya <bagasdotme@...il.com> wrote:
>>> 
>>>> I come across LACP bonding regression on Bugzilla [1].
>> 
>> Side note: Stephen forwards some (all?) network regressions to the right
>> people:
>> https://lore.kernel.org/all/20231113083746.5e02f8b0@hermes.local/
>> 
>> Would be best to check for that, no need to forward things twice, that
>> just results in a mess.
>> 
>>>> The reporter
>>>> (Cc'ed) has two regressions. The first is actual LACP bonding
>>>> regression (but terse):
>>>> 
>>>>> Till linkx kernel 6.5.7 it is working fine, but after upgrading to 6.6.1 ping stop working with LACP bonding.
>>>>> When we disable SR-IOV from bios , everything working fine
>> 
>> Makes me wonder if things have been working with or without the OOT
>> module on 6.5.7, as strictly speaking it's only considered a kernel
>> regression if thing worked with a vanilla kernel (e.g. without OOT
>> modules) beforehand and broke when switching to a newer vanilla kernel.
>> If that's the case it would be okay to add to regzbot.
>> 
>>>> And the second is out-of-tree module FTBFS:
>>> [... skip OOT stuff ...]
>>> 
>>>> Should I add the first regression to regzbot (since the second one
>>>> is obviously out-of-tree problem), or should I asked detailed regression
>>>> info to the reporter?
>>> 
>>> 	My vote is to get additional information.  Given the nature of
>>> the workaround ("When we disable SR-IOV from bios , everything working
>>> fine"), it's plausible that the underlying cause is something
>>> platform-specific.
>> 
>> Maybe, but when it comes to the "no regressions" rule that likely makes
>> no difference from Linus perspective.
>> 
>> But I guess unless the intel folks or someone else has an idea what
>> might be wrong here we likely need a bisection (with vanilla kernels of
>> course) to get anywhere.
>> 
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>> --
>> Everything you wanna know about Linux kernel regression tracking:
>> https://linux-regtracking.leemhuis.info/about/#tldr
>> If I did something stupid, please tell me, as explained on that page.
>