On Thu, May 11, 2023 at 07:46:06AM +0100, Mauro Carvalho Chehab wrote: > Em Wed, 10 May 2023 11:02:57 +0200 "Linux regression tracking (Thorsten Leemhuis)" escreveu: > > On 10.05.23 10:05, Mauro Carvalho Chehab wrote: > > > Em Mon, 8 May 2023 09:27:28 -0700 > > > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> escreveu: > > >> On Mon, May 8, 2023 at 3:55 AM Linux regression tracking #adding > > >> (Thorsten Leemhuis) <regressions@xxxxxxxxxxxxx> wrote: > > >>> > > >>> Thanks for the report. The fixes (see the mail from Laurent) apparently > > >>> are still not mainlined (or am I missing something?), so let me add this > > >>> report to the tracking to ensure this is not forgotten: > > >> > > >> Gaah. I was intending to apply the patch directly before rc1, but then > > >> I forgot about this issue. > > >> > > >> Mauro: I'm currently really *really* fed up with the media tree. This > > >> exact same thing happened last merge window, where the media tree > > >> caused pointless build errors, and it took way too long to get the > > >> fixes the proper ways. > > > [...] > > > > > > In the specific case of this fixup patch, I didn't identify it as a build > > > issue, so it followed the usual workflow. We have a huge number of patches > > > for media, and it usually takes some time to handle all of them. This one > > > just followed the normal flow, as it didn't break Jenkins builds nor the > > > subject mentioned anything about build breakage. > > > > Makes me wonder again if we should start adding > > > > CC: regressions@xxxxxxxxxxxxxxx > > > > to any patches that fix regressions, that way maintainers and reviewers > > would have something to filter for -- and I would become aware of all > > regression fixes in the work, too. > > Having some way that could be parsed by e-mail filters would be > nice. The presence of a Fixes: tag is already a strong indication that the patch should be prioritized. Looking at the last 10 kernel releases, here's the number of commits with a Fixes: tag in drivers/media/: v5.14 - v5.15: 19 v5.15 - v5.16: 36 v5.16 - v5.17: 50 v5.17 - v5.18: 49 v5.18 - v5.19: 25 v5.19 - v6.0: 44 v6.0 - v6.1: 35 v6.1 - v6.2: 72 v6.2 - v6.3: 39 v6.3 - v6.4-rc1: 39 Some are likely not regressions and wouldn't need to be treated with the highest priority, but keeping an eye on patches with a Fixes: tag seems doable. There's also the issue of regression fixes missing a Fixes: tag, but I doubt those would get CC: regressions@xxxxxxxxxxxxxxx, so from a mail filtering point of view, that wouldn't help. > > Ciao, Thorsten > > > > P.S.: BTW, let me tell regzbot that Linus merged the fix for the build > > failure. > > > > #regzbot fix: ba0ad6ed89f > > > > FWIW, the one for the gcc warnings[1] Laurent mentioned elsewhere in > > this thread is not merged yet afaics. > > > > [1] https://lore.kernel.org/all/20230418092007.2902984-1-arnd@xxxxxxxxxx/ > > Just sent a pull request. > > Btw, I did some changes at linux-media Jenkins instance to help early > track some extra build issues. They're all against > https://git.linuxtv.org/media_stage.git/, which is the tree where we place > media patches that are ready. We move them later, after a couple of days > to https://git.linuxtv.org/media_tree.git/. So, if something bad happens, > we have a chance to fix before setting them into a stone. With such > changes, we now have: > > 1. https://builder.linuxtv.org/job/patchwork/ > > This is a pre-merge test. It tests patch per patch the PRs with patch > sets ready to be merged, with W=1, allyesconfig/almodconfig[1] on x86_64. > Builds drivers/media and drivers/staging/media. > This is there already for a long time; > > 2. https://builder.linuxtv.org/job/media_stage_clang/ > > Checks build with clang-12 on x86_64 with W=1. Builds drivers/media > and drivers/staging/media with allyesconfig[1]. > > It was building with WERROR disabled, as some core macros were > producing errors at the time I created it (and for a while). > It was modified to enable WERROR as well. > > 3. https://builder.linuxtv.org/job/media_stage_gcc-pipeline/ > > It replaces another job that was just doing builds for x86_64 > with W=1. Builds drivers/media and drivers/staging/media with > different configurations[1]: > x86_64: allyesconfig, allmodconfig, almodconfig with PM disabled; > arm32: allyesconfig > arm64: allyesconfig > > 4. https://builder.linuxtv.org/job/linux-media/ > > Does full builds with different configurations[1]: > x86_64: allyesconfig, allmodconfig, almodconfig with PM disabled; > arm32: allyesconfig > arm64: allyesconfig > docs: htmldocs and pdfdocs > > I hope this will help avoiding future build regressions from our side. > Feel free to suggest a couple of other configs that we might add to > jobs (3) and (4). > > I'm still adjusting the pipeline for (4), but currently, it is failing > on an issue that seems unrelated with the media subsystem with gcc 10.2.1: > > AR drivers/built-in.a > AR built-in.a > AR vmlinux.a > LD vmlinux.o > vmlinux.o: warning: objtool: vmx_vcpu_enter_exit+0x2d8: call to vmread_error_trampoline() leaves .noinstr.text section > vmlinux.o: warning: objtool: lkdtm_UNSET_SMEP+0xe1: relocation to !ENDBR: native_write_cr4+0x40 > > Is this a known regression? The media-stage tree is on the top of > Kernel 6.4-rc1. > > Regards, > Mauro > > - > > [1] On all builds, the jobs disable some symbols that should not affect > media subsystem, to speedup the builds: > > scripts/config -d MODULE_SIG -d KEYS -d IMA -d CONFIG_DEBUG_INFO -d SYSTEM_TRUSTED_KEYRING -d MODVERSIONS -- Regards, Laurent Pinchart
