Em Wed, 10 May 2023 11:02:57 +0200 "Linux regression tracking (Thorsten Leemhuis)" <regressions@xxxxxxxxxxxxx> 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. > > 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
