linux-kernel - Re: linux-next: build failure after merge of the vfs 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: <20180919094847.2103082b@canb.auug.org.au>
Date:   Wed, 19 Sep 2018 09:49:42 +1000
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     David Howells <dhowells@...hat.com>
Cc:     Al Viro <viro@...IV.linux.org.uk>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the vfs tree

Hi David,

On Tue, 18 Sep 2018 23:17:21 +0100 David Howells <dhowells@...hat.com> wrote:
>
> Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> 
> > > After merging the vfs tree, today's linux-next build (powerpc
> > > allyesconfig) failed like this:
> > > 
> > > samples/vfs/test-fsinfo.c: In function 'fsinfo':
> > > samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use in this function); did you mean 'fsinfo'?  
> 
> I think the problem is that I haven't allocated system call numbers for any
> arches other than x86 - even the x86 syscall numbers are provisional until the
> patchset is taken upstream.  I'm not sure of the best way to deal with this -
> make the samples dependent on the X86 arch?

But the sample programs are built with HOSTCC, so you can't depend on
ARCH (since I, for one, am cross compiling).  Maybe SUBARCH.  Better
would be to use either Kconfig's shell primitive or some make magic to
figure out if the syscall number define's are defined.

> > > samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long unsigned int'} [-Wformat=]
> > >   printf("\tmax file size: %llx\n", f->max_file_size);  
> 
> Sigh.  On powerpc __u64 is unsigned long, but on x86_64 it's unsigned long
> long.  Is it possible to shift all arches to use unsigned long long for __u64?

I doubt it - that would probably cause more warnings in the arch code.
Instead, just explicitly cast it to unsigned long long.
-- 
Cheers,
Stephen Rothwell

Content of type "application/pgp-signature" skipped