netdev - Re: BUG? flaky "migrate_reuseport/IPv4 TCP_NEW_SYN_RECV reqsk_timer

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] [day] [month] [year] [list]

Message-ID: <20240322180841.54368-1-kuniyu@amazon.com>
Date: Fri, 22 Mar 2024 11:08:41 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <martin.lau@...ux.dev>
CC: <bpf@...r.kernel.org>, <kuni1840@...il.com>, <kuniyu@...zon.com>,
	<netdev@...r.kernel.org>
Subject: Re: BUG? flaky "migrate_reuseport/IPv4 TCP_NEW_SYN_RECV reqsk_timer_handler" test

Hi Martin,

Thanks for the report.

From: Martin KaFai Lau <martin.lau@...ux.dev>
Date: Thu, 21 Mar 2024 18:39:53 -0700
> Hi Kuniyuki,
> 
> The bpf CI has recently hit failure in the "migrate_reuseport/IPv4 
> TCP_NEW_SYN_RECV" test. It does not always fail but becomes more flaky recently:
> https://github.com/kernel-patches/bpf/actions/runs/8354884067/job/22869153115
> 
> It could be due to some slowness in the bpf CI environment but failing because 
> of environment slowness is still not expected.
> 
> I took a very quick look. It seems like the test depends on the firing of the 
> timer's handler "reqsk_timer_handler()", so there is a sleep(1) in the test.

Yes, it depends on the timing of the reqsk tiemr.


> May be the timer fired slower and the test failed? If that is the case, it may 
> help to directly trace the reqsk_timer_handler() and wait for enough time to 
> ensure it is called.

Sounds good.  I'll give it a try.

Thanks!

> 
> This test has been temporarily disabled for now 
> (https://github.com/kernel-patches/vmtest/blob/master/ci/vmtest/configs/DENYLIST). 
> Once you have a fix, we can re-enable it again to ensure this migrate feature 
> will not regress.
> 
> Thanks,
> Martin