12:03:14 <jki> #startmeeting CIP IRC weekly meeting
12:03:14 <collab-meetbot`> Meeting started Thu Jul 28 12:03:14 2022 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:03:14 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:03:14 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
12:03:23 <jki> #topic AI review
12:03:33 <jki> 1. Resolve/ignore failures of KernelCI on 4.4-cip - alicefm
12:03:58 <alicef> flo sended a pull request
12:04:08 <alicef> I did the review and testing process
12:04:35 <alicef> gtucker will do the final check late today or tomorrow
12:05:02 <jki> so, the direction makes sense for everyone so far?
12:05:12 <alicef> the pull request looks filtering correctly the cip 4.4 errors
12:05:25 <alicef> from the not needed builds
12:05:51 <jki> ok, good
12:06:01 <jki> I suppose we need some more PRs after that, right?
12:07:12 <alicef> we had some error in test results that there wasn't on the previous builds would be nice to check on that
12:07:42 <jki> pavel: are you aware of that already?
12:07:54 <alicef> and some warnings from builds
12:08:11 <pave1> jki: No, I'm not following that closely. I'll be happy when I see kernelci results with 0 fails :-).
12:08:26 <pave1> jki: Plus, we'll likely want same work on 4.19 and 5.10.
12:08:44 <jki> sure, one after the other I think though
12:08:53 <pave1> jki: Yes, one after the other.
12:09:07 <jki> alicefm: can you point pavel to the new errors/warnings you saw?
12:10:01 <alicef> we hav this warnings:
12:10:11 <alicef> 149net/ipv4/inet_hashtables.c:608:68: warning: suggest parentheses around ‘+’ in operand of ‘&’ [-Wparentheses]
12:10:47 <pave1> Yep, that one is probably real, I've seen it before and uli pointed it out in the review.
12:10:55 <alicef> https://gist.github.com/aliceinwire/6fdbe6e4269887f37f986e9771d63793/493c2b455ede3da9cd512fa1ce1cd7c95ac22de4
12:11:35 <alicef> 149 builds warnings about that
12:11:56 <pave1> Let's talk about that in the testing topic?
12:12:05 <alicef> sure
12:12:34 <jki> ok
12:12:52 <jki> 2. Check cip devices on kernelci old pull request - patersonc
12:12:59 <jki> no updates here according to chris
12:13:05 <jki> other AIs?
12:13:55 <jki> 3
12:13:56 <jki> 2
12:13:59 <jki> 1
12:14:01 <jki> #topic Kernel maintenance updates
12:14:27 <pave1> I did 5.10.134 reviews, and -rt releases for 4.19 / 5.10.
12:14:29 <masami> This week reported 5 new CVEs and 5 updated CVEs. no notable new CVEs.
12:14:30 <uli> i'm backporting patches to 4.4
12:14:52 <pave1> I believe we should do 4.4 release at this point.
12:15:58 <jki> release before those backports?
12:16:06 <jki> or after them?
12:16:31 <uli> they are fixes for xen, not sure if those should hold the release back
12:16:33 <pave1> I'd vote for before. Those backports is some kind of Xen CVEs, and there's always more to backport.
12:17:03 <jki> do we have Xen in support scope btw?
12:17:29 <pave1> (But maybe we should start tracking "what do we need to fix in 4.4" with CVE tracking).
12:20:04 <pave1> jki: We have XEN enabled in few configs. I'm not sure people are using it...
12:20:15 <pave1> qemu_arm64_defconfig:CONFIG_XEN=y
12:20:29 <pave1> arm64/renesas_defconfig:CONFIG_XEN=y
12:20:37 <pave1> x86/siemens_server_defconfig:CONFIG_NETXEN_NIC=m
12:20:39 <pave1> ...etc.
12:20:41 <jki> but arm64 is not in scope for 4.4
12:22:09 <jki> and NETXEN != Xen
12:23:06 <pave1> Well, scripts marked it as "used" in 4.9 and I did not investigate further...
12:23:18 <jki> please don't waste our time on Xen for 4.4
12:24:59 <pave1> I'd need to take a look why scripts say it is enabled.
12:25:38 <jki> at least from a quick scan of 4.4 configs, i don't see any reason
12:25:38 <pave1> Anyway I wish it was disabled in 4.19/5.10 too. If noone cares for 4.4, it is unlikely they care for later kernels.
12:26:17 <jki> arm64 might be different - but let's bring that up on the list
12:26:24 <jki> pavel: will you do?
12:26:44 <pave1> Ok, will do.
12:27:15 <jki> thanks
12:27:43 <jki> anything else kernel maintenance?
12:29:20 <jki> 3
12:29:21 <jki> 2
12:29:23 <jki> 1
12:29:25 <jki> #topic Kernel testing
12:29:56 <alicef> I made a difference file with old build and new build differences here:
12:30:01 <alicef> https://gist.github.com/aliceinwire/251b324fee1ce965d51db0b72f5dd011/revisions?diff=unified#diff-a92e01a033c084e6b1364a6737dd4c25de3a2905616d4e97b4b418d4fb67ab9b
12:30:51 <alicef> in summary the previous build errors looks dissapeared and the new net/ipv4/inet_hashtables.c:608:68: warning: suggest parentheses around ‘+’ in operand of ‘&’ [-Wparentheses] build warning appeared
12:31:23 <pave1> Yes, so that's from "tcp: change source port randomizarion at connect() time".
12:31:35 <pave1> These are some kinds of tcp privacy fixes.
12:31:45 <pave1> WRITE_ONCE(table_perturb[index], READ_ONCE(table_perturb[index]) + (i + 2) & ~1);
12:32:37 <pave1> In particular, uli believes it should be "+ ((i + 2) & ~1)" and I'm more inclined to (READ_ONCE() + i + 2) & ~1 :-)
12:33:01 <pave1> So... more reviews would not bad.
12:33:18 <alicef> there is a mail about this ?
12:33:37 <pave1> Also, running some kind of tests to ensure TCP still works with these and that the privacy issues are indeed closed would not be bad.
12:34:12 <jki> doesn't kernelci do sufficient tcp tests for us?
12:34:42 <pave1> The mail was "4.4-st20 -- Re: [cip-dev] Failures in 5.10, 4.4 testing".
12:35:50 <alicef> if the test can be included to kselftest or ltp KernelCI will pickup it
12:35:57 <alicef> eventually
12:36:50 <jki> so, there no such tests in any of them yet?
12:37:00 <jki> or we are not running that yet?
12:37:20 <alicef> we are not filtering out any test
12:37:33 <alicef> so we are running everything kernelci have
12:37:52 <alicef> that's mostly this https://staging.kernelci.org/test/job/cip/branch/linux-4.4.y-cip/kernel/v4.4.302-cip69-517-g92709d8ae585/
12:37:59 <alicef> at this time
12:38:15 <pave1> For reference, that is issues/CVE-2022-32296.yml and issues/CVE-2022-1012.yml AFAICT.
12:38:22 <alicef> they are improving new tests frequently
12:40:58 <alicef> spectre meltdown check script also had a some problems on one of the board https://staging.kernelci.org/test/plan/id/62e1181f97e5190630e19dcb/ and they are some kind of regression from 4.4 cip65 to cip 69
12:41:25 <pave1> I don't see a TCP related test in the list, much less testing TCP privacy issues...
12:41:49 <alicef> no just talking about 4.4 problems not related with tcp
12:41:58 <alicef> but still regression
12:42:50 <alicef> right in the list there is not a tcp related test or tcp privacy
12:43:01 <alicef> is something probably that shoud be improved
12:43:12 <alicef> kselftest have such tests ?
12:43:20 <alicef> or ltp
12:43:50 <alicef> if yes we can try to enable such test on kernelci
12:44:20 <pave1> I'm not familiar with kselftest or ltp. I guess wget in a loop would be basic test of tcp functionality.
12:45:08 <pave1> As for +https://staging.kernelci.org/test/plan/id/62e1181f97e5190630e19dcb/ , testing for spectre/meltdown on qemu... is not something I'd consider useful.
12:45:10 <alicef> I see
12:45:49 <pave1> If we wanted to debug this further, standard questions would be "can you bisect it"?
12:46:21 <alicef> sorry we mixed a bit problems togheter. which one are talking about ?
12:47:00 <alicef> smc?
12:47:14 <pave1> smc.
12:47:38 <pave1> But the fact that it detect problems on qemu is kind of a hint that it is test that is broken.
12:48:17 <alicef> smc test is broken?
12:48:46 <alicef> smc test is the same used by gitlab only more updated
12:48:48 <pave1> Looks like so. It is hard to believe that qemu would have spectre/metdown problem.
12:49:13 <alicef> https://github.com/speed47/spectre-meltdown-checker
12:51:40 <jki> any other topics?
12:51:51 <pave1> If you are confident there's a problem in kernel, we can try to debug it. But qemu is not a place where I'd expect it to appear.
12:52:23 <alicef> ok
12:52:33 <uli> i find that a bit odd. a bug in the cpu emulation is the first thing i would suspect...
12:52:50 <alicef> let's maybe recheck it after flo patch get merged upstream
12:53:43 <alicef> and we get the results from kernelci stable
12:54:21 <jki> ok, move on?
12:55:21 <jki> 3
12:55:23 <jki> 2
12:55:25 <jki> 1
12:55:28 <jki> #topic AOB
12:55:51 <jki> any topcis for the upcoming eTSC meeting?
12:58:14 <jki> seems like we are all happy... ;-)
12:58:25 <pave1> Happy :-).
12:58:46 <jki> next CIP kernel and related efforts will likely be a topic again
12:59:07 <jki> I would also use the chance to ask around for 4.4 usage of our members
12:59:32 <jki> another call for more contributions to testing...
13:01:05 <jki> anything else, in general?
13:01:28 <jki> 3
13:01:30 <jki> 2
13:01:32 <jki> 1
13:01:34 <jki> #endmeeting