Message-ID: <20230511074606.0349fc69@sal.lan>
Date:   Thu, 11 May 2023 07:46:06 +0100
From:   Mauro Carvalho Chehab <mchehab@...nel.org>
To:     "Linux regression tracking (Thorsten Leemhuis)" 
        <regressions@...mhuis.info>
Cc:     Linux regressions mailing list <regressions@...ts.linux.dev>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Sudip Mukherjee (Codethink)" <sudipm.mukherjee@...il.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        NXP Linux Team <linux-imx@....com>,
        linux-media@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>
Subject: Re: mainline build failure due to cf21f328fcaf ("media: nxp: Add
 i.MX8 ISI driver")

Em Wed, 10 May 2023 11:02:57 +0200
"Linux regression tracking (Thorsten Leemhuis)" <regressions@...mhuis.info> escreveu:

> On 10.05.23 10:05, Mauro Carvalho Chehab wrote:
> > Em Mon, 8 May 2023 09:27:28 -0700
> > Linus Torvalds <torvalds@...ux-foundation.org> escreveu:  
> >> On Mon, May 8, 2023 at 3:55 AM Linux regression tracking #adding
> >> (Thorsten Leemhuis) <regressions@...mhuis.info> 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@...ts.linux.dev
> 
> 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@kernel.org/

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

Powered by blists - more mailing lists