linux-kernel - Re: linux-next: build failure after merge of the arm tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZjSfDGh+yqndr9ya@shell.armlinux.org.uk>
Date: Fri, 3 May 2024 09:23:40 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the arm tree

On Fri, May 03, 2024 at 09:18:01AM +0100, Russell King (Oracle) wrote:
> On Fri, May 03, 2024 at 10:15:16AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the arm tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > drivers/clk/clkdev.c: In function 'vclkdev_alloc':
> > drivers/clk/clkdev.c:195:16: error: assignment to '__va_list_tag (*)[1]' from incompatible pointer type '__va_list_tag **' [-Werror=incompatible-pointer-types]
> >   195 |         fmt.va = &ap;
> >       |                ^
> > cc1: all warnings being treated as errors
> 
> This builds perfectly fine for me - this is on debian stable with
> arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110:
> 
>   CC      drivers/clk/clkdev.o
>   AR      drivers/clk/built-in.a
>   AR      drivers/built-in.a
>   AR      built-in.a
>   AR      vmlinux.a
>   LD      vmlinux.o
>   OBJCOPY modules.builtin.modinfo
>   GEN     modules.builtin
>   MODPOST Module.symvers
>   UPD     include/generated/utsversion.h
>   CC      init/version-timestamp.o
>   LD      .tmp_vmlinux.kallsyms1
>   NM      .tmp_vmlinux.kallsyms1.syms
>   KSYMS   .tmp_vmlinux.kallsyms1.S
>   AS      .tmp_vmlinux.kallsyms1.S
>   LD      .tmp_vmlinux.kallsyms2
>   NM      .tmp_vmlinux.kallsyms2.syms
>   KSYMS   .tmp_vmlinux.kallsyms2.S
>   AS      .tmp_vmlinux.kallsyms2.S
>   LD      vmlinux
>   NM      System.map
> 
> No warnings, no errors.
> 
> va_format is defined as:
> 
> struct va_format {
>         const char *fmt;
>         va_list *va;
> };
> 
> and what we have here is a "va_list ap".
> 
> Therefore, the assignment:
> 
>         fmt.va = &ap;
> 
> is correct.
> 
> What certainly won't work is:
> 
> 	fmt.va = ap;
> 
> and there aren't any other reasonable alternatives.
> 
> My conclusion: your compiler is being stupid.

.. and even more evidence that your error is strange:

void __ext4_error(struct super_block *sb, const char *function,
                  unsigned int line, bool force_ro, int error, __u64 block,
                  const char *fmt, ...)
{
        struct va_format vaf;
        va_list args;

                vaf.fmt = fmt;
                vaf.va = &args;

Now, looking at __ext4_error(), it seems that va_start()..va_end()
need to be around this - but why this oddity? None of the other printing
functions like vsnprintf() require it? Why do we have this pitfall?
Why isn't this oddity documented anywhere?

However, I don't see that lack of va_start() etc would cause a type
error.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!