13:01:37 <jki_> #startmeeting CIP IRC weekly meeting
13:01:38 <collab-meetbot> Meeting started Thu Feb 20 13:01:37 2025 UTC and is due to finish in 60 minutes.  The chair is jki_. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:38 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:38 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
13:01:48 <jki_> #topic AI review
13:01:52 <jki_> none recorded
13:02:03 <jki_> 5
13:02:04 <jki_> 4
13:02:06 <jki_> 3
13:02:07 <jki_> 2
13:02:09 <jki_> 1
13:02:11 <jki_> #topic Kernel maintenance updates
13:02:34 <uli_> no updates from me this week
13:02:36 <pave1> I was reviewing 6.1.129.
13:02:37 <masami> This week reported 20 new CVEs and 2 updated CVEs.
13:02:50 <iwamatsu__> I am reviewing 6.1.129.
13:02:54 <masami> I am currently implementing a process to extract version information for commits such as "fixed-by".
13:04:06 <jki_> as already written in the invitation, this is relevant for our old RT kernels:
13:04:07 <jki_> https://lore.kernel.org/stable-rt/CAMLffL-PTp+Y-rXsTFaC5cUJyMMiXk-Gjx59WiQvcTe46rXFrw@mail.gmail.com/T/#m67dce3408cac40318ae3dbe1c713b13621ac66c9
13:04:58 <jki_> should also come via stable-rt at some point, but as that channel already lost it (partially)
13:06:05 <pave1> Ok, let me take a look.
13:07:19 <jki_> anything else?
13:07:46 <jki_> 5
13:07:48 <jki_> 4
13:07:50 <jki_> 3
13:07:52 <jki_> 2
13:07:53 <jki_> 1
13:07:55 <jki_> #topic Kernel release status
13:08:22 <jki_> was all green today - good :)
13:08:34 <pave1> Good :-).
13:09:04 <jki_> then let's move on
13:09:06 <jki_> 5
13:09:08 <jki_> 4
13:09:09 <jki_> 3
13:09:10 <jki_> 2
13:09:12 <jki_> 1
13:09:14 <jki_> #topic Kernel testing
13:09:33 <patersonc> Hey, sorry I'm late
13:09:44 <patersonc> I don't think I have any updates this week anyway
13:09:57 <arisut> Relesed kci-dev v0.1.3 with some fixes for bisection command and results
13:10:11 <arisut> https://kci.dev/
13:10:29 <arisut> this is now the link of kci-dev documentation
13:13:21 <jki_> I'd like to bring the testing topic of RT up again (this week)
13:13:46 <jki_> the issue cited above was visible with the right nft settings and lockdep
13:14:06 <jki_> is RT, ours or upstream, also running with lockdep on?
13:14:15 <jki_> in kernelci or our lab?
13:15:01 <jki_> yes, it still needs code paths to be run, but if lockdep is even off...
13:15:09 <patersonc> Is that a kernel config thing?
13:15:20 <jki_> also
13:15:45 <jki_> but lockdep is (hopefully) not found in any contributed member production configs
13:16:01 <jki_> it's rather a "testing overlay"
13:16:34 <patersonc> We can check what KernelCI does - I know they run more tests then we do
13:17:01 <arisut> yes, but I don't remember if lockdep is enabled
13:17:14 <arisut> we should check it
13:17:17 <pave1> Yep so... people should not be running lockdep in production.
13:17:23 <jki_> would be good to understand what was missing to let this commit slip through
13:17:36 <pave1> And I would not be surprised if lockdep increased latencies somewhere.
13:17:42 <jki_> yes, but people should run it during QA
13:17:53 <jki_> for correctness checking
13:18:21 <pave1> Yes; we likely want lockdep on to see if it find anything, and then lockdep off to see what the real latencies are :-(.
13:18:22 <jki_> the commit-triggered Xenomai pipelines run will almost all debug switches enabled, always
13:18:33 <jki_> exactly
13:18:42 <jki_> functional vs. non-functional testing
13:19:13 <jki_> just that the funcitonal tests luckily rarely need to run for days ;)
13:19:54 <jki_> who could have a look in kernelci?
13:20:07 <jki_> and we can already rule out that our lab has that enabled, right?
13:20:51 <patersonc> Yea, CIP doesn't
13:21:51 <arisut> jki_, KernelCI looks like is using CONFIG_PROVE_LOCKING
13:22:07 <jki_> that's what I was looking for, yes
13:22:10 <arisut> with CONFIG_LOCKDEP
13:22:19 <arisut> https://github.com/kernelci/kernelci-core/blob/2b4433eeb8ae18274e43c4c806350f1efe4d3a5b/config/core/build-configs.yaml#L495
13:22:29 <jki_> then we were "only" missing the code path that the patch above is touching
13:23:32 <jki_> and that kcidebug is surely applied on all input kernels? just to double-check the logic
13:25:10 <arisut> only machine that allow defconfig+kcidebug
13:25:12 <pave1> Well, its netfilter. That is not going to be easy to test. Plus I really hope people are not expecting realtime performance on network routing, because I'm pretty sure we can't do that :-).
13:26:07 <jki_> no, "just" correctness when having such a firewall rule on an some edge device with container & co + RT
13:26:16 <jki_> "normal" setup...
13:27:13 <jki_> we are currently trying to reproduce the case artificially
13:27:33 <jki_> lockdep was triggering immediately, though - with the right nftable settings
13:27:34 <arisut> not sure about what is currently running with kcidebug
13:28:01 <jki_> we don't need to clarify now
13:28:35 <jki_> but it would be important that some pipeline with the CIP RT kernels would also have lock validation enabled
13:28:43 <pave1> +1
13:28:48 <jki_> for now at least
13:28:52 <jki_> good
13:29:02 <jki_> let's check offline and revisit next time
13:29:20 <pave1> But please don't mix containers + realtime + expectations it will work together flawlessly :-).
13:29:38 <jki_> too late :)
13:29:56 <pave1> It still not too late to adjust the expectations :-)_
13:30:55 <jki_> more testing topics for today?
13:32:06 <jki_> 5
13:32:08 <jki_> 4
13:32:09 <jki_> 3
13:32:11 <jki_> 2
13:32:13 <jki_> 1
13:32:16 <jki_> #topic AOB
13:34:36 <jki_> anything for today?
13:34:52 <jki_> 5
13:34:54 <jki_> 4
13:34:56 <jki_> 3
13:34:57 <jki_> 2
13:34:59 <jki_> 1
13:35:01 <jki_> #endmeeting