On 19.07.23 14:30, Bagas Sanjaya wrote: > On 7/19/23 18:49, Thorsten Leemhuis wrote: >> On 18.07.23 02:51, Bagas Sanjaya wrote: >>> I notice a regression report on Bugzilla [1]. Quoting from it: >>> >>>> After I updated to 6.4 through Archlinux kernel update, suddenly I noticed random packet losses on my routers like nodes. I have these networking relevant config on my nodes >>>> >>>> 1. Using archlinux >>>> 2. Network config through systemd-networkd >>>> 3. Using bird2 for BGP routing, but not relevant to this bug. >>>> 4. Using nftables for traffic control, but seems not relevant to this bug. >>>> 5. Not using fail2ban like dymanic filtering tools, at least at L3/L4 level >>>> >>>> After I ruled out systemd-networkd, nftables related issues. I tracked down issues to kernel. >>> [...] >>> See Bugzilla for the full thread. >>> >>> Thorsten: The reporter had a bad bisect (some bad commits were marked as good >>> instead), hence SoB chain for culprit (unrelated) ipvu commit is in To: >>> list. I also asked the reporter (also in To:) to provide dmesg and request >>> rerunning bisection, but he doesn't currently have a reliable reproducer. >>> Is it the best I can do? >> >> When a bisection apparently went sideways it's best to not bother the >> culprit's developers with it, they most likely will just be annoyed by >> it (and then they might become annoyed by regression tracking, which we >> need to avoid). > > I mean don't Cc: the culprit author in that case? Yes. If a bisection lands on a commit that seems like a pretty unlikely culprit for the problem at hand (which even the reporter admitted in the report), then ask the reporter to verify the result (e.g. ideally by trying to revert it ontop of latest mainline; checking the parent commit again sometimes can do the trick as well) before involving the people that authored and handled said change. Otherwise you just raise a false alarm and then people will be annoyed by our work or if we are unlucky start to ignore us -- and we need to prevent that. Ciao, Thorsten
