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

[Al Viro]

On Tue, Jan 05, 2021 at 09:36:16AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> In file included from arch/x86/include/asm/elf.h:8,
>  from include/linux/elf.h:6,
>  from include/linux/elfcore-compat.h:5,
>  from fs/compat_binfmt_elf.c:17:
> fs/binfmt_elf.c: In function 'fill_thread_core_info':
> arch/x86/include/asm/elfcore-compat.h:23:20: error: 'TIF_X32' undeclared 
> (first use in this function)
>23 |  (test_thread_flag(TIF_X32) \
>   |^~~
> include/linux/thread_info.h:116:45: note: in definition of macro 
> 'test_thread_flag'
>   116 |  test_ti_thread_flag(current_thread_info(), flag)
>   | ^~~~
> fs/binfmt_elf.c:1744:5: note: in expansion of macro 'PRSTATUS_SIZE'
>  1744 | PRSTATUS_SIZE, >prstatus);
>   | ^
> arch/x86/include/asm/elfcore-compat.h:23:20: note: each undeclared identifier 
> is reported only once for each function it appears in
>23 |  (test_thread_flag(TIF_X32) \
>   |^~~
> include/linux/thread_info.h:116:45: note: in definition of macro 
> 'test_thread_flag'
>   116 |  test_ti_thread_flag(current_thread_info(), flag)
>   | ^~~~
> fs/binfmt_elf.c:1744:5: note: in expansion of macro 'PRSTATUS_SIZE'
>  1744 | PRSTATUS_SIZE, >prstatus);
>   | ^
> 
> Caused by commit
> 
>   5a9b7f382248 ("binfmt_elf: partially sanitize PRSTATUS_SIZE and 
> SET_PR_FPVALID")
> 
> or maybe commit
> 
>   9866fcab1c65 ("[elfcore-compat][amd64] clean PRSTATUS_SIZE/SET_PR_FPVALID 
> up properly")

Arrgh...  It's 8d71d2bf6efe ("x86: Reclaim TIF_IA32 and TIF_X32") in mainline, 
actually.
Mea culpa ;-/

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi all,

After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

In file included from arch/x86/include/asm/elf.h:8,
 from include/linux/elf.h:6,
 from include/linux/elfcore-compat.h:5,
 from fs/compat_binfmt_elf.c:17:
fs/binfmt_elf.c: In function 'fill_thread_core_info':
arch/x86/include/asm/elfcore-compat.h:23:20: error: 'TIF_X32' undeclared (first 
use in this function)
   23 |  (test_thread_flag(TIF_X32) \
  |^~~
include/linux/thread_info.h:116:45: note: in definition of macro 
'test_thread_flag'
  116 |  test_ti_thread_flag(current_thread_info(), flag)
  | ^~~~
fs/binfmt_elf.c:1744:5: note: in expansion of macro 'PRSTATUS_SIZE'
 1744 | PRSTATUS_SIZE, >prstatus);
  | ^
arch/x86/include/asm/elfcore-compat.h:23:20: note: each undeclared identifier 
is reported only once for each function it appears in
   23 |  (test_thread_flag(TIF_X32) \
  |^~~
include/linux/thread_info.h:116:45: note: in definition of macro 
'test_thread_flag'
  116 |  test_ti_thread_flag(current_thread_info(), flag)
  | ^~~~
fs/binfmt_elf.c:1744:5: note: in expansion of macro 'PRSTATUS_SIZE'
 1744 | PRSTATUS_SIZE, >prstatus);
  | ^

Caused by commit

  5a9b7f382248 ("binfmt_elf: partially sanitize PRSTATUS_SIZE and 
SET_PR_FPVALID")

or maybe commit

  9866fcab1c65 ("[elfcore-compat][amd64] clean PRSTATUS_SIZE/SET_PR_FPVALID up 
properly")

I have used the vfs tree from next-20210104 for today.

-- 
Cheers,
Stephen Rothwell


pgpkaiJQMmk3r.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Al,

On Tue, 10 Nov 2020 19:00:36 + Al Viro  wrote:
>
> On Tue, Oct 27, 2020 at 04:59:12AM +, Al Viro wrote:
> 
> > I'll rebase that branch on top of sparc tree tomorrow (and eventually I'd 
> > like
> > it to go through the sparc tree anyway).  
> 
> Done - sorry for disappearing ;-/

No worries and thanks.

-- 
Cheers,
Stephen Rothwell


pgpCFDkflbNrs.pgp
Description: OpenPGP digital signature

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

[Al Viro]

On Tue, Oct 27, 2020 at 04:59:12AM +, Al Viro wrote:

> I'll rebase that branch on top of sparc tree tomorrow (and eventually I'd like
> it to go through the sparc tree anyway).

Done - sorry for disappearing ;-/

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

[Al Viro]

On Tue, Oct 27, 2020 at 03:14:14PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs tree, today's linux-next build (sparc_defconfig)
> failed like this:
> 
> arch/sparc/lib/memset.S: Assembler messages:
> arch/sparc/lib/memset.S:149: Error: Unknown opcode: `ext(12b, 13b,21f)'
> 
> Caused by commit
> 
>   0e0bbae08a6e ("sparc32: switch __bzero() away from range exception table 
> entries")
> 
> merging badly with commit
> 
>   7780918b3648 ("sparc32: fix a user-triggerable oops in clear_user()")
> 
> from the sparc tree.
> 
> The sparc tree commit above appears as commit
> 
>   80537bbf19d6 ("sparc32: fix a user-triggerable oops in clear_user()")
> 
> in the vfs tree as well.  The patch adds one line which is later removed
> by commit
> 
>   0e0bbae08a6e ("sparc32: switch __bzero() away from range exception table 
> entries")
> 
> in the vfs tree, but the git merge puts the line back again :-(
> 
> I have added the following fix to the vfs tree merge

I'll rebase that branch on top of sparc tree tomorrow (and eventually I'd like
it to go through the sparc tree anyway).

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi all,

After merging the vfs tree, today's linux-next build (sparc_defconfig)
failed like this:

arch/sparc/lib/memset.S: Assembler messages:
arch/sparc/lib/memset.S:149: Error: Unknown opcode: `ext(12b, 13b,21f)'

Caused by commit

  0e0bbae08a6e ("sparc32: switch __bzero() away from range exception table 
entries")

merging badly with commit

  7780918b3648 ("sparc32: fix a user-triggerable oops in clear_user()")

from the sparc tree.

The sparc tree commit above appears as commit

  80537bbf19d6 ("sparc32: fix a user-triggerable oops in clear_user()")

in the vfs tree as well.  The patch adds one line which is later removed
by commit

  0e0bbae08a6e ("sparc32: switch __bzero() away from range exception table 
entries")

in the vfs tree, but the git merge puts the line back again :-(

I have added the following fix to the vfs tree merge

From: Stephen Rothwell 
Date: Tue, 27 Oct 2020 15:05:28 +1100
Subject: [PATCH] fix up for merge of arch/sparc/lib/memset.S

Signed-off-by: Stephen Rothwell 
---
 arch/sparc/lib/memset.S | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/sparc/lib/memset.S b/arch/sparc/lib/memset.S
index 522f45a952a0..eaff68213fdf 100644
--- a/arch/sparc/lib/memset.S
+++ b/arch/sparc/lib/memset.S
@@ -146,7 +146,6 @@ __bzero:
ZERO_LAST_BLOCKS(%o0, 0x48, %g2)
ZERO_LAST_BLOCKS(%o0, 0x08, %g2)
 13:
-   EXT(12b, 13b, 21f)
be  8f
 andcc  %o1, 4, %g0
 
-- 
2.28.0

-- 
Cheers,
Stephen Rothwell


pgp9n65n8RG92.pgp
Description: OpenPGP digital signature

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

[Josh Poimboeuf]

On Wed, Oct 07, 2020 at 08:04:05AM +1100, Stephen Rothwell wrote:
> Hi Josh,
> 
> On Tue, 6 Oct 2020 09:30:12 -0500 Josh Poimboeuf  wrote:
> >
> > On Mon, Sep 28, 2020 at 11:10:56PM -0500, Josh Poimboeuf wrote:
> > > > Josh, any ideas?  We could, of course, make it "r"(size), but that would
> > > > be unpleasant in all existing callers...  
> > > 
> > > Sorry, I've been traveling.  I'd just vote for making it "r".
> > > 
> > > array_index_nospec() is always called after a usercopy.  I don't think
> > > anyone will notice the extra mov, for the cases where it would be
> > > propagated as an immediate.  And the argument *is* an unsigned long
> > > after all.
> > > 
> > > Stephen, can you confirm this fixes it?  
> > 
> > Still traveling, I didn't see an update on this.  Any objections to the
> > below?  I assume it fixes Stephen's build issue.
> 
> Yes, it does fix my x86_64 allnoconfig build.

Stephen, thanks!

Al, do you want to fold that change in?  Or shall I post another
version?

-- 
Josh

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

[Stephen Rothwell]

Hi Josh,

On Tue, 6 Oct 2020 09:30:12 -0500 Josh Poimboeuf  wrote:
>
> On Mon, Sep 28, 2020 at 11:10:56PM -0500, Josh Poimboeuf wrote:
> > > Josh, any ideas?  We could, of course, make it "r"(size), but that would
> > > be unpleasant in all existing callers...  
> > 
> > Sorry, I've been traveling.  I'd just vote for making it "r".
> > 
> > array_index_nospec() is always called after a usercopy.  I don't think
> > anyone will notice the extra mov, for the cases where it would be
> > propagated as an immediate.  And the argument *is* an unsigned long
> > after all.
> > 
> > Stephen, can you confirm this fixes it?  
> 
> Still traveling, I didn't see an update on this.  Any objections to the
> below?  I assume it fixes Stephen's build issue.

Yes, it does fix my x86_64 allnoconfig build.

-- 
Cheers,
Stephen Rothwell


pgpWJSjxfb9J9.pgp
Description: OpenPGP digital signature

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

[Josh Poimboeuf]

On Mon, Sep 28, 2020 at 11:10:56PM -0500, Josh Poimboeuf wrote:
> > Josh, any ideas?  We could, of course, make it "r"(size), but that would
> > be unpleasant in all existing callers...
> 
> Sorry, I've been traveling.  I'd just vote for making it "r".
> 
> array_index_nospec() is always called after a usercopy.  I don't think
> anyone will notice the extra mov, for the cases where it would be
> propagated as an immediate.  And the argument *is* an unsigned long
> after all.
> 
> Stephen, can you confirm this fixes it?

Still traveling, I didn't see an update on this.  Any objections to the
below?  I assume it fixes Stephen's build issue.

> 
> diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
> index d158ea1fa250..69045ac62f58 100644
> --- a/arch/x86/include/asm/barrier.h
> +++ b/arch/x86/include/asm/barrier.h
> @@ -40,7 +40,7 @@ static inline unsigned long 
> array_index_mask_nospec(unsigned long index,
>  
>   asm volatile ("cmp %1,%2; sbb %0,%0;"
>   :"=r" (mask)
> - :"g"(size),"r" (index)
> + :"r"(size), "r"(index)
>   :"cc");
>   return mask;
>  }
> 

-- 
Josh

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

[Josh Poimboeuf]

On Fri, Sep 25, 2020 at 02:38:20PM +0100, Al Viro wrote:
> On Fri, Sep 25, 2020 at 10:01:28PM +1000, Stephen Rothwell wrote:
> > $ x86_64-linux-gnu-gcc --version
> > x86_64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0
> > $ x86_64-linux-gnu-ld --version
> > GNU ld (GNU Binutils for Debian) 2.35
> > 
> > and the gcc plugins don't get built for the allnoconfig builds.
> 
> > I reverted my Revert commit after I finished linux-next today and built
> > the x86_64 allnoconfig verion of lib/iov_iter.s:
> > 
> > $ grep -A 1 '41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h"' 
> > lib/iov_iter.s
> > # 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
> > cmp $140737488351232,%rdx; sbb %rcx,%rcx;   #, uaddr, mask
> 
> Wait a sec...
> static inline unsigned long array_index_mask_nospec(unsigned long index,
> unsigned long size)
> {
> unsigned long mask;
> 
> asm volatile ("cmp %1,%2; sbb %0,%0;"
> :"=r" (mask)
> :"g"(size),"r" (index)
> :"cc");
> return mask;
> }  
> 
> used with large constant size will blow up - "g" is wrong, since cmp allows
> 64bit arguments to be register or memory ones; immediates can't go past
> 32bit.
> 
> Looks like on the configs where it builds we end up with not seeing it's
> a constant...
> 
> Josh, any ideas?  We could, of course, make it "r"(size), but that would
> be unpleasant in all existing callers...

Sorry, I've been traveling.  I'd just vote for making it "r".

array_index_nospec() is always called after a usercopy.  I don't think
anyone will notice the extra mov, for the cases where it would be
propagated as an immediate.  And the argument *is* an unsigned long
after all.

Stephen, can you confirm this fixes it?

diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index d158ea1fa250..69045ac62f58 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -40,7 +40,7 @@ static inline unsigned long array_index_mask_nospec(unsigned 
long index,
 
asm volatile ("cmp %1,%2; sbb %0,%0;"
:"=r" (mask)
-   :"g"(size),"r" (index)
+   :"r"(size), "r"(index)
:"cc");
return mask;
 }

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

[Christoph Hellwig]

That is the crude fix, and it should work.  I'd much rather make
compat_iovec always available, though.  Let me give that a spin.

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi all,

After merging the vfs tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from arch/arm/include/asm/atomic.h:11,
 from include/linux/atomic.h:7,
 from include/linux/crypto.h:15,
 from include/crypto/hash.h:11,
 from lib/iov_iter.c:2:
lib/iov_iter.c: In function 'copy_compat_iovec_from_user':
lib/iov_iter.c:1665:29: error: invalid use of undefined type 'struct 
compat_iovec'
 1665 |   unsafe_get_user(len, [i].iov_len, uaccess_end);
  | ^
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
   78 | # define unlikely(x) __builtin_expect(!!(x), 0)
  |  ^
include/linux/uaccess.h:370:32: note: in expansion of macro 'unsafe_op_wrap'
  370 | #define unsafe_get_user(x,p,e) unsafe_op_wrap(__get_user(x,p),e)
  |^~
arch/arm/include/asm/uaccess.h:238:3: note: in expansion of macro 
'__get_user_check'
  238 |   __get_user_check(x, p); \
  |   ^~~~
arch/arm/include/asm/uaccess.h:296:28: note: in expansion of macro 'get_user'
  296 | #define __get_user(x, ptr) get_user(x, ptr)
  |^~~~
include/linux/uaccess.h:370:47: note: in expansion of macro '__get_user'
  370 | #define unsafe_get_user(x,p,e) unsafe_op_wrap(__get_user(x,p),e)
  |   ^~
lib/iov_iter.c:1665:3: note: in expansion of macro 'unsafe_get_user'
 1665 |   unsafe_get_user(len, [i].iov_len, uaccess_end);
  |   ^~~
lib/iov_iter.c:1665:32: error: invalid use of undefined type 'const struct 
compat_iovec'
 1665 |   unsafe_get_user(len, [i].iov_len, uaccess_end);
  |^
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
   78 | # define unlikely(x) __builtin_expect(!!(x), 0)
  |  ^
include/linux/uaccess.h:370:32: note: in expansion of macro 'unsafe_op_wrap'
  370 | #define unsafe_get_user(x,p,e) unsafe_op_wrap(__get_user(x,p),e)
  |^~
arch/arm/include/asm/uaccess.h:238:3: note: in expansion of macro 
'__get_user_check'
  238 |   __get_user_check(x, p); \
  |   ^~~~
arch/arm/include/asm/uaccess.h:296:28: note: in expansion of macro 'get_user'
  296 | #define __get_user(x, ptr) get_user(x, ptr)
  |^~~~
include/linux/uaccess.h:370:47: note: in expansion of macro '__get_user'
  370 | #define unsafe_get_user(x,p,e) unsafe_op_wrap(__get_user(x,p),e)
  |   ^~
lib/iov_iter.c:1665:3: note: in expansion of macro 'unsafe_get_user'
 1665 |   unsafe_get_user(len, [i].iov_len, uaccess_end);
  |   ^~~
lib/iov_iter.c:1665:29: error: invalid use of undefined type 'struct 
compat_iovec'
 1665 |   unsafe_get_user(len, [i].iov_len, uaccess_end);
  | ^
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
   78 | # define unlikely(x) __builtin_expect(!!(x), 0)
  |  ^
include/linux/uaccess.h:370:32: note: in expansion of macro 'unsafe_op_wrap'
  370 | #define unsafe_get_user(x,p,e) unsafe_op_wrap(__get_user(x,p),e)
  |^~
arch/arm/include/asm/uaccess.h:238:3: note: in expansion of macro 
'__get_user_check'
  238 |   __get_user_check(x, p); \
  |   ^~~~
arch/arm/include/asm/uaccess.h:296:28: note: in expansion of macro 'get_user'
  296 | #define __get_user(x, ptr) get_user(x, ptr)
  |^~~~
include/linux/uaccess.h:370:47: note: in expansion of macro '__get_user'
  370 | #define unsafe_get_user(x,p,e) unsafe_op_wrap(__get_user(x,p),e)
  |   ^~
lib/iov_iter.c:1665:3: note: in expansion of macro 'unsafe_get_user'
 1665 |   unsafe_get_user(len, [i].iov_len, uaccess_end);
  |   ^~~
lib/iov_iter.c:1665:32: error: invalid use of undefined type 'const struct 
compat_iovec'
 1665 |   unsafe_get_user(len, [i].iov_len, uaccess_end);
  |^
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
   78 | # define unlikely(x) __builtin_expect(!!(x), 0)
  |  ^
include/linux/uaccess.h:370:32: note: in expansion of macro 'unsafe_op_wrap'
  370 | #define unsafe_get_user(x,p,e) unsafe_op_wrap(__get_user(x,p),e)
  |^~
arch/arm/include/asm/uaccess.h:238:3: note: in expansion of macro 
'__get_user_check'
  238 |   __get_user_check(x, p); \
  |   ^~~~
arch/arm/include/asm/uaccess.h:296:28: note: in expansion of macro 'get_user'
  296 | #define 

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

[Al Viro]

On Fri, Sep 25, 2020 at 10:01:28PM +1000, Stephen Rothwell wrote:
> $ x86_64-linux-gnu-gcc --version
> x86_64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0
> $ x86_64-linux-gnu-ld --version
> GNU ld (GNU Binutils for Debian) 2.35
> 
> and the gcc plugins don't get built for the allnoconfig builds.

> I reverted my Revert commit after I finished linux-next today and built
> the x86_64 allnoconfig verion of lib/iov_iter.s:
> 
> $ grep -A 1 '41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h"' 
> lib/iov_iter.s
> # 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
>   cmp $140737488351232,%rdx; sbb %rcx,%rcx;   #, uaddr, mask

Wait a sec...
static inline unsigned long array_index_mask_nospec(unsigned long index,
unsigned long size)
{
unsigned long mask;

asm volatile ("cmp %1,%2; sbb %0,%0;"
:"=r" (mask)
:"g"(size),"r" (index)
:"cc");
return mask;
}  

used with large constant size will blow up - "g" is wrong, since cmp allows
64bit arguments to be register or memory ones; immediates can't go past
32bit.

Looks like on the configs where it builds we end up with not seeing it's
a constant...

Josh, any ideas?  We could, of course, make it "r"(size), but that would
be unpleasant in all existing callers...

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

[Stephen Rothwell]

Hi Al,

On Thu, 24 Sep 2020 21:08:07 +0100 Al Viro  wrote:
>
> On Thu, Sep 24, 2020 at 06:30:38PM +1000, Stephen Rothwell wrote:
> > 
> > After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> > failed like this:
> > 
> > arch/x86/include/asm/barrier.h: Assembler messages:
> > arch/x86/include/asm/barrier.h:41: Error: operand type mismatch for `cmp'
> > arch/x86/include/asm/barrier.h:41: Error: operand type mismatch for `cmp'
> > 
> > and many more ...
> > 
> > Caused by commit
> > 
> >   e33ea6e5ba6a ("x86/uaccess: Use pointer masking to limit uaccess 
> > speculation")
> > 
> > I am not exactly sure why (but reverting it fixes the build).
> > 
> > I have reverted that commit for today.  
> 
> Can't reproduce here...  This on top of today's -next seems to build with
> allnoconfig here:

I don't know what to tell you ... it still fails for me today.

$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0
$ x86_64-linux-gnu-ld --version
GNU ld (GNU Binutils for Debian) 2.35

and the gcc plugins don't get built for the allnoconfig builds.

> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 35293ad83297..aca828b9b831 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -647,7 +647,7 @@ static int copyout_mc(void __user *to, const void *from, 
> size_t n)
>  {
>   if (access_ok(to, n)) {
>   instrument_copy_to_user(to, from, n);
> - n = copy_mc_to_user((__force void *) to, from, n);
> + n = copy_mc_to_user((__force void *)force_user_ptr(to), from, 
> n);

BTW, You can't do that because force_user_ptr is only defined for x86 ...

I reverted my Revert commit after I finished linux-next today and built
the x86_64 allnoconfig verion of lib/iov_iter.s:

$ grep -A 1 '41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h"' 
lib/iov_iter.s
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdx; sbb %rcx,%rcx;   #, uaddr, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%r8; sbb %rdx,%rdx;#, end, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdx; sbb %rcx,%rcx;   #, uaddr, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdi; sbb %rdx,%rdx;   #, end, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdi; sbb %rax,%rax;   #, to.29_334, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdi; sbb %rax,%rax;   #, to.29_367, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax;   #, from.37_239, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax;   #, from.37_272, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax;   #, _i, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax;   #, _i, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax;   #, _i, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax;   #, _i, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdi; sbb %rax,%rax;   #, to.29_96, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdi; sbb %rax,%rax;   #, to.29_244, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax;   #, from.37_68, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax;   #, from.37_221, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %r10,%r10;   #, from.37_281, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax;   #, from.37_314, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %r10,%r10;   #, from.37_177, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax;   #, from.37_210, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%r10; sbb %rsi,%rsi;   #, _i, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax;   #, _i, mask

I don't know if that helps.
-- 
Cheers,
Stephen Rothwell


pgpOQn7xVDEPt.pgp
Description: OpenPGP digital signature

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

[Al Viro]

On Thu, Sep 24, 2020 at 06:30:38PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> arch/x86/include/asm/barrier.h: Assembler messages:
> arch/x86/include/asm/barrier.h:41: Error: operand type mismatch for `cmp'
> arch/x86/include/asm/barrier.h:41: Error: operand type mismatch for `cmp'
> 
> and many more ...
> 
> Caused by commit
> 
>   e33ea6e5ba6a ("x86/uaccess: Use pointer masking to limit uaccess 
> speculation")
> 
> I am not exactly sure why (but reverting it fixes the build).
> 
> I have reverted that commit for today.

Can't reproduce here...  This on top of today's -next seems to build with
allnoconfig here:

diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst 
b/Documentation/admin-guide/hw-vuln/spectre.rst
index e05e581af5cf..27a8adedd2b8 100644
--- a/Documentation/admin-guide/hw-vuln/spectre.rst
+++ b/Documentation/admin-guide/hw-vuln/spectre.rst
@@ -426,9 +426,9 @@ Spectre variant 1
` to avoid any usable disclosure gadgets. However, it may
not cover all attack vectors for Spectre variant 1.
 
-   Copy-from-user code has an LFENCE barrier to prevent the access_ok()
-   check from being mis-speculated.  The barrier is done by the
-   barrier_nospec() macro.
+   Usercopy code uses user pointer masking to prevent the access_ok()
+   check from being mis-speculated in the success path with a kernel
+   address.  The masking is done by the force_user_ptr() macro.
 
For the swapgs variant of Spectre variant 1, LFENCE barriers are
added to interrupt, exception and NMI entry where needed.  These
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index 7f828fe49797..d158ea1fa250 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -48,9 +48,6 @@ static inline unsigned long array_index_mask_nospec(unsigned 
long index,
 /* Override the default implementation from linux/nospec.h. */
 #define array_index_mask_nospec array_index_mask_nospec
 
-/* Prevent speculative execution past this barrier. */
-#define barrier_nospec() alternative("", "lfence", X86_FEATURE_LFENCE_RDTSC)
-
 #define dma_rmb()  barrier()
 #define dma_wmb()  barrier()
 
diff --git a/arch/x86/include/asm/checksum_32.h 
b/arch/x86/include/asm/checksum_32.h
index 17da95387997..c7ebc40c6fb9 100644
--- a/arch/x86/include/asm/checksum_32.h
+++ b/arch/x86/include/asm/checksum_32.h
@@ -49,7 +49,8 @@ static inline __wsum csum_and_copy_from_user(const void 
__user *src,
might_sleep();
if (!user_access_begin(src, len))
return 0;
-   ret = csum_partial_copy_generic((__force void *)src, dst, len);
+   ret = csum_partial_copy_generic((__force void *)force_user_ptr(src),
+   dst, len);
user_access_end();
 
return ret;
@@ -177,8 +178,7 @@ static inline __wsum csum_and_copy_to_user(const void *src,
might_sleep();
if (!user_access_begin(dst, len))
return 0;
-
-   ret = csum_partial_copy_generic(src, (__force void *)dst, len);
+   ret = csum_partial_copy_generic(src, (__force void 
*)force_user_ptr(dst), len);
user_access_end();
return ret;
 }
diff --git a/arch/x86/include/asm/futex.h b/arch/x86/include/asm/futex.h
index f9c00110a69a..0cecdaa362b1 100644
--- a/arch/x86/include/asm/futex.h
+++ b/arch/x86/include/asm/futex.h
@@ -59,6 +59,8 @@ static __always_inline int arch_futex_atomic_op_inuser(int 
op, int oparg, int *o
if (!user_access_begin(uaddr, sizeof(u32)))
return -EFAULT;
 
+   uaddr = force_user_ptr(uaddr);
+
switch (op) {
case FUTEX_OP_SET:
unsafe_atomic_op1("xchgl %0, %2", oval, uaddr, oparg, Efault);
@@ -94,6 +96,9 @@ static inline int futex_atomic_cmpxchg_inatomic(u32 *uval, 
u32 __user *uaddr,
 
if (!user_access_begin(uaddr, sizeof(u32)))
return -EFAULT;
+
+   uaddr = force_user_ptr(uaddr);
+
asm volatile("\n"
"1:\t" LOCK_PREFIX "cmpxchgl %4, %2\n"
"2:\n"
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index b24f8623bcda..cad8d0b1dbbb 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -67,13 +68,24 @@ static inline bool pagefault_disabled(void);
  * Return: true (nonzero) if the memory block may be valid, false (zero)
  * if it is definitely invalid.
  */
-#define access_ok(addr, size)  \
+#define access_ok(addr, size)  \
 ({ \
WARN_ON_IN_IRQ();   \
likely(!__range_not_ok(addr, size, TASK_SIZE_MAX)); \
 })
 
 /*
+ * Sanitize a user 

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi all,

After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
failed like this:

arch/x86/include/asm/barrier.h: Assembler messages:
arch/x86/include/asm/barrier.h:41: Error: operand type mismatch for `cmp'
arch/x86/include/asm/barrier.h:41: Error: operand type mismatch for `cmp'

and many more ...

Caused by commit

  e33ea6e5ba6a ("x86/uaccess: Use pointer masking to limit uaccess speculation")

I am not exactly sure why (but reverting it fixes the build).

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell


pgpvGB19FlRhY.pgp
Description: OpenPGP digital signature

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

[Al Viro]

On Wed, Jul 29, 2020 at 08:33:05AM +0200, Christoph Hellwig wrote:
> Thanks,
> 
> I've sent out a fixed version.

#work.quota-compat and #for-next rebuilt (and pushed) with it...

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

[Christoph Hellwig]

Thanks,

I've sent out a fixed version.

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi all,

After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

In file included from :
In function 'signal_compat_build_tests',
inlined from 'sigaction_compat_abi' at 
arch/x86/kernel/signal_compat.c:166:2:
include/linux/compiler_types.h:313:38: error: call to 
'__compiletime_assert_980' declared with attribute error: BUILD_BUG_ON failed: 
sizeof(compat_siginfo_t) != 128
  313 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  |  ^
include/linux/compiler_types.h:294:4: note: in definition of macro 
'__compiletime_assert'
  294 |prefix ## suffix();\
  |^~
include/linux/compiler_types.h:313:2: note: in expansion of macro 
'_compiletime_assert'
  313 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  |  ^~~
include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
   39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
  | ^~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
   50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
  |  ^~~~
arch/x86/kernel/signal_compat.c:37:2: note: in expansion of macro 'BUILD_BUG_ON'
   37 |  BUILD_BUG_ON(sizeof(compat_siginfo_t) != 128);
  |  ^~~~
include/linux/compiler_types.h:313:38: error: call to 
'__compiletime_assert_981' declared with attribute error: BUILD_BUG_ON failed: 
offsetof(compat_siginfo_t, _sifields) != 3 * sizeof(int)
  313 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  |  ^
include/linux/compiler_types.h:294:4: note: in definition of macro 
'__compiletime_assert'
  294 |prefix ## suffix();\
  |^~
include/linux/compiler_types.h:313:2: note: in expansion of macro 
'_compiletime_assert'
  313 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  |  ^~~
include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
   39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
  | ^~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
   50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
  |  ^~~~
arch/x86/kernel/signal_compat.c:43:2: note: in expansion of macro 'BUILD_BUG_ON'
   43 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, _sifields) != 3 * sizeof(int));
  |  ^~~~
include/linux/compiler_types.h:313:38: error: call to 
'__compiletime_assert_993' declared with attribute error: BUILD_BUG_ON failed: 
offsetof(compat_siginfo_t, si_pid) != 0xC
  313 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  |  ^
include/linux/compiler_types.h:294:4: note: in definition of macro 
'__compiletime_assert'
  294 |prefix ## suffix();\
  |^~
include/linux/compiler_types.h:313:2: note: in expansion of macro 
'_compiletime_assert'
  313 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  |  ^~~
include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
   39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
  | ^~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
   50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
  |  ^~~~
arch/x86/kernel/signal_compat.c:75:2: note: in expansion of macro 'BUILD_BUG_ON'
   75 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_pid) != 0xC);
  |  ^~~~
include/linux/compiler_types.h:313:38: error: call to 
'__compiletime_assert_994' declared with attribute error: BUILD_BUG_ON failed: 
offsetof(compat_siginfo_t, si_uid) != 0x10
  313 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  |  ^
include/linux/compiler_types.h:294:4: note: in definition of macro 
'__compiletime_assert'
  294 |prefix ## suffix();\
  |^~
include/linux/compiler_types.h:313:2: note: in expansion of macro 
'_compiletime_assert'
  313 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  |  ^~~
include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
   39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
  | ^~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
   50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
  |  ^~~~

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi all,

After merging the vfs tree, today's linux-next build (sparc defconfig)
failed like this:

arch/sparc/kernel/ptrace_32.c: In function 'setregs_set':
arch/sparc/kernel/ptrace_32.c:271:2: error: 'ret' undeclared (first use in this 
function); did you mean 'net'?
  ret = user_regset_copyin(, , , ,
  ^~~
  net


Caused by commit

  cf921bf15c62 ("sparc32: get rid of odd callers of copy_regset_from_user()")

I added this patch for today.

From: Stephen Rothwell 
Date: Mon, 27 Jul 2020 21:59:23 +1000
Subject: [PATCH] sparc32: declare ret

Signed-off-by: Stephen Rothwell 
---
 arch/sparc/kernel/ptrace_32.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/sparc/kernel/ptrace_32.c b/arch/sparc/kernel/ptrace_32.c
index caeb99cbc1fa..f2c581d36d6c 100644
--- a/arch/sparc/kernel/ptrace_32.c
+++ b/arch/sparc/kernel/ptrace_32.c
@@ -264,6 +264,7 @@ static int setregs_set(struct task_struct *target,
 {
struct pt_regs *regs = target->thread.kregs;
u32 v[4];
+   int ret;
 
if (target == current)
flush_user_windows();
-- 
2.27.0

-- 
Cheers,
Stephen Rothwell


pgp8eKDiaOy9j.pgp
Description: OpenPGP digital signature

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

[Jens Axboe]

On 5/6/20 8:35 PM, Al Viro wrote:
> On Thu, May 07, 2020 at 10:39:21AM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the vfs tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>> fs/eventfd.c: In function 'eventfd_read':
>> fs/eventfd.c:226:6: error: implicit declaration of function 'iov_iter_count' 
>> [-Werror=implicit-function-declaration]
>>   226 |  if (iov_iter_count(to) < sizeof(ucnt))
>>   |  ^~
>> In file included from include/linux/file.h:9,
>>  from fs/eventfd.c:9:
>> fs/eventfd.c:257:15: error: implicit declaration of function 'copy_to_iter'; 
>> did you mean 'copy_to_user'? [-Werror=implicit-function-declaration]
>>   257 |  if (unlikely(copy_to_iter(, sizeof(ucnt), to) != sizeof(ucnt)))
>>   |   ^~~~
>>
>> Caused by commit
>>
>>   a6515b3a7410 ("eventfd: convert to f_op->read_iter()")
>>
>> I have applied the following patch for today:
> 
> [snip]
> 
> folded and pushed out

Thanks Al.

-- 
Jens Axboe

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

[Al Viro]

On Thu, May 07, 2020 at 10:39:21AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> fs/eventfd.c: In function 'eventfd_read':
> fs/eventfd.c:226:6: error: implicit declaration of function 'iov_iter_count' 
> [-Werror=implicit-function-declaration]
>   226 |  if (iov_iter_count(to) < sizeof(ucnt))
>   |  ^~
> In file included from include/linux/file.h:9,
>  from fs/eventfd.c:9:
> fs/eventfd.c:257:15: error: implicit declaration of function 'copy_to_iter'; 
> did you mean 'copy_to_user'? [-Werror=implicit-function-declaration]
>   257 |  if (unlikely(copy_to_iter(, sizeof(ucnt), to) != sizeof(ucnt)))
>   |   ^~~~
> 
> Caused by commit
> 
>   a6515b3a7410 ("eventfd: convert to f_op->read_iter()")
> 
> I have applied the following patch for today:

[snip]

folded and pushed out

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi all,

After merging the vfs tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

fs/eventfd.c: In function 'eventfd_read':
fs/eventfd.c:226:6: error: implicit declaration of function 'iov_iter_count' 
[-Werror=implicit-function-declaration]
  226 |  if (iov_iter_count(to) < sizeof(ucnt))
  |  ^~
In file included from include/linux/file.h:9,
 from fs/eventfd.c:9:
fs/eventfd.c:257:15: error: implicit declaration of function 'copy_to_iter'; 
did you mean 'copy_to_user'? [-Werror=implicit-function-declaration]
  257 |  if (unlikely(copy_to_iter(, sizeof(ucnt), to) != sizeof(ucnt)))
  |   ^~~~

Caused by commit

  a6515b3a7410 ("eventfd: convert to f_op->read_iter()")

I have applied the following patch for today:

From: Stephen Rothwell 
Date: Thu, 7 May 2020 10:35:52 +1000
Subject: [PATCH] eventfd: include uio.h

Fixes: a6515b3a7410 ("eventfd: convert to f_op->read_iter()")
Signed-off-by: Stephen Rothwell 
---
 fs/eventfd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/eventfd.c b/fs/eventfd.c
index 20f0fd4d56e1..df466ef81ddd 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DEFINE_PER_CPU(int, eventfd_wake_count);
 
-- 
2.26.2

-- 
Cheers,
Stephen Rothwell


pgpSPNYsXkzbh.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

On Wed, 2 Jan 2019 15:01:40 +1100 Stephen Rothwell  
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> fs/fs_context.c: In function 'logfc':
> fs/fs_context.c:400:3: error: implicit declaration of function 
> 'vprintk_emit'; did you mean 'dev_printk_emit'? 
> [-Werror=implicit-function-declaration]
>vprintk_emit(0, LOGLEVEL_WARNING, NULL, 0, fmt, va);
>^~~~
>dev_printk_emit
> 
> Caused by commit
> 
>   e6d72ffc503f ("vfs: Implement logging through fs_context")
> 
> # CONFIG_PRINTK is not set
> 
> I added the following hack for today:
> 
> From: Stephen Rothwell 
> Date: Wed, 2 Jan 2019 14:57:36 +1100
> Subject: [PATCH] vfs: work around CONFIG_PRINTK=n in fs_context logging code
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  fs/fs_context.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/fs_context.c b/fs/fs_context.c
> index 8728d49c7871..b0324598f573 100644
> --- a/fs/fs_context.c
> +++ b/fs/fs_context.c
> @@ -391,6 +391,7 @@ EXPORT_SYMBOL(vfs_dup_fs_context);
>   */
>  void logfc(struct fs_context *fc, const char *fmt, ...)
>  {
> +#ifdef CONFIG_PRINTK
>   va_list va;
>  
>   va_start(va, fmt);
> @@ -409,6 +410,7 @@ void logfc(struct fs_context *fc, const char *fmt, ...)
>  
>   pr_cont("\n");
>   va_end(va);
> +#endif
>  }
>  EXPORT_SYMBOL(logfc);
>  

Ping?
-- 
Cheers,
Stephen Rothwell


pgp966dJkI160.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
failed like this:

fs/fs_context.c: In function 'logfc':
fs/fs_context.c:400:3: error: implicit declaration of function 'vprintk_emit'; 
did you mean 'dev_printk_emit'? [-Werror=implicit-function-declaration]
   vprintk_emit(0, LOGLEVEL_WARNING, NULL, 0, fmt, va);
   ^~~~
   dev_printk_emit

Caused by commit

  e6d72ffc503f ("vfs: Implement logging through fs_context")

# CONFIG_PRINTK is not set

I added the following hack for today:

From: Stephen Rothwell 
Date: Wed, 2 Jan 2019 14:57:36 +1100
Subject: [PATCH] vfs: work around CONFIG_PRINTK=n in fs_context logging code

Signed-off-by: Stephen Rothwell 
---
 fs/fs_context.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/fs_context.c b/fs/fs_context.c
index 8728d49c7871..b0324598f573 100644
--- a/fs/fs_context.c
+++ b/fs/fs_context.c
@@ -391,6 +391,7 @@ EXPORT_SYMBOL(vfs_dup_fs_context);
  */
 void logfc(struct fs_context *fc, const char *fmt, ...)
 {
+#ifdef CONFIG_PRINTK
va_list va;
 
va_start(va, fmt);
@@ -409,6 +410,7 @@ void logfc(struct fs_context *fc, const char *fmt, ...)
 
pr_cont("\n");
va_end(va);
+#endif
 }
 EXPORT_SYMBOL(logfc);
 
-- 
2.19.1

-- 
Cheers,
Stephen Rothwell


pgpYqcfq2D0qI.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi David,

On Mon, 29 Oct 2018 09:21:20 + David Howells  wrote:
>
> I think these changes should cover them all.

Yep, that fixes the build for me, thanks.

Tested-by: Stephen Rothwell 
-- 
Cheers,
Stephen Rothwell


pgpUP0DRJWa3r.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi David,

On Mon, 29 Oct 2018 09:21:20 + David Howells  wrote:
>
> I think these changes should cover them all.

Yep, that fixes the build for me, thanks.

Tested-by: Stephen Rothwell 
-- 
Cheers,
Stephen Rothwell


pgpUP0DRJWa3r.pgp
Description: OpenPGP digital signature

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

[David Howells]

I think these changes should cover them all.

David
---
diff --git a/samples/vfs/test-fs-query.c b/samples/vfs/test-fs-query.c
index 511541d12b9e..4635bf1eb3d4 100644
--- a/samples/vfs/test-fs-query.c
+++ b/samples/vfs/test-fs-query.c
@@ -27,6 +27,13 @@
 #include 
 #include 
 
+#ifndef __NR_fsopen
+#define __NR_fsopen -1
+#endif
+#ifndef __NR_fsinfo
+#define __NR_fsinfo -1
+#endif
+
 static int fsopen(const char *fs_name, unsigned int flags)
 {
return syscall(__NR_fsopen, fs_name, flags);
diff --git a/samples/vfs/test-fsinfo.c b/samples/vfs/test-fsinfo.c
index 75f5c2a61445..125010212eee 100644
--- a/samples/vfs/test-fsinfo.c
+++ b/samples/vfs/test-fsinfo.c
@@ -28,6 +28,10 @@
 #include 
 #include 
 
+#ifndef __NR_fsinfo
+#define __NR_fsinfo -1
+#endif
+
 static bool debug = 0;
 
 static __attribute__((unused))
diff --git a/samples/vfs/test-statx.c b/samples/vfs/test-statx.c
index 9ac4b7707aba..4ef0c914a62a 100644
--- a/samples/vfs/test-statx.c
+++ b/samples/vfs/test-statx.c
@@ -161,7 +161,8 @@ static void dump_statx(struct statx *stx)
"?dai?c??"  /*  7- 00x-00ff */
;
 
-   printf("Attributes: %016llx (", stx->stx_attributes);
+   printf("Attributes: %016llx (",
+  (unsigned long long)stx->stx_attributes);
for (byte = 64 - 8; byte >= 0; byte -= 8) {
bits = stx->stx_attributes >> byte;
mbits = stx->stx_attributes_mask >> byte;

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

[David Howells]

I think these changes should cover them all.

David
---
diff --git a/samples/vfs/test-fs-query.c b/samples/vfs/test-fs-query.c
index 511541d12b9e..4635bf1eb3d4 100644
--- a/samples/vfs/test-fs-query.c
+++ b/samples/vfs/test-fs-query.c
@@ -27,6 +27,13 @@
 #include 
 #include 
 
+#ifndef __NR_fsopen
+#define __NR_fsopen -1
+#endif
+#ifndef __NR_fsinfo
+#define __NR_fsinfo -1
+#endif
+
 static int fsopen(const char *fs_name, unsigned int flags)
 {
return syscall(__NR_fsopen, fs_name, flags);
diff --git a/samples/vfs/test-fsinfo.c b/samples/vfs/test-fsinfo.c
index 75f5c2a61445..125010212eee 100644
--- a/samples/vfs/test-fsinfo.c
+++ b/samples/vfs/test-fsinfo.c
@@ -28,6 +28,10 @@
 #include 
 #include 
 
+#ifndef __NR_fsinfo
+#define __NR_fsinfo -1
+#endif
+
 static bool debug = 0;
 
 static __attribute__((unused))
diff --git a/samples/vfs/test-statx.c b/samples/vfs/test-statx.c
index 9ac4b7707aba..4ef0c914a62a 100644
--- a/samples/vfs/test-statx.c
+++ b/samples/vfs/test-statx.c
@@ -161,7 +161,8 @@ static void dump_statx(struct statx *stx)
"?dai?c??"  /*  7- 00x-00ff */
;
 
-   printf("Attributes: %016llx (", stx->stx_attributes);
+   printf("Attributes: %016llx (",
+  (unsigned long long)stx->stx_attributes);
for (byte = 64 - 8; byte >= 0; byte -= 8) {
bits = stx->stx_attributes >> byte;
mbits = stx->stx_attributes_mask >> byte;

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

[Stephen Rothwell]

Hi David,

On Mon, 29 Oct 2018 15:33:34 +1100 Stephen Rothwell  
wrote:
>
> Hi Al, David,
> 
> These have returned, so I have disabled CONFIG_SAMPLE_VFS again.

Here is the current set of errors I git today (this is from a PowerPC
allyesconfig build native compiler on a PowerPC64 LE machine):

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'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 fsinfo
samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/vfs/test-fsinfo.c:38:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^
samples/vfs/test-fs-query.c: In function 'fsopen':
samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use 
in this function); did you mean 'fsopen'?
  return syscall(__NR_fsopen, fs_name, flags);
 ^~~
 fsopen
samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/vfs/test-fs-query.c: In function 'fsinfo':
samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use 
in this function); did you mean 'fsinfo'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 fsinfo
samples/vfs/test-fs-query.c: In function 'fsopen':
samples/vfs/test-fs-query.c:33:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^
samples/vfs/test-fs-query.c: In function 'fsinfo':
samples/vfs/test-fs-query.c:39:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^
samples/vfs/test-statx.c: In function 'dump_statx':
samples/vfs/test-statx.c:164:29: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
   printf("Attributes: %016llx (", stx->stx_attributes);
   ~~^ ~~~
   %016lx

-- 
Cheers,
Stephen Rothwell


pgp35wEErfoA1.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi David,

On Mon, 29 Oct 2018 15:33:34 +1100 Stephen Rothwell  
wrote:
>
> Hi Al, David,
> 
> These have returned, so I have disabled CONFIG_SAMPLE_VFS again.

Here is the current set of errors I git today (this is from a PowerPC
allyesconfig build native compiler on a PowerPC64 LE machine):

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'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 fsinfo
samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/vfs/test-fsinfo.c:38:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^
samples/vfs/test-fs-query.c: In function 'fsopen':
samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use 
in this function); did you mean 'fsopen'?
  return syscall(__NR_fsopen, fs_name, flags);
 ^~~
 fsopen
samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/vfs/test-fs-query.c: In function 'fsinfo':
samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use 
in this function); did you mean 'fsinfo'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 fsinfo
samples/vfs/test-fs-query.c: In function 'fsopen':
samples/vfs/test-fs-query.c:33:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^
samples/vfs/test-fs-query.c: In function 'fsinfo':
samples/vfs/test-fs-query.c:39:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^
samples/vfs/test-statx.c: In function 'dump_statx':
samples/vfs/test-statx.c:164:29: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
   printf("Attributes: %016llx (", stx->stx_attributes);
   ~~^ ~~~
   %016lx

-- 
Cheers,
Stephen Rothwell


pgp35wEErfoA1.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Al, David,

These have returned, so I have disabled CONFIG_SAMPLE_VFS again.

On Mon, 10 Sep 2018 13:35:25 +1000 Stephen Rothwell  
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'?
>   return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
>  ^~~
>  fsinfo
> samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported 
> only once for each function it appears in
> samples/vfs/test-fsinfo.c: In function 'dump_attr_LIMITS':
> 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);
>~~~^ 
>%lx
> samples/vfs/test-fsinfo.c:181:32: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
>  ~~~^
>  %lx
>  f->max_uid, f->max_gid, f->max_projid);
>  ~~
> samples/vfs/test-fsinfo.c:181:39: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
> ~~~^
> %lx
>  f->max_uid, f->max_gid, f->max_projid);
>  ~~
> samples/vfs/test-fsinfo.c:181:46: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
>~~~^
>%lx
>  f->max_uid, f->max_gid, f->max_projid);
>  ~
> samples/vfs/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
> samples/vfs/test-fsinfo.c:197:24: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tstx_attr=%llx\n", f->stx_attributes);
>  ~~~^ ~
>  %lx
> samples/vfs/test-fsmount.c: In function 'fsopen':
> samples/vfs/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first use 
> in this function); did you mean 'fsopen'?
>   return syscall(__NR_fsopen, fs_name, flags);
>  ^~~
>  fsopen
> samples/vfs/test-fsmount.c:63:17: note: each undeclared identifier is 
> reported only once for each function it appears in
> samples/vfs/test-fsmount.c: In function 'fsmount':
> samples/vfs/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first use 
> in this function); did you mean 'fsmount'?
>   return syscall(__NR_fsmount, fsfd, flags, ms_flags);
>  ^~~~
>  fsmount
> samples/vfs/test-fsmount.c: In function 'fsconfig':
> samples/vfs/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared (first 
> use in this function); did you mean 'fsconfig'?
>   return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
>  ^
>  fsconfig
> samples/vfs/test-fsmount.c: In function 'move_mount':
> samples/vfs/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared (first 
> use in this function); did you mean 'move_mount'?
>   return syscall(__NR_move_mount,
>  ^~~
>  move_mount
> samples/vfs/test-fs-query.c: In function 'fsopen':
> samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use 
> in this function); did you mean 'fsopen'?
>   return syscall(__NR_fsopen, fs_name, flags);
>  ^~~
>  fsopen
> samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is 
> reported only once for each function it appears in
> samples/vfs/test-fs-query.c: In function 'fsinfo':
> samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use 
> in this function); did you mean 'fsinfo'?
>   return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
>  ^~~
>  fsinfo
> samples/vfs/test-statx.c: In function 'dump_statx':
> samples/vfs/test-statx.c:160:29: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>printf("Attributes: %016llx (", stx->stx_attributes);
>  

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

[Stephen Rothwell]

Hi Al, David,

These have returned, so I have disabled CONFIG_SAMPLE_VFS again.

On Mon, 10 Sep 2018 13:35:25 +1000 Stephen Rothwell  
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'?
>   return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
>  ^~~
>  fsinfo
> samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported 
> only once for each function it appears in
> samples/vfs/test-fsinfo.c: In function 'dump_attr_LIMITS':
> 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);
>~~~^ 
>%lx
> samples/vfs/test-fsinfo.c:181:32: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
>  ~~~^
>  %lx
>  f->max_uid, f->max_gid, f->max_projid);
>  ~~
> samples/vfs/test-fsinfo.c:181:39: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
> ~~~^
> %lx
>  f->max_uid, f->max_gid, f->max_projid);
>  ~~
> samples/vfs/test-fsinfo.c:181:46: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
>~~~^
>%lx
>  f->max_uid, f->max_gid, f->max_projid);
>  ~
> samples/vfs/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
> samples/vfs/test-fsinfo.c:197:24: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tstx_attr=%llx\n", f->stx_attributes);
>  ~~~^ ~
>  %lx
> samples/vfs/test-fsmount.c: In function 'fsopen':
> samples/vfs/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first use 
> in this function); did you mean 'fsopen'?
>   return syscall(__NR_fsopen, fs_name, flags);
>  ^~~
>  fsopen
> samples/vfs/test-fsmount.c:63:17: note: each undeclared identifier is 
> reported only once for each function it appears in
> samples/vfs/test-fsmount.c: In function 'fsmount':
> samples/vfs/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first use 
> in this function); did you mean 'fsmount'?
>   return syscall(__NR_fsmount, fsfd, flags, ms_flags);
>  ^~~~
>  fsmount
> samples/vfs/test-fsmount.c: In function 'fsconfig':
> samples/vfs/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared (first 
> use in this function); did you mean 'fsconfig'?
>   return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
>  ^
>  fsconfig
> samples/vfs/test-fsmount.c: In function 'move_mount':
> samples/vfs/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared (first 
> use in this function); did you mean 'move_mount'?
>   return syscall(__NR_move_mount,
>  ^~~
>  move_mount
> samples/vfs/test-fs-query.c: In function 'fsopen':
> samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use 
> in this function); did you mean 'fsopen'?
>   return syscall(__NR_fsopen, fs_name, flags);
>  ^~~
>  fsopen
> samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is 
> reported only once for each function it appears in
> samples/vfs/test-fs-query.c: In function 'fsinfo':
> samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use 
> in this function); did you mean 'fsinfo'?
>   return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
>  ^~~
>  fsinfo
> samples/vfs/test-statx.c: In function 'dump_statx':
> samples/vfs/test-statx.c:160:29: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>printf("Attributes: %016llx (", stx->stx_attributes);
>  

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

[Stephen Rothwell]

Hi Jaegeuk,

On Tue, 16 Oct 2018 09:37:44 -0700 Jaegeuk Kim  wrote:
>
> I've modified this patch in f2fs tree to use SB_RDONLY.

Thanks for that.

-- 
Cheers,
Stephen Rothwell


pgpFgDa4GbUu9.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Jaegeuk,

On Tue, 16 Oct 2018 09:37:44 -0700 Jaegeuk Kim  wrote:
>
> I've modified this patch in f2fs tree to use SB_RDONLY.

Thanks for that.

-- 
Cheers,
Stephen Rothwell


pgpFgDa4GbUu9.pgp
Description: OpenPGP digital signature

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

[Jaegeuk Kim]

On 10/16, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 3 Oct 2018 10:32:22 +1000 Stephen Rothwell  
> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > /home/sfr/next/next/fs/f2fs/super.c: In function 'f2fs_remount':
> > /home/sfr/next/next/fs/f2fs/super.c:1589:16: error: 'MS_RDONLY' undeclared 
> > (first use in this function); did you mean 'IS_RDONLY'?
> >   if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> > ^
> > IS_RDONLY
> > 
> > Caused by commit
> > 
> >   dcf8001d292b ("vfs: Suppress MS_* flag defs within the kernel unless 
> > explicitly enabled")
> > 
> > interacting with commit
> > 
> >   f80f781514ef ("f2fs: checkpoint disabling")
> > 
> > from the f2fs tree.
> > 
> > I have added the following merge fix patch for today.  If it is correct,
> > I assume that it could be applied to f2fs tree as the the other uses of
> > MS_RDONLY have already been changed to SB_RDONLY.  (There is another
> > use of MS_READONLY in this function that is already cleaned up in the
> > vfs tree commit.)
> 
> Can this be applied to the f2fs tree?

Hi Stephen,

I've modified this patch in f2fs tree to use SB_RDONLY.

Thanks,

> 
> > From: Stephen Rothwell 
> > Date: Wed, 3 Oct 2018 10:27:04 +1000
> > Subject: [PATCH] f2fs: update for MS_* flags mostly going away
> > 
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  fs/f2fs/super.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > index 6ed77589ff2b..b612a9e4a35e 100644
> > --- a/fs/f2fs/super.c
> > +++ b/fs/f2fs/super.c
> > @@ -1586,7 +1586,7 @@ static int f2fs_remount(struct super_block *sb, int 
> > *flags,
> > goto restore_opts;
> > }
> >  
> > -   if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> > +   if ((*flags & SB_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> > err = -EINVAL;
> > f2fs_msg(sbi->sb, KERN_WARNING,
> > "disabling checkpoint not compatible with read-only");
> > -- 
> > 2.18.0
> 
> -- 
> Cheers,
> Stephen Rothwell

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

[Jaegeuk Kim]

On 10/16, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 3 Oct 2018 10:32:22 +1000 Stephen Rothwell  
> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > /home/sfr/next/next/fs/f2fs/super.c: In function 'f2fs_remount':
> > /home/sfr/next/next/fs/f2fs/super.c:1589:16: error: 'MS_RDONLY' undeclared 
> > (first use in this function); did you mean 'IS_RDONLY'?
> >   if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> > ^
> > IS_RDONLY
> > 
> > Caused by commit
> > 
> >   dcf8001d292b ("vfs: Suppress MS_* flag defs within the kernel unless 
> > explicitly enabled")
> > 
> > interacting with commit
> > 
> >   f80f781514ef ("f2fs: checkpoint disabling")
> > 
> > from the f2fs tree.
> > 
> > I have added the following merge fix patch for today.  If it is correct,
> > I assume that it could be applied to f2fs tree as the the other uses of
> > MS_RDONLY have already been changed to SB_RDONLY.  (There is another
> > use of MS_READONLY in this function that is already cleaned up in the
> > vfs tree commit.)
> 
> Can this be applied to the f2fs tree?

Hi Stephen,

I've modified this patch in f2fs tree to use SB_RDONLY.

Thanks,

> 
> > From: Stephen Rothwell 
> > Date: Wed, 3 Oct 2018 10:27:04 +1000
> > Subject: [PATCH] f2fs: update for MS_* flags mostly going away
> > 
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  fs/f2fs/super.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > index 6ed77589ff2b..b612a9e4a35e 100644
> > --- a/fs/f2fs/super.c
> > +++ b/fs/f2fs/super.c
> > @@ -1586,7 +1586,7 @@ static int f2fs_remount(struct super_block *sb, int 
> > *flags,
> > goto restore_opts;
> > }
> >  
> > -   if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> > +   if ((*flags & SB_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> > err = -EINVAL;
> > f2fs_msg(sbi->sb, KERN_WARNING,
> > "disabling checkpoint not compatible with read-only");
> > -- 
> > 2.18.0
> 
> -- 
> Cheers,
> Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

On Wed, 3 Oct 2018 10:32:22 +1000 Stephen Rothwell  
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> /home/sfr/next/next/fs/f2fs/super.c: In function 'f2fs_remount':
> /home/sfr/next/next/fs/f2fs/super.c:1589:16: error: 'MS_RDONLY' undeclared 
> (first use in this function); did you mean 'IS_RDONLY'?
>   if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> ^
> IS_RDONLY
> 
> Caused by commit
> 
>   dcf8001d292b ("vfs: Suppress MS_* flag defs within the kernel unless 
> explicitly enabled")
> 
> interacting with commit
> 
>   f80f781514ef ("f2fs: checkpoint disabling")
> 
> from the f2fs tree.
> 
> I have added the following merge fix patch for today.  If it is correct,
> I assume that it could be applied to f2fs tree as the the other uses of
> MS_RDONLY have already been changed to SB_RDONLY.  (There is another
> use of MS_READONLY in this function that is already cleaned up in the
> vfs tree commit.)

Can this be applied to the f2fs tree?

> From: Stephen Rothwell 
> Date: Wed, 3 Oct 2018 10:27:04 +1000
> Subject: [PATCH] f2fs: update for MS_* flags mostly going away
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  fs/f2fs/super.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 6ed77589ff2b..b612a9e4a35e 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -1586,7 +1586,7 @@ static int f2fs_remount(struct super_block *sb, int 
> *flags,
>   goto restore_opts;
>   }
>  
> - if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> + if ((*flags & SB_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
>   err = -EINVAL;
>   f2fs_msg(sbi->sb, KERN_WARNING,
>   "disabling checkpoint not compatible with read-only");
> -- 
> 2.18.0

-- 
Cheers,
Stephen Rothwell


pgpxZe7Lo_ATH.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

On Wed, 3 Oct 2018 10:32:22 +1000 Stephen Rothwell  
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> /home/sfr/next/next/fs/f2fs/super.c: In function 'f2fs_remount':
> /home/sfr/next/next/fs/f2fs/super.c:1589:16: error: 'MS_RDONLY' undeclared 
> (first use in this function); did you mean 'IS_RDONLY'?
>   if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> ^
> IS_RDONLY
> 
> Caused by commit
> 
>   dcf8001d292b ("vfs: Suppress MS_* flag defs within the kernel unless 
> explicitly enabled")
> 
> interacting with commit
> 
>   f80f781514ef ("f2fs: checkpoint disabling")
> 
> from the f2fs tree.
> 
> I have added the following merge fix patch for today.  If it is correct,
> I assume that it could be applied to f2fs tree as the the other uses of
> MS_RDONLY have already been changed to SB_RDONLY.  (There is another
> use of MS_READONLY in this function that is already cleaned up in the
> vfs tree commit.)

Can this be applied to the f2fs tree?

> From: Stephen Rothwell 
> Date: Wed, 3 Oct 2018 10:27:04 +1000
> Subject: [PATCH] f2fs: update for MS_* flags mostly going away
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  fs/f2fs/super.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 6ed77589ff2b..b612a9e4a35e 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -1586,7 +1586,7 @@ static int f2fs_remount(struct super_block *sb, int 
> *flags,
>   goto restore_opts;
>   }
>  
> - if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> + if ((*flags & SB_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
>   err = -EINVAL;
>   f2fs_msg(sbi->sb, KERN_WARNING,
>   "disabling checkpoint not compatible with read-only");
> -- 
> 2.18.0

-- 
Cheers,
Stephen Rothwell


pgpxZe7Lo_ATH.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

/home/sfr/next/next/fs/f2fs/super.c: In function 'f2fs_remount':
/home/sfr/next/next/fs/f2fs/super.c:1589:16: error: 'MS_RDONLY' undeclared 
(first use in this function); did you mean 'IS_RDONLY'?
  if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
^
IS_RDONLY

Caused by commit

  dcf8001d292b ("vfs: Suppress MS_* flag defs within the kernel unless 
explicitly enabled")

interacting with commit

  f80f781514ef ("f2fs: checkpoint disabling")

from the f2fs tree.

I have added the following merge fix patch for today.  If it is correct,
I assume that it could be applied to f2fs tree as the the other uses of
MS_RDONLY have already been changed to SB_RDONLY.  (There is another
use of MS_READONLY in this function that is already cleaned up in the
vfs tree commit.)

From: Stephen Rothwell 
Date: Wed, 3 Oct 2018 10:27:04 +1000
Subject: [PATCH] f2fs: update for MS_* flags mostly going away

Signed-off-by: Stephen Rothwell 
---
 fs/f2fs/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 6ed77589ff2b..b612a9e4a35e 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1586,7 +1586,7 @@ static int f2fs_remount(struct super_block *sb, int 
*flags,
goto restore_opts;
}
 
-   if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
+   if ((*flags & SB_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
err = -EINVAL;
f2fs_msg(sbi->sb, KERN_WARNING,
"disabling checkpoint not compatible with read-only");
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell


pgpfDneKUFy5e.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

/home/sfr/next/next/fs/f2fs/super.c: In function 'f2fs_remount':
/home/sfr/next/next/fs/f2fs/super.c:1589:16: error: 'MS_RDONLY' undeclared 
(first use in this function); did you mean 'IS_RDONLY'?
  if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
^
IS_RDONLY

Caused by commit

  dcf8001d292b ("vfs: Suppress MS_* flag defs within the kernel unless 
explicitly enabled")

interacting with commit

  f80f781514ef ("f2fs: checkpoint disabling")

from the f2fs tree.

I have added the following merge fix patch for today.  If it is correct,
I assume that it could be applied to f2fs tree as the the other uses of
MS_RDONLY have already been changed to SB_RDONLY.  (There is another
use of MS_READONLY in this function that is already cleaned up in the
vfs tree commit.)

From: Stephen Rothwell 
Date: Wed, 3 Oct 2018 10:27:04 +1000
Subject: [PATCH] f2fs: update for MS_* flags mostly going away

Signed-off-by: Stephen Rothwell 
---
 fs/f2fs/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 6ed77589ff2b..b612a9e4a35e 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1586,7 +1586,7 @@ static int f2fs_remount(struct super_block *sb, int 
*flags,
goto restore_opts;
}
 
-   if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
+   if ((*flags & SB_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
err = -EINVAL;
f2fs_msg(sbi->sb, KERN_WARNING,
"disabling checkpoint not compatible with read-only");
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell


pgpfDneKUFy5e.pgp
Description: OpenPGP digital signature

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

[David Howells]

Michael Ellerman  wrote:

> I realise these are in samples rather than selftests, but what most of
> the selftests do is just #define the syscall number if it's not defined,
> so that you're not dependent on getting the headers.

The reason I don't want to do that is that syscall numbers aren't consistent
across arches - they aren't even consistent within arches.

I've made the VFS samples contingent on X86 in Kconfig for the moment.

David

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

[David Howells]

Michael Ellerman  wrote:

> I realise these are in samples rather than selftests, but what most of
> the selftests do is just #define the syscall number if it's not defined,
> so that you're not dependent on getting the headers.

The reason I don't want to do that is that syscall numbers aren't consistent
across arches - they aren't even consistent within arches.

I've made the VFS samples contingent on X86 in Kconfig for the moment.

David

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

[Michael Ellerman]

Stephen Rothwell  writes:
> Hi David,
>
> On Wed, 19 Sep 2018 07:01:00 +0100 David Howells  wrote:
>>
>> Stephen Rothwell  wrote:
>> 
>> > > 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.  
>> 
>> I meant put the dependency in the Kconfig.
>
> Yeah, sure.  Kconfig now has the ability for that dependency to be the
> result of an external program "$(shell )", so you could have a
> script or program that checked to see if the syscall numbers are
> defined and then have the Kconfig symbol(s) for the tests depend on that.

I realise these are in samples rather than selftests, but what most of
the selftests do is just #define the syscall number if it's not defined,
so that you're not dependent on getting the headers.

cheers

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

[Michael Ellerman]

Stephen Rothwell  writes:
> Hi David,
>
> On Wed, 19 Sep 2018 07:01:00 +0100 David Howells  wrote:
>>
>> Stephen Rothwell  wrote:
>> 
>> > > 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.  
>> 
>> I meant put the dependency in the Kconfig.
>
> Yeah, sure.  Kconfig now has the ability for that dependency to be the
> result of an external program "$(shell )", so you could have a
> script or program that checked to see if the syscall numbers are
> defined and then have the Kconfig symbol(s) for the tests depend on that.

I realise these are in samples rather than selftests, but what most of
the selftests do is just #define the syscall number if it's not defined,
so that you're not dependent on getting the headers.

cheers

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

[Michael Ellerman]

David Howells  writes:

> Stephen Rothwell  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?
>
>> > 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?

You can #define SANE_USERSPACE_TYPES to get ll64 for powerpc.

cheers

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

[Michael Ellerman]

David Howells  writes:

> Stephen Rothwell  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?
>
>> > 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?

You can #define SANE_USERSPACE_TYPES to get ll64 for powerpc.

cheers

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

[Geert Uytterhoeven]

On Wed, Sep 19, 2018 at 1:50 AM Stephen Rothwell  wrote:
> On Tue, 18 Sep 2018 23:17:21 +0100 David Howells  wrote:
> > Stephen Rothwell  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.

In kernelspace, it's unsigned long long on all architectures.
In userspace, it may still be unsigned long on early 64-bit architectures.

> Instead, just explicitly cast it to unsigned long long.

Or use C99's PRIx64?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Geert Uytterhoeven]

On Wed, Sep 19, 2018 at 1:50 AM Stephen Rothwell  wrote:
> On Tue, 18 Sep 2018 23:17:21 +0100 David Howells  wrote:
> > Stephen Rothwell  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.

In kernelspace, it's unsigned long long on all architectures.
In userspace, it may still be unsigned long on early 64-bit architectures.

> Instead, just explicitly cast it to unsigned long long.

Or use C99's PRIx64?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Stephen Rothwell]

Hi David,

On Wed, 19 Sep 2018 07:01:00 +0100 David Howells  wrote:
>
> Stephen Rothwell  wrote:
> 
> > > 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.  
> 
> I meant put the dependency in the Kconfig.

Yeah, sure.  Kconfig now has the ability for that dependency to be the
result of an external program "$(shell )", so you could have a
script or program that checked to see if the syscall numbers are
defined and then have the Kconfig symbol(s) for the tests depend on that.

-- 
Cheers,
Stephen Rothwell


pgpKC7z8d1KX6.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi David,

On Wed, 19 Sep 2018 07:01:00 +0100 David Howells  wrote:
>
> Stephen Rothwell  wrote:
> 
> > > 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.  
> 
> I meant put the dependency in the Kconfig.

Yeah, sure.  Kconfig now has the ability for that dependency to be the
result of an external program "$(shell )", so you could have a
script or program that checked to see if the syscall numbers are
defined and then have the Kconfig symbol(s) for the tests depend on that.

-- 
Cheers,
Stephen Rothwell


pgpKC7z8d1KX6.pgp
Description: OpenPGP digital signature

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

[David Howells]

Stephen Rothwell  wrote:

> > 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.

I meant put the dependency in the Kconfig.

David

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

[David Howells]

Stephen Rothwell  wrote:

> > 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.

I meant put the dependency in the Kconfig.

David

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

[Stephen Rothwell]

Hi David,

On Tue, 18 Sep 2018 23:17:21 +0100 David Howells  wrote:
>
> Stephen Rothwell  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


pgpNMMUCxl2Y0.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi David,

On Tue, 18 Sep 2018 23:17:21 +0100 David Howells  wrote:
>
> Stephen Rothwell  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


pgpNMMUCxl2Y0.pgp
Description: OpenPGP digital signature

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

[David Howells]

Stephen Rothwell  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?

> > 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?

David

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

[David Howells]

Stephen Rothwell  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?

> > 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?

David

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

[Stephen Rothwell]

Hi David, Al,

On Mon, 10 Sep 2018 13:35:25 +1000 Stephen Rothwell  
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'?
>   return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
>  ^~~
>  fsinfo
> samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported 
> only once for each function it appears in
> samples/vfs/test-fsinfo.c: In function 'dump_attr_LIMITS':
> 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);
>~~~^ 
>%lx
> samples/vfs/test-fsinfo.c:181:32: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
>  ~~~^
>  %lx
>  f->max_uid, f->max_gid, f->max_projid);
>  ~~
> samples/vfs/test-fsinfo.c:181:39: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
> ~~~^
> %lx
>  f->max_uid, f->max_gid, f->max_projid);
>  ~~
> samples/vfs/test-fsinfo.c:181:46: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
>~~~^
>%lx
>  f->max_uid, f->max_gid, f->max_projid);
>  ~
> samples/vfs/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
> samples/vfs/test-fsinfo.c:197:24: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tstx_attr=%llx\n", f->stx_attributes);
>  ~~~^ ~
>  %lx
> samples/vfs/test-fsmount.c: In function 'fsopen':
> samples/vfs/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first use 
> in this function); did you mean 'fsopen'?
>   return syscall(__NR_fsopen, fs_name, flags);
>  ^~~
>  fsopen
> samples/vfs/test-fsmount.c:63:17: note: each undeclared identifier is 
> reported only once for each function it appears in
> samples/vfs/test-fsmount.c: In function 'fsmount':
> samples/vfs/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first use 
> in this function); did you mean 'fsmount'?
>   return syscall(__NR_fsmount, fsfd, flags, ms_flags);
>  ^~~~
>  fsmount
> samples/vfs/test-fsmount.c: In function 'fsconfig':
> samples/vfs/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared (first 
> use in this function); did you mean 'fsconfig'?
>   return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
>  ^
>  fsconfig
> samples/vfs/test-fsmount.c: In function 'move_mount':
> samples/vfs/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared (first 
> use in this function); did you mean 'move_mount'?
>   return syscall(__NR_move_mount,
>  ^~~
>  move_mount
> samples/vfs/test-fs-query.c: In function 'fsopen':
> samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use 
> in this function); did you mean 'fsopen'?
>   return syscall(__NR_fsopen, fs_name, flags);
>  ^~~
>  fsopen
> samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is 
> reported only once for each function it appears in
> samples/vfs/test-fs-query.c: In function 'fsinfo':
> samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use 
> in this function); did you mean 'fsinfo'?
>   return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
>  ^~~
>  fsinfo
> samples/vfs/test-statx.c: In function 'dump_statx':
> samples/vfs/test-statx.c:160:29: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>printf("Attributes: %016llx (", stx->stx_attributes);
>~~^ ~~~
>   

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

[Stephen Rothwell]

Hi David, Al,

On Mon, 10 Sep 2018 13:35:25 +1000 Stephen Rothwell  
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'?
>   return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
>  ^~~
>  fsinfo
> samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported 
> only once for each function it appears in
> samples/vfs/test-fsinfo.c: In function 'dump_attr_LIMITS':
> 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);
>~~~^ 
>%lx
> samples/vfs/test-fsinfo.c:181:32: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
>  ~~~^
>  %lx
>  f->max_uid, f->max_gid, f->max_projid);
>  ~~
> samples/vfs/test-fsinfo.c:181:39: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
> ~~~^
> %lx
>  f->max_uid, f->max_gid, f->max_projid);
>  ~~
> samples/vfs/test-fsinfo.c:181:46: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
>~~~^
>%lx
>  f->max_uid, f->max_gid, f->max_projid);
>  ~
> samples/vfs/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
> samples/vfs/test-fsinfo.c:197:24: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>   printf("\tstx_attr=%llx\n", f->stx_attributes);
>  ~~~^ ~
>  %lx
> samples/vfs/test-fsmount.c: In function 'fsopen':
> samples/vfs/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first use 
> in this function); did you mean 'fsopen'?
>   return syscall(__NR_fsopen, fs_name, flags);
>  ^~~
>  fsopen
> samples/vfs/test-fsmount.c:63:17: note: each undeclared identifier is 
> reported only once for each function it appears in
> samples/vfs/test-fsmount.c: In function 'fsmount':
> samples/vfs/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first use 
> in this function); did you mean 'fsmount'?
>   return syscall(__NR_fsmount, fsfd, flags, ms_flags);
>  ^~~~
>  fsmount
> samples/vfs/test-fsmount.c: In function 'fsconfig':
> samples/vfs/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared (first 
> use in this function); did you mean 'fsconfig'?
>   return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
>  ^
>  fsconfig
> samples/vfs/test-fsmount.c: In function 'move_mount':
> samples/vfs/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared (first 
> use in this function); did you mean 'move_mount'?
>   return syscall(__NR_move_mount,
>  ^~~
>  move_mount
> samples/vfs/test-fs-query.c: In function 'fsopen':
> samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use 
> in this function); did you mean 'fsopen'?
>   return syscall(__NR_fsopen, fs_name, flags);
>  ^~~
>  fsopen
> samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is 
> reported only once for each function it appears in
> samples/vfs/test-fs-query.c: In function 'fsinfo':
> samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use 
> in this function); did you mean 'fsinfo'?
>   return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
>  ^~~
>  fsinfo
> samples/vfs/test-statx.c: In function 'dump_statx':
> samples/vfs/test-statx.c:160:29: warning: format '%llx' expects argument of 
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
> unsigned int'} [-Wformat=]
>printf("Attributes: %016llx (", stx->stx_attributes);
>~~^ ~~~
>   

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (sparc64 defconfig)
failed like this:

In file included from arch/sparc/include/asm/fbio.h:5:0,
 from fs/compat_ioctl.c:76:
arch/sparc/include/uapi/asm/fbio.h:100:25: error: field 'pos' has incomplete 
type
 struct fbcurpos pos;/* cursor position */
 ^~~
arch/sparc/include/uapi/asm/fbio.h:101:25: error: field 'hot' has incomplete 
type
 struct fbcurpos hot;/* cursor hot spot */
 ^~~
arch/sparc/include/uapi/asm/fbio.h:103:25: error: field 'size' has incomplete 
type
 struct fbcurpos size;   /* cursor bit map size */
 ^~~~
In file included from fs/compat_ioctl.c:76:0:
arch/sparc/include/asm/fbio.h:63:18: error: field 'pos' has incomplete type
  struct fbcurpos pos; /* cursor position */
  ^~~
arch/sparc/include/asm/fbio.h:64:18: error: field 'hot' has incomplete type
  struct fbcurpos hot; /* cursor hot spot */
  ^~~
arch/sparc/include/asm/fbio.h:66:18: error: field 'size' has incomplete type
  struct fbcurpos size; /* cursor bit map size */
  ^~~~
arch/sparc/include/uapi/asm/fbio.h:113:39: error: invalid application of 
'sizeof' to incomplete type 'struct fbcurpos'
 #define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
   ^
fs/compat_ioctl.c:640:21: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
 ^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
 #define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
   ^~~~
fs/compat_ioctl.c:1188:1: note: in expansion of macro 'IGNORE_IOCTL'
 IGNORE_IOCTL(FBIOSCURPOS)
 ^~~~
arch/sparc/include/uapi/asm/ioctl.h:47:29: note: in expansion of macro '_IOC'
 #define _IOW(type,nr,size)  _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
 ^~~~
arch/sparc/include/uapi/asm/fbio.h:113:25: note: in expansion of macro '_IOW'
 #define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
 ^~~~
fs/compat_ioctl.c:1188:14: note: in expansion of macro 'FBIOSCURPOS'
 IGNORE_IOCTL(FBIOSCURPOS)
  ^~~
arch/sparc/include/uapi/asm/fbio.h:113:39: error: invalid application of 
'sizeof' to incomplete type 'struct fbcurpos'
 #define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
   ^
fs/compat_ioctl.c:640:28: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
 #define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
   ^~~~
fs/compat_ioctl.c:1188:1: note: in expansion of macro 'IGNORE_IOCTL'
 IGNORE_IOCTL(FBIOSCURPOS)
 ^~~~
arch/sparc/include/uapi/asm/ioctl.h:47:29: note: in expansion of macro '_IOC'
 #define _IOW(type,nr,size)  _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
 ^~~~
arch/sparc/include/uapi/asm/fbio.h:113:25: note: in expansion of macro '_IOW'
 #define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
 ^~~~
fs/compat_ioctl.c:1188:14: note: in expansion of macro 'FBIOSCURPOS'
 IGNORE_IOCTL(FBIOSCURPOS)
  ^~~
arch/sparc/include/uapi/asm/fbio.h:113:39: error: invalid application of 
'sizeof' to incomplete type 'struct fbcurpos'
 #define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
   ^
fs/compat_ioctl.c:640:42: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
  ^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
 #define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
   ^~~~
fs/compat_ioctl.c:1188:1: note: in expansion of macro 'IGNORE_IOCTL'
 IGNORE_IOCTL(FBIOSCURPOS)
 ^~~~
arch/sparc/include/uapi/asm/ioctl.h:47:29: note: in expansion of macro '_IOC'
 #define _IOW(type,nr,size)  _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
 ^~~~
arch/sparc/include/uapi/asm/fbio.h:113:25: note: in expansion of macro '_IOW'
 #define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
 ^~~~
fs/compat_ioctl.c:1188:14: note: in expansion of macro 'FBIOSCURPOS'
 IGNORE_IOCTL(FBIOSCURPOS)
  ^~~
arch/sparc/include/uapi/asm/fbio.h:114:39: error: invalid application of 
'sizeof' to incomplete type 'struct fbcurpos'
 #define FBIOGCURPOS _IOW('F', 27, struct fbcurpos)
   ^
fs/compat_ioctl.c:640:21: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
 ^
fs/compat_ioctl.c:650:27: note: in expansion of macro 

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (sparc64 defconfig)
failed like this:

In file included from arch/sparc/include/asm/fbio.h:5:0,
 from fs/compat_ioctl.c:76:
arch/sparc/include/uapi/asm/fbio.h:100:25: error: field 'pos' has incomplete 
type
 struct fbcurpos pos;/* cursor position */
 ^~~
arch/sparc/include/uapi/asm/fbio.h:101:25: error: field 'hot' has incomplete 
type
 struct fbcurpos hot;/* cursor hot spot */
 ^~~
arch/sparc/include/uapi/asm/fbio.h:103:25: error: field 'size' has incomplete 
type
 struct fbcurpos size;   /* cursor bit map size */
 ^~~~
In file included from fs/compat_ioctl.c:76:0:
arch/sparc/include/asm/fbio.h:63:18: error: field 'pos' has incomplete type
  struct fbcurpos pos; /* cursor position */
  ^~~
arch/sparc/include/asm/fbio.h:64:18: error: field 'hot' has incomplete type
  struct fbcurpos hot; /* cursor hot spot */
  ^~~
arch/sparc/include/asm/fbio.h:66:18: error: field 'size' has incomplete type
  struct fbcurpos size; /* cursor bit map size */
  ^~~~
arch/sparc/include/uapi/asm/fbio.h:113:39: error: invalid application of 
'sizeof' to incomplete type 'struct fbcurpos'
 #define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
   ^
fs/compat_ioctl.c:640:21: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
 ^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
 #define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
   ^~~~
fs/compat_ioctl.c:1188:1: note: in expansion of macro 'IGNORE_IOCTL'
 IGNORE_IOCTL(FBIOSCURPOS)
 ^~~~
arch/sparc/include/uapi/asm/ioctl.h:47:29: note: in expansion of macro '_IOC'
 #define _IOW(type,nr,size)  _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
 ^~~~
arch/sparc/include/uapi/asm/fbio.h:113:25: note: in expansion of macro '_IOW'
 #define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
 ^~~~
fs/compat_ioctl.c:1188:14: note: in expansion of macro 'FBIOSCURPOS'
 IGNORE_IOCTL(FBIOSCURPOS)
  ^~~
arch/sparc/include/uapi/asm/fbio.h:113:39: error: invalid application of 
'sizeof' to incomplete type 'struct fbcurpos'
 #define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
   ^
fs/compat_ioctl.c:640:28: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
 #define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
   ^~~~
fs/compat_ioctl.c:1188:1: note: in expansion of macro 'IGNORE_IOCTL'
 IGNORE_IOCTL(FBIOSCURPOS)
 ^~~~
arch/sparc/include/uapi/asm/ioctl.h:47:29: note: in expansion of macro '_IOC'
 #define _IOW(type,nr,size)  _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
 ^~~~
arch/sparc/include/uapi/asm/fbio.h:113:25: note: in expansion of macro '_IOW'
 #define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
 ^~~~
fs/compat_ioctl.c:1188:14: note: in expansion of macro 'FBIOSCURPOS'
 IGNORE_IOCTL(FBIOSCURPOS)
  ^~~
arch/sparc/include/uapi/asm/fbio.h:113:39: error: invalid application of 
'sizeof' to incomplete type 'struct fbcurpos'
 #define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
   ^
fs/compat_ioctl.c:640:42: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
  ^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
 #define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
   ^~~~
fs/compat_ioctl.c:1188:1: note: in expansion of macro 'IGNORE_IOCTL'
 IGNORE_IOCTL(FBIOSCURPOS)
 ^~~~
arch/sparc/include/uapi/asm/ioctl.h:47:29: note: in expansion of macro '_IOC'
 #define _IOW(type,nr,size)  _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
 ^~~~
arch/sparc/include/uapi/asm/fbio.h:113:25: note: in expansion of macro '_IOW'
 #define FBIOSCURPOS _IOW('F', 26, struct fbcurpos)
 ^~~~
fs/compat_ioctl.c:1188:14: note: in expansion of macro 'FBIOSCURPOS'
 IGNORE_IOCTL(FBIOSCURPOS)
  ^~~
arch/sparc/include/uapi/asm/fbio.h:114:39: error: invalid application of 
'sizeof' to incomplete type 'struct fbcurpos'
 #define FBIOGCURPOS _IOW('F', 27, struct fbcurpos)
   ^
fs/compat_ioctl.c:640:21: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
 ^
fs/compat_ioctl.c:650:27: note: in expansion of macro 

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

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'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 fsinfo
samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/vfs/test-fsinfo.c: In function 'dump_attr_LIMITS':
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);
   ~~~^ 
   %lx
samples/vfs/test-fsinfo.c:181:32: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
 ~~~^
 %lx
 f->max_uid, f->max_gid, f->max_projid);
 ~~
samples/vfs/test-fsinfo.c:181:39: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
~~~^
%lx
 f->max_uid, f->max_gid, f->max_projid);
 ~~
samples/vfs/test-fsinfo.c:181:46: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
   ~~~^
   %lx
 f->max_uid, f->max_gid, f->max_projid);
 ~
samples/vfs/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
samples/vfs/test-fsinfo.c:197:24: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tstx_attr=%llx\n", f->stx_attributes);
 ~~~^ ~
 %lx
samples/vfs/test-fsmount.c: In function 'fsopen':
samples/vfs/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first use in 
this function); did you mean 'fsopen'?
  return syscall(__NR_fsopen, fs_name, flags);
 ^~~
 fsopen
samples/vfs/test-fsmount.c:63:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/vfs/test-fsmount.c: In function 'fsmount':
samples/vfs/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first use 
in this function); did you mean 'fsmount'?
  return syscall(__NR_fsmount, fsfd, flags, ms_flags);
 ^~~~
 fsmount
samples/vfs/test-fsmount.c: In function 'fsconfig':
samples/vfs/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared (first use 
in this function); did you mean 'fsconfig'?
  return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
 ^
 fsconfig
samples/vfs/test-fsmount.c: In function 'move_mount':
samples/vfs/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared (first 
use in this function); did you mean 'move_mount'?
  return syscall(__NR_move_mount,
 ^~~
 move_mount
samples/vfs/test-fs-query.c: In function 'fsopen':
samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use 
in this function); did you mean 'fsopen'?
  return syscall(__NR_fsopen, fs_name, flags);
 ^~~
 fsopen
samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/vfs/test-fs-query.c: In function 'fsinfo':
samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use 
in this function); did you mean 'fsinfo'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 fsinfo
samples/vfs/test-statx.c: In function 'dump_statx':
samples/vfs/test-statx.c:160:29: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
   printf("Attributes: %016llx (", stx->stx_attributes);
   ~~^ ~~~
   %016lx

Caused by commits

  2615362dc9ce ("vfs: Add a sample program for the new mount API")
  e9078278ec11 ("vfs: syscall: Add fsinfo() to query filesystem information")

The directory name has changed, but the errors persist!

I have applied this 

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

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'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 fsinfo
samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/vfs/test-fsinfo.c: In function 'dump_attr_LIMITS':
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);
   ~~~^ 
   %lx
samples/vfs/test-fsinfo.c:181:32: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
 ~~~^
 %lx
 f->max_uid, f->max_gid, f->max_projid);
 ~~
samples/vfs/test-fsinfo.c:181:39: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
~~~^
%lx
 f->max_uid, f->max_gid, f->max_projid);
 ~~
samples/vfs/test-fsinfo.c:181:46: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
   ~~~^
   %lx
 f->max_uid, f->max_gid, f->max_projid);
 ~
samples/vfs/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
samples/vfs/test-fsinfo.c:197:24: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tstx_attr=%llx\n", f->stx_attributes);
 ~~~^ ~
 %lx
samples/vfs/test-fsmount.c: In function 'fsopen':
samples/vfs/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first use in 
this function); did you mean 'fsopen'?
  return syscall(__NR_fsopen, fs_name, flags);
 ^~~
 fsopen
samples/vfs/test-fsmount.c:63:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/vfs/test-fsmount.c: In function 'fsmount':
samples/vfs/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first use 
in this function); did you mean 'fsmount'?
  return syscall(__NR_fsmount, fsfd, flags, ms_flags);
 ^~~~
 fsmount
samples/vfs/test-fsmount.c: In function 'fsconfig':
samples/vfs/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared (first use 
in this function); did you mean 'fsconfig'?
  return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
 ^
 fsconfig
samples/vfs/test-fsmount.c: In function 'move_mount':
samples/vfs/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared (first 
use in this function); did you mean 'move_mount'?
  return syscall(__NR_move_mount,
 ^~~
 move_mount
samples/vfs/test-fs-query.c: In function 'fsopen':
samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use 
in this function); did you mean 'fsopen'?
  return syscall(__NR_fsopen, fs_name, flags);
 ^~~
 fsopen
samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/vfs/test-fs-query.c: In function 'fsinfo':
samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use 
in this function); did you mean 'fsinfo'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 fsinfo
samples/vfs/test-statx.c: In function 'dump_statx':
samples/vfs/test-statx.c:160:29: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
   printf("Attributes: %016llx (", stx->stx_attributes);
   ~~^ ~~~
   %016lx

Caused by commits

  2615362dc9ce ("vfs: Add a sample program for the new mount API")
  e9078278ec11 ("vfs: syscall: Add fsinfo() to query filesystem information")

The directory name has changed, but the errors persist!

I have applied this 

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (powerpc
allyesconfig) failed like this:

samples/mount_api/test-fsmount.c: In function 'fsopen':
samples/mount_api/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first 
use in this function); did you mean 'fsopen'?
  return syscall(__NR_fsopen, fs_name, flags);
 ^~~
 fsopen
samples/mount_api/test-fsmount.c:63:17: note: each undeclared identifier is 
reported only once for each function it appears in
samples/mount_api/test-fsmount.c: In function 'fsmount':
samples/mount_api/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first 
use in this function); did you mean 'fsmount'?
  return syscall(__NR_fsmount, fsfd, flags, ms_flags);
 ^~~~
 fsmount
samples/mount_api/test-fsmount.c: In function 'fsconfig':
samples/mount_api/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared 
(first use in this function); did you mean 'fsconfig'?
  return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
 ^
 fsconfig
samples/mount_api/test-fsmount.c: In function 'move_mount':
samples/mount_api/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared 
(first use in this function); did you mean 'move_mount'?
  return syscall(__NR_move_mount,
 ^~~
 move_mount
samples/statx/test-fs-query.c: In function 'fsopen':
samples/statx/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use 
in this function); did you mean 'fsopen'?
  return syscall(__NR_fsopen, fs_name, flags);
 ^~~
 fsopen
samples/statx/test-fs-query.c:32:17: note: each undeclared identifier is 
reported only once for each function it appears in
samples/statx/test-fs-query.c: In function 'fsinfo':
samples/statx/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use 
in this function); did you mean 'fsinfo'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 fsinfo
samples/statx/test-fsinfo.c: In function 'fsinfo':
samples/statx/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use 
in this function); did you mean 'fsinfo'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 fsinfo
samples/statx/test-fsinfo.c:37:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/statx/test-fsinfo.c: In function 'dump_attr_LIMITS':
samples/statx/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);
   ~~~^ 
   %lx
samples/statx/test-fsinfo.c:181:32: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
 ~~~^
 %lx
 f->max_uid, f->max_gid, f->max_projid);
 ~~
samples/statx/test-fsinfo.c:181:39: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
~~~^
%lx
 f->max_uid, f->max_gid, f->max_projid);
 ~~
samples/statx/test-fsinfo.c:181:46: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
   ~~~^
   %lx
 f->max_uid, f->max_gid, f->max_projid);
 ~
samples/statx/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
samples/statx/test-fsinfo.c:197:24: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tstx_attr=%llx\n", f->stx_attributes);
 ~~~^ ~
 %lx
samples/statx/test-statx.c: In function 'dump_statx':
samples/statx/test-statx.c:160:29: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
   printf("Attributes: %016llx (", stx->stx_attributes);
   ~~^ ~~~
   %016lx

Caused by commits

  3e83f58bcc4f ("vfs: Add a sample program for the new mount API")
  67f668a6a913 ("vfs: syscall: Add fsinfo() to query filesystem 

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (powerpc
allyesconfig) failed like this:

samples/mount_api/test-fsmount.c: In function 'fsopen':
samples/mount_api/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first 
use in this function); did you mean 'fsopen'?
  return syscall(__NR_fsopen, fs_name, flags);
 ^~~
 fsopen
samples/mount_api/test-fsmount.c:63:17: note: each undeclared identifier is 
reported only once for each function it appears in
samples/mount_api/test-fsmount.c: In function 'fsmount':
samples/mount_api/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first 
use in this function); did you mean 'fsmount'?
  return syscall(__NR_fsmount, fsfd, flags, ms_flags);
 ^~~~
 fsmount
samples/mount_api/test-fsmount.c: In function 'fsconfig':
samples/mount_api/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared 
(first use in this function); did you mean 'fsconfig'?
  return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
 ^
 fsconfig
samples/mount_api/test-fsmount.c: In function 'move_mount':
samples/mount_api/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared 
(first use in this function); did you mean 'move_mount'?
  return syscall(__NR_move_mount,
 ^~~
 move_mount
samples/statx/test-fs-query.c: In function 'fsopen':
samples/statx/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use 
in this function); did you mean 'fsopen'?
  return syscall(__NR_fsopen, fs_name, flags);
 ^~~
 fsopen
samples/statx/test-fs-query.c:32:17: note: each undeclared identifier is 
reported only once for each function it appears in
samples/statx/test-fs-query.c: In function 'fsinfo':
samples/statx/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use 
in this function); did you mean 'fsinfo'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 fsinfo
samples/statx/test-fsinfo.c: In function 'fsinfo':
samples/statx/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use 
in this function); did you mean 'fsinfo'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 fsinfo
samples/statx/test-fsinfo.c:37:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/statx/test-fsinfo.c: In function 'dump_attr_LIMITS':
samples/statx/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);
   ~~~^ 
   %lx
samples/statx/test-fsinfo.c:181:32: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
 ~~~^
 %lx
 f->max_uid, f->max_gid, f->max_projid);
 ~~
samples/statx/test-fsinfo.c:181:39: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
~~~^
%lx
 f->max_uid, f->max_gid, f->max_projid);
 ~~
samples/statx/test-fsinfo.c:181:46: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
   ~~~^
   %lx
 f->max_uid, f->max_gid, f->max_projid);
 ~
samples/statx/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
samples/statx/test-fsinfo.c:197:24: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
  printf("\tstx_attr=%llx\n", f->stx_attributes);
 ~~~^ ~
 %lx
samples/statx/test-statx.c: In function 'dump_statx':
samples/statx/test-statx.c:160:29: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long 
unsigned int'} [-Wformat=]
   printf("Attributes: %016llx (", stx->stx_attributes);
   ~~^ ~~~
   %016lx

Caused by commits

  3e83f58bcc4f ("vfs: Add a sample program for the new mount API")
  67f668a6a913 ("vfs: syscall: Add fsinfo() to query filesystem 

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (powercp
allyesconfig) failed like this (I have also included all the warnings):

samples/statx/test-fsinfo.c: In function 'fsinfo':
samples/statx/test-fsinfo.c:36:17: error: '__NR_fsinfo' undeclared (first use 
in this function); did you mean '__NR_sysinfo'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 __NR_sysinfo
samples/statx/test-fsinfo.c:36:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/statx/test-fsinfo.c: In function 'dump_attr_LIMITS':
samples/statx/test-fsinfo.c:181: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);
   ~~~^ 
   %lx
samples/statx/test-fsinfo.c:182:32: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64 {aka long 
unsigned int}' [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
 ~~~^
 %lx
 f->max_uid, f->max_gid, f->max_projid);
 ~~  
samples/statx/test-fsinfo.c:182:39: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 3 has type '__u64 {aka long 
unsigned int}' [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
~~~^
%lx
 f->max_uid, f->max_gid, f->max_projid);
 ~~ 
samples/statx/test-fsinfo.c:182:46: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 4 has type '__u64 {aka long 
unsigned int}' [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
   ~~~^
   %lx
 f->max_uid, f->max_gid, f->max_projid);
 ~ 
samples/statx/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
samples/statx/test-fsinfo.c:198:24: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64 {aka long 
unsigned int}' [-Wformat=]
  printf("\tstx_attr=%llx\n", f->stx_attributes);
 ~~~^ ~
 %lx
samples/statx/test-fsinfo.c: In function 'fsinfo':
samples/statx/test-fsinfo.c:37:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^
scripts/Makefile.host:90: recipe for target 'samples/statx/test-fsinfo' failed
samples/statx/test-statx.c: In function 'dump_statx':
samples/statx/test-statx.c:160:29: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64 {aka long 
unsigned int}' [-Wformat=]
   printf("Attributes: %016llx (", stx->stx_attributes);
   ~~^ ~~~
   %016lx
samples/statx/test-fs-query.c: In function 'fsopen':
samples/statx/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use 
in this function); did you mean '__NR_open'?
  return syscall(__NR_fsopen, fs_name, flags);
 ^~~
 __NR_open
samples/statx/test-fs-query.c:32:17: note: each undeclared identifier is 
reported only once for each function it appears in
samples/statx/test-fs-query.c: In function 'fsinfo':
samples/statx/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use 
in this function); did you mean '__NR_sysinfo'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 __NR_sysinfo
samples/statx/test-fs-query.c: In function 'fsopen':
samples/statx/test-fs-query.c:33:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^
samples/statx/test-fs-query.c: In function 'fsinfo':
samples/statx/test-fs-query.c:39:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^

Caused by commit

  ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")

which enabled CONFIG_SAMPLE_STATX.  I have disabled that again.  I assume
that problem is that these syscalls are not yet wired up on PowerPC ...

-- 
Cheers,
Stephen Rothwell


pgpzNp0X5JvvU.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (powercp
allyesconfig) failed like this (I have also included all the warnings):

samples/statx/test-fsinfo.c: In function 'fsinfo':
samples/statx/test-fsinfo.c:36:17: error: '__NR_fsinfo' undeclared (first use 
in this function); did you mean '__NR_sysinfo'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 __NR_sysinfo
samples/statx/test-fsinfo.c:36:17: note: each undeclared identifier is reported 
only once for each function it appears in
samples/statx/test-fsinfo.c: In function 'dump_attr_LIMITS':
samples/statx/test-fsinfo.c:181: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);
   ~~~^ 
   %lx
samples/statx/test-fsinfo.c:182:32: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64 {aka long 
unsigned int}' [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
 ~~~^
 %lx
 f->max_uid, f->max_gid, f->max_projid);
 ~~  
samples/statx/test-fsinfo.c:182:39: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 3 has type '__u64 {aka long 
unsigned int}' [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
~~~^
%lx
 f->max_uid, f->max_gid, f->max_projid);
 ~~ 
samples/statx/test-fsinfo.c:182:46: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 4 has type '__u64 {aka long 
unsigned int}' [-Wformat=]
  printf("\tmax ids  : u=%llx g=%llx p=%llx\n",
   ~~~^
   %lx
 f->max_uid, f->max_gid, f->max_projid);
 ~ 
samples/statx/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
samples/statx/test-fsinfo.c:198:24: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64 {aka long 
unsigned int}' [-Wformat=]
  printf("\tstx_attr=%llx\n", f->stx_attributes);
 ~~~^ ~
 %lx
samples/statx/test-fsinfo.c: In function 'fsinfo':
samples/statx/test-fsinfo.c:37:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^
scripts/Makefile.host:90: recipe for target 'samples/statx/test-fsinfo' failed
samples/statx/test-statx.c: In function 'dump_statx':
samples/statx/test-statx.c:160:29: warning: format '%llx' expects argument of 
type 'long long unsigned int', but argument 2 has type '__u64 {aka long 
unsigned int}' [-Wformat=]
   printf("Attributes: %016llx (", stx->stx_attributes);
   ~~^ ~~~
   %016lx
samples/statx/test-fs-query.c: In function 'fsopen':
samples/statx/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use 
in this function); did you mean '__NR_open'?
  return syscall(__NR_fsopen, fs_name, flags);
 ^~~
 __NR_open
samples/statx/test-fs-query.c:32:17: note: each undeclared identifier is 
reported only once for each function it appears in
samples/statx/test-fs-query.c: In function 'fsinfo':
samples/statx/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use 
in this function); did you mean '__NR_sysinfo'?
  return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
 ^~~
 __NR_sysinfo
samples/statx/test-fs-query.c: In function 'fsopen':
samples/statx/test-fs-query.c:33:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^
samples/statx/test-fs-query.c: In function 'fsinfo':
samples/statx/test-fs-query.c:39:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^

Caused by commit

  ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")

which enabled CONFIG_SAMPLE_STATX.  I have disabled that again.  I assume
that problem is that these syscalls are not yet wired up on PowerPC ...

-- 
Cheers,
Stephen Rothwell


pgpzNp0X5JvvU.pgp
Description: OpenPGP digital signature

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

[Masahiro Yamada]

2018-08-07 9:59 GMT+09:00 Stephen Rothwell :
> Hi all,
>
> On Mon, 6 Aug 2018 22:24:01 +1000 Stephen Rothwell  
> wrote:
>>
>> On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell  
>> wrote:
>> >
>> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
>> > failed like this:
>> >
>> > samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such 
>> > file or directory
>> >  #include 
>> >   ^~~~
>> >
>> > Caused by commit
>> >
>> >   90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem 
>> > information")
>> >
>> > I guess that headers_install (or whatever its called) has not bee run
>> > before the sample code is built.
>> >
>> > I have applied the following patch for today:
>> >
>> > From: Stephen Rothwell 
>> > Date: Mon, 6 Aug 2018 10:29:34 +1000
>> > Subject: [PATCH] vfs: don;t build new sample programs yet
>> >
>> > It seems that headers_install is not done before the samples
>> > are build so some needed include files are not in the right place.
>> >
>> > Signed-off-by: Stephen Rothwell 
>> > ---
>> >  samples/statx/Makefile | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/samples/statx/Makefile b/samples/statx/Makefile
>> > index 05b4d30cdd3c..0b4d01822eca 100644
>> > --- a/samples/statx/Makefile
>> > +++ b/samples/statx/Makefile
>> > @@ -1,5 +1,5 @@
>> >  # List of programs to build
>> > -hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
>> > +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
>> >
>> >  # Tell kbuild to always build the programs
>> >  always := $(hostprogs-y)
>>
>> It turns out that commit
>>
>>   ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")
>>
>> removed the "depends on BROKEN" from CONFIG_SAMPLE_STATX and that
>> breaks other builds (at least allyesconfig on s390).
>
> I have added the following suggested patch (I am sorry I can't
> find/remember who pointed me to this patch) for today (I guess that it
> should be merged via the vfs tree as that is what is causing the build
> failures ... in which case a real patch should be supplied with
> appropriate SOB line).  This seems to fix the current problem.
>
> From: Masahiro Yamada 
> Date: Tue, 7 Aug 2018 10:33:43 +1000
> Subject: [PATCH] Try to get the headers installed before we build the samples
>
> Signed-off-by: Stephen Rothwell 
> ---
>  Makefile | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Makefile b/Makefile
> index 9e71826f67d7..d224d94c14be 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1023,6 +1023,7 @@ endif
>  # Build samples along the rest of the kernel
>  ifdef CONFIG_SAMPLES
>  vmlinux-dirs += samples
> +samples: headers_install
>  endif
>
>  # The actual objects are generated when descending,
> --


OK, I will queue this up to my tree.


I suggested this in the discussion:
https://patchwork.kernel.org/patch/10552353/

I did not get response, though.




-- 
Best Regards
Masahiro Yamada

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

[Masahiro Yamada]

2018-08-07 9:59 GMT+09:00 Stephen Rothwell :
> Hi all,
>
> On Mon, 6 Aug 2018 22:24:01 +1000 Stephen Rothwell  
> wrote:
>>
>> On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell  
>> wrote:
>> >
>> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
>> > failed like this:
>> >
>> > samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such 
>> > file or directory
>> >  #include 
>> >   ^~~~
>> >
>> > Caused by commit
>> >
>> >   90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem 
>> > information")
>> >
>> > I guess that headers_install (or whatever its called) has not bee run
>> > before the sample code is built.
>> >
>> > I have applied the following patch for today:
>> >
>> > From: Stephen Rothwell 
>> > Date: Mon, 6 Aug 2018 10:29:34 +1000
>> > Subject: [PATCH] vfs: don;t build new sample programs yet
>> >
>> > It seems that headers_install is not done before the samples
>> > are build so some needed include files are not in the right place.
>> >
>> > Signed-off-by: Stephen Rothwell 
>> > ---
>> >  samples/statx/Makefile | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/samples/statx/Makefile b/samples/statx/Makefile
>> > index 05b4d30cdd3c..0b4d01822eca 100644
>> > --- a/samples/statx/Makefile
>> > +++ b/samples/statx/Makefile
>> > @@ -1,5 +1,5 @@
>> >  # List of programs to build
>> > -hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
>> > +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
>> >
>> >  # Tell kbuild to always build the programs
>> >  always := $(hostprogs-y)
>>
>> It turns out that commit
>>
>>   ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")
>>
>> removed the "depends on BROKEN" from CONFIG_SAMPLE_STATX and that
>> breaks other builds (at least allyesconfig on s390).
>
> I have added the following suggested patch (I am sorry I can't
> find/remember who pointed me to this patch) for today (I guess that it
> should be merged via the vfs tree as that is what is causing the build
> failures ... in which case a real patch should be supplied with
> appropriate SOB line).  This seems to fix the current problem.
>
> From: Masahiro Yamada 
> Date: Tue, 7 Aug 2018 10:33:43 +1000
> Subject: [PATCH] Try to get the headers installed before we build the samples
>
> Signed-off-by: Stephen Rothwell 
> ---
>  Makefile | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Makefile b/Makefile
> index 9e71826f67d7..d224d94c14be 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1023,6 +1023,7 @@ endif
>  # Build samples along the rest of the kernel
>  ifdef CONFIG_SAMPLES
>  vmlinux-dirs += samples
> +samples: headers_install
>  endif
>
>  # The actual objects are generated when descending,
> --


OK, I will queue this up to my tree.


I suggested this in the discussion:
https://patchwork.kernel.org/patch/10552353/

I did not get response, though.




-- 
Best Regards
Masahiro Yamada

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

/usr/bin/ld: /home/sfr/next/tmp/ccWnssuq.o: in function 
`dump_attr_TIMESTAMP_INFO':
test-fsinfo.c:(.text+0x5d4): undefined reference to `pow'
/usr/bin/ld: test-fsinfo.c:(.text+0x618): undefined reference to `pow'
/usr/bin/ld: test-fsinfo.c:(.text+0x65c): undefined reference to `pow'
/usr/bin/ld: test-fsinfo.c:(.text+0x6a0): undefined reference to `pow'

Caused by commit

  90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem information")

interacting with commit

  8377bd2b9ee1 ("kbuild: Rename HOST_LOADLIBES to KBUILD_HOSTLDLIBS")

from the kbuild tree.

I have added the following merge fix patch for today:

From: Stephen Rothwell 
Date: Tue, 7 Aug 2018 11:01:32 +1000
Subject: [PATCH] vfs: samples: fix up for HOSTLOADLIBES rename

Signed-off-by: Stephen Rothwell 
---
 samples/statx/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/samples/statx/Makefile b/samples/statx/Makefile
index 05b4d30cdd3c..6a862bbc0627 100644
--- a/samples/statx/Makefile
+++ b/samples/statx/Makefile
@@ -7,6 +7,6 @@ always := $(hostprogs-y)
 HOSTCFLAGS_test-statx.o += -I$(objtree)/usr/include
 
 HOSTCFLAGS_test-fsinfo.o += -I$(objtree)/usr/include
-HOSTLOADLIBES_test-fsinfo += -lm
+HOSTLDLIBS_test-fsinfo += -lm
 
 HOSTCFLAGS_test-fs-query.o += -I$(objtree)/usr/include
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell


pgp_cmlOTOSr4.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

/usr/bin/ld: /home/sfr/next/tmp/ccWnssuq.o: in function 
`dump_attr_TIMESTAMP_INFO':
test-fsinfo.c:(.text+0x5d4): undefined reference to `pow'
/usr/bin/ld: test-fsinfo.c:(.text+0x618): undefined reference to `pow'
/usr/bin/ld: test-fsinfo.c:(.text+0x65c): undefined reference to `pow'
/usr/bin/ld: test-fsinfo.c:(.text+0x6a0): undefined reference to `pow'

Caused by commit

  90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem information")

interacting with commit

  8377bd2b9ee1 ("kbuild: Rename HOST_LOADLIBES to KBUILD_HOSTLDLIBS")

from the kbuild tree.

I have added the following merge fix patch for today:

From: Stephen Rothwell 
Date: Tue, 7 Aug 2018 11:01:32 +1000
Subject: [PATCH] vfs: samples: fix up for HOSTLOADLIBES rename

Signed-off-by: Stephen Rothwell 
---
 samples/statx/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/samples/statx/Makefile b/samples/statx/Makefile
index 05b4d30cdd3c..6a862bbc0627 100644
--- a/samples/statx/Makefile
+++ b/samples/statx/Makefile
@@ -7,6 +7,6 @@ always := $(hostprogs-y)
 HOSTCFLAGS_test-statx.o += -I$(objtree)/usr/include
 
 HOSTCFLAGS_test-fsinfo.o += -I$(objtree)/usr/include
-HOSTLOADLIBES_test-fsinfo += -lm
+HOSTLDLIBS_test-fsinfo += -lm
 
 HOSTCFLAGS_test-fs-query.o += -I$(objtree)/usr/include
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell


pgp_cmlOTOSr4.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

On Mon, 6 Aug 2018 22:24:01 +1000 Stephen Rothwell  
wrote:
>
> On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell  
> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such 
> > file or directory
> >  #include 
> >   ^~~~
> > 
> > Caused by commit
> > 
> >   90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem 
> > information")
> > 
> > I guess that headers_install (or whatever its called) has not bee run
> > before the sample code is built.
> > 
> > I have applied the following patch for today:
> > 
> > From: Stephen Rothwell 
> > Date: Mon, 6 Aug 2018 10:29:34 +1000
> > Subject: [PATCH] vfs: don;t build new sample programs yet
> > 
> > It seems that headers_install is not done before the samples
> > are build so some needed include files are not in the right place.
> > 
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  samples/statx/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/samples/statx/Makefile b/samples/statx/Makefile
> > index 05b4d30cdd3c..0b4d01822eca 100644
> > --- a/samples/statx/Makefile
> > +++ b/samples/statx/Makefile
> > @@ -1,5 +1,5 @@
> >  # List of programs to build
> > -hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
> > +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
> >  
> >  # Tell kbuild to always build the programs
> >  always := $(hostprogs-y)  
> 
> It turns out that commit
> 
>   ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")
> 
> removed the "depends on BROKEN" from CONFIG_SAMPLE_STATX and that
> breaks other builds (at least allyesconfig on s390).

I have added the following suggested patch (I am sorry I can't
find/remember who pointed me to this patch) for today (I guess that it
should be merged via the vfs tree as that is what is causing the build
failures ... in which case a real patch should be supplied with
appropriate SOB line).  This seems to fix the current problem.

From: Masahiro Yamada 
Date: Tue, 7 Aug 2018 10:33:43 +1000
Subject: [PATCH] Try to get the headers installed before we build the samples

Signed-off-by: Stephen Rothwell 
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 9e71826f67d7..d224d94c14be 100644
--- a/Makefile
+++ b/Makefile
@@ -1023,6 +1023,7 @@ endif
 # Build samples along the rest of the kernel
 ifdef CONFIG_SAMPLES
 vmlinux-dirs += samples
+samples: headers_install
 endif
 
 # The actual objects are generated when descending,
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell


pgpL_pp3DmTjt.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

On Mon, 6 Aug 2018 22:24:01 +1000 Stephen Rothwell  
wrote:
>
> On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell  
> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such 
> > file or directory
> >  #include 
> >   ^~~~
> > 
> > Caused by commit
> > 
> >   90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem 
> > information")
> > 
> > I guess that headers_install (or whatever its called) has not bee run
> > before the sample code is built.
> > 
> > I have applied the following patch for today:
> > 
> > From: Stephen Rothwell 
> > Date: Mon, 6 Aug 2018 10:29:34 +1000
> > Subject: [PATCH] vfs: don;t build new sample programs yet
> > 
> > It seems that headers_install is not done before the samples
> > are build so some needed include files are not in the right place.
> > 
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  samples/statx/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/samples/statx/Makefile b/samples/statx/Makefile
> > index 05b4d30cdd3c..0b4d01822eca 100644
> > --- a/samples/statx/Makefile
> > +++ b/samples/statx/Makefile
> > @@ -1,5 +1,5 @@
> >  # List of programs to build
> > -hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
> > +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
> >  
> >  # Tell kbuild to always build the programs
> >  always := $(hostprogs-y)  
> 
> It turns out that commit
> 
>   ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")
> 
> removed the "depends on BROKEN" from CONFIG_SAMPLE_STATX and that
> breaks other builds (at least allyesconfig on s390).

I have added the following suggested patch (I am sorry I can't
find/remember who pointed me to this patch) for today (I guess that it
should be merged via the vfs tree as that is what is causing the build
failures ... in which case a real patch should be supplied with
appropriate SOB line).  This seems to fix the current problem.

From: Masahiro Yamada 
Date: Tue, 7 Aug 2018 10:33:43 +1000
Subject: [PATCH] Try to get the headers installed before we build the samples

Signed-off-by: Stephen Rothwell 
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 9e71826f67d7..d224d94c14be 100644
--- a/Makefile
+++ b/Makefile
@@ -1023,6 +1023,7 @@ endif
 # Build samples along the rest of the kernel
 ifdef CONFIG_SAMPLES
 vmlinux-dirs += samples
+samples: headers_install
 endif
 
 # The actual objects are generated when descending,
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell


pgpL_pp3DmTjt.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell  
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such file 
> or directory
>  #include 
>   ^~~~
> 
> Caused by commit
> 
>   90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem information")
> 
> I guess that headers_install (or whatever its called) has not bee run
> before the sample code is built.
> 
> I have applied the following patch for today:
> 
> From: Stephen Rothwell 
> Date: Mon, 6 Aug 2018 10:29:34 +1000
> Subject: [PATCH] vfs: don;t build new sample programs yet
> 
> It seems that headers_install is not done before the samples
> are build so some needed include files are not in the right place.
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  samples/statx/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/samples/statx/Makefile b/samples/statx/Makefile
> index 05b4d30cdd3c..0b4d01822eca 100644
> --- a/samples/statx/Makefile
> +++ b/samples/statx/Makefile
> @@ -1,5 +1,5 @@
>  # List of programs to build
> -hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
> +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
>  
>  # Tell kbuild to always build the programs
>  always := $(hostprogs-y)

It turns out that commit

  ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")

removed the "depends on BROKEN" from CONFIG_SAMPLE_STATX and that
breaks other builds (at least allyesconfig on s390).

-- 
Cheers,
Stephen Rothwell


pgppJoM7PLodw.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell  
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such file 
> or directory
>  #include 
>   ^~~~
> 
> Caused by commit
> 
>   90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem information")
> 
> I guess that headers_install (or whatever its called) has not bee run
> before the sample code is built.
> 
> I have applied the following patch for today:
> 
> From: Stephen Rothwell 
> Date: Mon, 6 Aug 2018 10:29:34 +1000
> Subject: [PATCH] vfs: don;t build new sample programs yet
> 
> It seems that headers_install is not done before the samples
> are build so some needed include files are not in the right place.
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  samples/statx/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/samples/statx/Makefile b/samples/statx/Makefile
> index 05b4d30cdd3c..0b4d01822eca 100644
> --- a/samples/statx/Makefile
> +++ b/samples/statx/Makefile
> @@ -1,5 +1,5 @@
>  # List of programs to build
> -hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
> +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
>  
>  # Tell kbuild to always build the programs
>  always := $(hostprogs-y)

It turns out that commit

  ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")

removed the "depends on BROKEN" from CONFIG_SAMPLE_STATX and that
breaks other builds (at least allyesconfig on s390).

-- 
Cheers,
Stephen Rothwell


pgppJoM7PLodw.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such file or 
directory
 #include 
  ^~~~

Caused by commit

  90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem information")

I guess that headers_install (or whatever its called) has not bee run
before the sample code is built.

I have applied the following patch for today:

From: Stephen Rothwell 
Date: Mon, 6 Aug 2018 10:29:34 +1000
Subject: [PATCH] vfs: don;t build new sample programs yet

It seems that headers_install is not done before the samples
are build so some needed include files are not in the right place.

Signed-off-by: Stephen Rothwell 
---
 samples/statx/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/samples/statx/Makefile b/samples/statx/Makefile
index 05b4d30cdd3c..0b4d01822eca 100644
--- a/samples/statx/Makefile
+++ b/samples/statx/Makefile
@@ -1,5 +1,5 @@
 # List of programs to build
-hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
+hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell


pgpIbHCOHcEwU.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such file or 
directory
 #include 
  ^~~~

Caused by commit

  90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem information")

I guess that headers_install (or whatever its called) has not bee run
before the sample code is built.

I have applied the following patch for today:

From: Stephen Rothwell 
Date: Mon, 6 Aug 2018 10:29:34 +1000
Subject: [PATCH] vfs: don;t build new sample programs yet

It seems that headers_install is not done before the samples
are build so some needed include files are not in the right place.

Signed-off-by: Stephen Rothwell 
---
 samples/statx/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/samples/statx/Makefile b/samples/statx/Makefile
index 05b4d30cdd3c..0b4d01822eca 100644
--- a/samples/statx/Makefile
+++ b/samples/statx/Makefile
@@ -1,5 +1,5 @@
 # List of programs to build
-hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
+hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell


pgpIbHCOHcEwU.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/cxlflash/ocxl_hw.c:62:12: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
  .mount  = ocxlflash_fs_mount,
^~
drivers/scsi/cxlflash/ocxl_hw.c:62:12: note: (near initialization for 
'ocxlflash_fs_type.mount')

Caused by commit

  6eebfb42b5d6 ("vfs: Require specification of size of mount data for internal 
mounts")

interacting with commit

  926a62f9bd53 ("scsi: cxlflash: Support adapter file descriptors for OCXL")

from Linus' tree.

I have applide the following merge fix patch:

From: Stephen Rothwell 
Date: Tue, 19 Jun 2018 11:42:15 +1000
Subject: [PATCH] scsi: cxlflash: update for fs_type->mount API change

Signed-off-by: Stephen Rothwell 
---
 drivers/scsi/cxlflash/ocxl_hw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
index 0a95b5f25380..5ad1d5cfb0a8 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.c
+++ b/drivers/scsi/cxlflash/ocxl_hw.c
@@ -45,12 +45,13 @@ static const struct dentry_operations ocxlflash_fs_dops = {
  * @flags: Flags for the filesystem.
  * @dev_name:  Device name associated with the filesystem.
  * @data:  Data pointer.
+ * @data_size: Size of the mount data.
  *
  * Return: pointer to the directory entry structure
  */
 static struct dentry *ocxlflash_fs_mount(struct file_system_type *fs_type,
 int flags, const char *dev_name,
-void *data)
+void *data, size_t data_size)
 {
return mount_pseudo(fs_type, "ocxlflash:", NULL, _fs_dops,
OCXLFLASH_FS_MAGIC);
-- 
2.17.1

-- 
Cheers,
Stephen Rothwell


pgp0t6XNwik5t.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/cxlflash/ocxl_hw.c:62:12: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
  .mount  = ocxlflash_fs_mount,
^~
drivers/scsi/cxlflash/ocxl_hw.c:62:12: note: (near initialization for 
'ocxlflash_fs_type.mount')

Caused by commit

  6eebfb42b5d6 ("vfs: Require specification of size of mount data for internal 
mounts")

interacting with commit

  926a62f9bd53 ("scsi: cxlflash: Support adapter file descriptors for OCXL")

from Linus' tree.

I have applide the following merge fix patch:

From: Stephen Rothwell 
Date: Tue, 19 Jun 2018 11:42:15 +1000
Subject: [PATCH] scsi: cxlflash: update for fs_type->mount API change

Signed-off-by: Stephen Rothwell 
---
 drivers/scsi/cxlflash/ocxl_hw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
index 0a95b5f25380..5ad1d5cfb0a8 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.c
+++ b/drivers/scsi/cxlflash/ocxl_hw.c
@@ -45,12 +45,13 @@ static const struct dentry_operations ocxlflash_fs_dops = {
  * @flags: Flags for the filesystem.
  * @dev_name:  Device name associated with the filesystem.
  * @data:  Data pointer.
+ * @data_size: Size of the mount data.
  *
  * Return: pointer to the directory entry structure
  */
 static struct dentry *ocxlflash_fs_mount(struct file_system_type *fs_type,
 int flags, const char *dev_name,
-void *data)
+void *data, size_t data_size)
 {
return mount_pseudo(fs_type, "ocxlflash:", NULL, _fs_dops,
OCXLFLASH_FS_MAGIC);
-- 
2.17.1

-- 
Cheers,
Stephen Rothwell


pgp0t6XNwik5t.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Al,

On Sun, 8 Apr 2018 03:19:56 +0100 Al Viro  wrote:
>
> > > Caused by commit
> > > 
> > >   92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
> > > 
> > > I have reverted that commit for today.  
> > 
> > I am still doing that revert ...  
> 
> That's interesting, seeing that this commit is *not* in #for-next and
> 08fdc8a0138a should not have that problem...

I do the revert by applying a reverse patch (initially generated by a
"git revert").  That reverse patch still applies cleanly, so I have no
easy way to tell that this problem has been fixed (except by trying
without the reverse patch each day - which would add a significant cost
to my work as that patch touches linux/fs.h).

Anyway, thanks for letting me know, I will remove the reverse patch
from tomorrow.
-- 
Cheers,
Stephen Rothwell


pgpPDpY08iQ_Y.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Al,

On Sun, 8 Apr 2018 03:19:56 +0100 Al Viro  wrote:
>
> > > Caused by commit
> > > 
> > >   92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
> > > 
> > > I have reverted that commit for today.  
> > 
> > I am still doing that revert ...  
> 
> That's interesting, seeing that this commit is *not* in #for-next and
> 08fdc8a0138a should not have that problem...

I do the revert by applying a reverse patch (initially generated by a
"git revert").  That reverse patch still applies cleanly, so I have no
easy way to tell that this problem has been fixed (except by trying
without the reverse patch each day - which would add a significant cost
to my work as that patch touches linux/fs.h).

Anyway, thanks for letting me know, I will remove the reverse patch
from tomorrow.
-- 
Cheers,
Stephen Rothwell


pgpPDpY08iQ_Y.pgp
Description: OpenPGP digital signature

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

[Al Viro]

On Tue, Apr 03, 2018 at 12:26:29PM +1000, Stephen Rothwell wrote:
> Hi Al,
> 
> On Mon, 19 Mar 2018 17:06:27 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> > failed like this:
> > 
> > fs/super.c: In function 'do_thaw_all_callback':
> > fs/super.c:942:3: error: implicit declaration of function 
> > 'emergency_thaw_bdev'; did you mean 'emergency_remount'? 
> > [-Werror=implicit-function-declaration]
> >emergency_thaw_bdev(sb);
> >^~~
> >emergency_remount
> > 
> > Caused by commit
> > 
> >   92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
> > 
> > I have reverted that commit for today.
> 
> I am still doing that revert ...

That's interesting, seeing that this commit is *not* in #for-next and
08fdc8a0138a should not have that problem...

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

[Al Viro]

On Tue, Apr 03, 2018 at 12:26:29PM +1000, Stephen Rothwell wrote:
> Hi Al,
> 
> On Mon, 19 Mar 2018 17:06:27 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> > failed like this:
> > 
> > fs/super.c: In function 'do_thaw_all_callback':
> > fs/super.c:942:3: error: implicit declaration of function 
> > 'emergency_thaw_bdev'; did you mean 'emergency_remount'? 
> > [-Werror=implicit-function-declaration]
> >emergency_thaw_bdev(sb);
> >^~~
> >emergency_remount
> > 
> > Caused by commit
> > 
> >   92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
> > 
> > I have reverted that commit for today.
> 
> I am still doing that revert ...

That's interesting, seeing that this commit is *not* in #for-next and
08fdc8a0138a should not have that problem...

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

[Stephen Rothwell]

Hi Al,

On Mon, 19 Mar 2018 17:06:27 +1100 Stephen Rothwell  
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> fs/super.c: In function 'do_thaw_all_callback':
> fs/super.c:942:3: error: implicit declaration of function 
> 'emergency_thaw_bdev'; did you mean 'emergency_remount'? 
> [-Werror=implicit-function-declaration]
>emergency_thaw_bdev(sb);
>^~~
>emergency_remount
> 
> Caused by commit
> 
>   92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
> 
> I have reverted that commit for today.

I am still doing that revert ...

-- 
Cheers,
Stephen Rothwell


pgpWF3Hbjzbmz.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Al,

On Mon, 19 Mar 2018 17:06:27 +1100 Stephen Rothwell  
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> fs/super.c: In function 'do_thaw_all_callback':
> fs/super.c:942:3: error: implicit declaration of function 
> 'emergency_thaw_bdev'; did you mean 'emergency_remount'? 
> [-Werror=implicit-function-declaration]
>emergency_thaw_bdev(sb);
>^~~
>emergency_remount
> 
> Caused by commit
> 
>   92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
> 
> I have reverted that commit for today.

I am still doing that revert ...

-- 
Cheers,
Stephen Rothwell


pgpWF3Hbjzbmz.pgp
Description: OpenPGP digital signature

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

[Mateusz Guzik]

On Mon, Mar 19, 2018 at 05:06:27PM +1100, Stephen Rothwell wrote:
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> fs/super.c: In function 'do_thaw_all_callback':
> fs/super.c:942:3: error: implicit declaration of function 
> 'emergency_thaw_bdev'; did you mean 'emergency_remount'? 
> [-Werror=implicit-function-declaration]
>emergency_thaw_bdev(sb);
>^~~
>emergency_remount
> 
> Caused by commit
> 
>   92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
> 
> I have reverted that commit for today.
> 

Oops, did not test with CONFIG_BLOCK disabled. The sysrq func itself is guarded
with it so imho the right fixup is to do the same thing:

diff --git a/fs/super.c b/fs/super.c
index 5fa9a8d..86b5575 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -935,6 +935,7 @@ void emergency_remount(void)
}
 }
 
+#ifdef CONFIG_BLOCK
 static void do_thaw_all_callback(struct super_block *sb)
 {
down_write(>s_umount);
@@ -968,6 +969,7 @@ void emergency_thaw_all(void)
schedule_work(work);
}
 }
+#endif
 
 /*
  * Unnamed block devices are dummy devices used by virtual


-- 
Mateusz Guzik

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

[Mateusz Guzik]

On Mon, Mar 19, 2018 at 05:06:27PM +1100, Stephen Rothwell wrote:
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> fs/super.c: In function 'do_thaw_all_callback':
> fs/super.c:942:3: error: implicit declaration of function 
> 'emergency_thaw_bdev'; did you mean 'emergency_remount'? 
> [-Werror=implicit-function-declaration]
>emergency_thaw_bdev(sb);
>^~~
>emergency_remount
> 
> Caused by commit
> 
>   92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
> 
> I have reverted that commit for today.
> 

Oops, did not test with CONFIG_BLOCK disabled. The sysrq func itself is guarded
with it so imho the right fixup is to do the same thing:

diff --git a/fs/super.c b/fs/super.c
index 5fa9a8d..86b5575 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -935,6 +935,7 @@ void emergency_remount(void)
}
 }
 
+#ifdef CONFIG_BLOCK
 static void do_thaw_all_callback(struct super_block *sb)
 {
down_write(>s_umount);
@@ -968,6 +969,7 @@ void emergency_thaw_all(void)
schedule_work(work);
}
 }
+#endif
 
 /*
  * Unnamed block devices are dummy devices used by virtual


-- 
Mateusz Guzik

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
failed like this:

fs/super.c: In function 'do_thaw_all_callback':
fs/super.c:942:3: error: implicit declaration of function 
'emergency_thaw_bdev'; did you mean 'emergency_remount'? 
[-Werror=implicit-function-declaration]
   emergency_thaw_bdev(sb);
   ^~~
   emergency_remount

Caused by commit

  92afc556e622 ("buffer.c: call thaw_super during emergency thaw")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell


pgpymm7y1auZI.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
failed like this:

fs/super.c: In function 'do_thaw_all_callback':
fs/super.c:942:3: error: implicit declaration of function 
'emergency_thaw_bdev'; did you mean 'emergency_remount'? 
[-Werror=implicit-function-declaration]
   emergency_thaw_bdev(sb);
   ^~~
   emergency_remount

Caused by commit

  92afc556e622 ("buffer.c: call thaw_super during emergency thaw")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell


pgpymm7y1auZI.pgp
Description: OpenPGP digital signature

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/kvm/../../../virt/kvm/kvm_main.c: In function 'hva_to_pfn_slow':
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:1379:35: error: 'start' 
undeclared (first use in this function)
  npages = get_user_pages_unlocked(start, 1, , flags);
   ^

Caused by commit

  eeb7c213c804 ("kvm: switch get_user_page_nowait() to 
get_user_pages_unlocked()")

I have applied the following fix patch for today:

From e9cc05c8ba9b9f19c62b74e81e4beb67ec9fc09e Mon Sep 17 00:00:00 2001
From: Stephen Rothwell 
Date: Mon, 4 Dec 2017 10:13:38 +1100
Subject: [PATCH] kvm: fix for "switch get_user_page_nowait() to 
get_user_pages_unlocked()"

Signed-off-by: Stephen Rothwell 
---
 virt/kvm/kvm_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 4f0f0045e634..7b4d46432c85 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1376,7 +1376,7 @@ static int hva_to_pfn_slow(unsigned long addr, bool 
*async, bool write_fault,
if (async)
flags |= FOLL_NOWAIT;
 
-   npages = get_user_pages_unlocked(start, 1, , flags);
+   npages = get_user_pages_unlocked(addr, 1, , flags);
if (npages != 1)
return npages;
 
-- 
2.15.0

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/kvm/../../../virt/kvm/kvm_main.c: In function 'hva_to_pfn_slow':
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:1379:35: error: 'start' 
undeclared (first use in this function)
  npages = get_user_pages_unlocked(start, 1, , flags);
   ^

Caused by commit

  eeb7c213c804 ("kvm: switch get_user_page_nowait() to 
get_user_pages_unlocked()")

I have applied the following fix patch for today:

From e9cc05c8ba9b9f19c62b74e81e4beb67ec9fc09e Mon Sep 17 00:00:00 2001
From: Stephen Rothwell 
Date: Mon, 4 Dec 2017 10:13:38 +1100
Subject: [PATCH] kvm: fix for "switch get_user_page_nowait() to 
get_user_pages_unlocked()"

Signed-off-by: Stephen Rothwell 
---
 virt/kvm/kvm_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 4f0f0045e634..7b4d46432c85 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1376,7 +1376,7 @@ static int hva_to_pfn_slow(unsigned long addr, bool 
*async, bool write_fault,
if (async)
flags |= FOLL_NOWAIT;
 
-   npages = get_user_pages_unlocked(start, 1, , flags);
+   npages = get_user_pages_unlocked(addr, 1, , flags);
if (npages != 1)
return npages;
 
-- 
2.15.0

-- 
Cheers,
Stephen Rothwell

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

[David Howells]

Stephen Rothwell  wrote:

> - if (inode->i_mode & S_IALLUGO != 0775)
> + if ((inode->i_mode & S_IALLUGO) != 0775)

Acked-by: David Howells 

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

[David Howells]

Stephen Rothwell  wrote:

> - if (inode->i_mode & S_IALLUGO != 0775)
> + if ((inode->i_mode & S_IALLUGO) != 0775)

Acked-by: David Howells 

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_show_options':
arch/powerpc/platforms/cell/spufs/inode.c:619:20: error: suggest parentheses 
around comparison in operand of '&' [-Werror=parentheses]
  if (inode->i_mode & S_IALLUGO != 0775)
^
cc1: all warnings being treated as errors

Caused by commit

  86b1b993671d ("spufs: Implement show_options")

I applied the following patch:

From: Stephen Rothwell 
Date: Tue, 11 Jul 2017 10:44:55 +1000
Subject: [PATCH] spufs: always parenthesise bitwise expressions

arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_show_options':
arch/powerpc/platforms/cell/spufs/inode.c:619:20: error: suggest parentheses 
around comparison in operand of '&' [-Werror=parentheses]
  if (inode->i_mode & S_IALLUGO != 0775)
^

Fixes: 86b1b993671d "spufs: Implement show_options"
Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/platforms/cell/spufs/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/cell/spufs/inode.c 
b/arch/powerpc/platforms/cell/spufs/inode.c
index e210d69b..9558d725a99b 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -616,7 +616,7 @@ static int spufs_show_options(struct seq_file *m, struct 
dentry *root)
if (!gid_eq(inode->i_gid, GLOBAL_ROOT_GID))
seq_printf(m, ",gid=%u",
   from_kgid_munged(_user_ns, inode->i_gid));
-   if (inode->i_mode & S_IALLUGO != 0775)
+   if ((inode->i_mode & S_IALLUGO) != 0775)
seq_printf(m, ",mode=%o", inode->i_mode);
if (sbi->debug)
seq_puts(m, ",debug");
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_show_options':
arch/powerpc/platforms/cell/spufs/inode.c:619:20: error: suggest parentheses 
around comparison in operand of '&' [-Werror=parentheses]
  if (inode->i_mode & S_IALLUGO != 0775)
^
cc1: all warnings being treated as errors

Caused by commit

  86b1b993671d ("spufs: Implement show_options")

I applied the following patch:

From: Stephen Rothwell 
Date: Tue, 11 Jul 2017 10:44:55 +1000
Subject: [PATCH] spufs: always parenthesise bitwise expressions

arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_show_options':
arch/powerpc/platforms/cell/spufs/inode.c:619:20: error: suggest parentheses 
around comparison in operand of '&' [-Werror=parentheses]
  if (inode->i_mode & S_IALLUGO != 0775)
^

Fixes: 86b1b993671d "spufs: Implement show_options"
Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/platforms/cell/spufs/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/cell/spufs/inode.c 
b/arch/powerpc/platforms/cell/spufs/inode.c
index e210d69b..9558d725a99b 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -616,7 +616,7 @@ static int spufs_show_options(struct seq_file *m, struct 
dentry *root)
if (!gid_eq(inode->i_gid, GLOBAL_ROOT_GID))
seq_printf(m, ",gid=%u",
   from_kgid_munged(_user_ns, inode->i_gid));
-   if (inode->i_mode & S_IALLUGO != 0775)
+   if ((inode->i_mode & S_IALLUGO) != 0775)
seq_printf(m, ",mode=%o", inode->i_mode);
if (sbi->debug)
seq_puts(m, ",debug");
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell

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

[Al Viro]

On Mon, Jul 10, 2017 at 12:15:11PM +1000, Stephen Rothwell wrote:
> Hi Al,

> Caused by commit
> 
>   4f9365d9e2e7 ("spufs: Implement show_options")

Obvious incremental follows, will fold and push

diff --git a/arch/powerpc/platforms/cell/spufs/inode.c 
b/arch/powerpc/platforms/cell/spufs/inode.c
index 27a51a60bc33..e210d69b 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -608,15 +608,16 @@ static const match_table_t spufs_tokens = {
 static int spufs_show_options(struct seq_file *m, struct dentry *root)
 {
struct spufs_sb_info *sbi = spufs_get_sb_info(root->d_sb);
+   struct inode *inode = root->d_inode;
 
-   if (!uid_eq(root->i_uid, GLOBAL_ROOT_UID))
+   if (!uid_eq(inode->i_uid, GLOBAL_ROOT_UID))
seq_printf(m, ",uid=%u",
-  from_kuid_munged(_user_ns, root->i_uid));
-   if (!gid_eq(root->i_gid, GLOBAL_ROOT_GID))
+  from_kuid_munged(_user_ns, inode->i_uid));
+   if (!gid_eq(inode->i_gid, GLOBAL_ROOT_GID))
seq_printf(m, ",gid=%u",
-  from_kgid_munged(_user_ns, root->i_gid));
-   if (root->i_mode & S_IALLUGO != 0775)
-   seq_printf(m, ",mode=%o", root->i_mode);
+  from_kgid_munged(_user_ns, inode->i_gid));
+   if (inode->i_mode & S_IALLUGO != 0775)
+   seq_printf(m, ",mode=%o", inode->i_mode);
if (sbi->debug)
seq_puts(m, ",debug");
return 0;

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

[Al Viro]

On Mon, Jul 10, 2017 at 12:15:11PM +1000, Stephen Rothwell wrote:
> Hi Al,

> Caused by commit
> 
>   4f9365d9e2e7 ("spufs: Implement show_options")

Obvious incremental follows, will fold and push

diff --git a/arch/powerpc/platforms/cell/spufs/inode.c 
b/arch/powerpc/platforms/cell/spufs/inode.c
index 27a51a60bc33..e210d69b 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -608,15 +608,16 @@ static const match_table_t spufs_tokens = {
 static int spufs_show_options(struct seq_file *m, struct dentry *root)
 {
struct spufs_sb_info *sbi = spufs_get_sb_info(root->d_sb);
+   struct inode *inode = root->d_inode;
 
-   if (!uid_eq(root->i_uid, GLOBAL_ROOT_UID))
+   if (!uid_eq(inode->i_uid, GLOBAL_ROOT_UID))
seq_printf(m, ",uid=%u",
-  from_kuid_munged(_user_ns, root->i_uid));
-   if (!gid_eq(root->i_gid, GLOBAL_ROOT_GID))
+  from_kuid_munged(_user_ns, inode->i_uid));
+   if (!gid_eq(inode->i_gid, GLOBAL_ROOT_GID))
seq_printf(m, ",gid=%u",
-  from_kgid_munged(_user_ns, root->i_gid));
-   if (root->i_mode & S_IALLUGO != 0775)
-   seq_printf(m, ",mode=%o", root->i_mode);
+  from_kgid_munged(_user_ns, inode->i_gid));
+   if (inode->i_mode & S_IALLUGO != 0775)
+   seq_printf(m, ",mode=%o", inode->i_mode);
if (sbi->debug)
seq_puts(m, ",debug");
return 0;

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_show_options':
arch/powerpc/platforms/cell/spufs/inode.c:612:18: error: 'struct dentry' has no 
member named 'i_uid'
  if (!uid_eq(root->i_uid, GLOBAL_ROOT_UID))
  ^
arch/powerpc/platforms/cell/spufs/inode.c:614:43: error: 'struct dentry' has no 
member named 'i_uid'
   from_kuid_munged(_user_ns, root->i_uid));
   ^
arch/powerpc/platforms/cell/spufs/inode.c:615:18: error: 'struct dentry' has no 
member named 'i_gid'
  if (!gid_eq(root->i_gid, GLOBAL_ROOT_GID))
  ^
arch/powerpc/platforms/cell/spufs/inode.c:617:43: error: 'struct dentry' has no 
member named 'i_gid'
   from_kgid_munged(_user_ns, root->i_gid));
   ^
arch/powerpc/platforms/cell/spufs/inode.c:618:10: error: 'struct dentry' has no 
member named 'i_mode'
  if (root->i_mode & S_IALLUGO != 0775)
  ^
arch/powerpc/platforms/cell/spufs/inode.c:619:33: error: 'struct dentry' has no 
member named 'i_mode'
   seq_printf(m, ",mode=%o", root->i_mode);
 ^

Caused by commit

  4f9365d9e2e7 ("spufs: Implement show_options")

A bit hard to revert this, so I added the below patch for now ... please
fix it up.

Also, isn't this a bit late for this merge window?

From: Stephen Rothwell 
Date: Mon, 10 Jul 2017 11:05:31 +1000
Subject: [PATCH] disable the spufs show options for now

Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/platforms/cell/spufs/inode.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/platforms/cell/spufs/inode.c 
b/arch/powerpc/platforms/cell/spufs/inode.c
index 27a51a60bc33..fafbf88326d8 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -609,6 +609,7 @@ static int spufs_show_options(struct seq_file *m, struct 
dentry *root)
 {
struct spufs_sb_info *sbi = spufs_get_sb_info(root->d_sb);
 
+#if 0
if (!uid_eq(root->i_uid, GLOBAL_ROOT_UID))
seq_printf(m, ",uid=%u",
   from_kuid_munged(_user_ns, root->i_uid));
@@ -617,6 +618,7 @@ static int spufs_show_options(struct seq_file *m, struct 
dentry *root)
   from_kgid_munged(_user_ns, root->i_gid));
if (root->i_mode & S_IALLUGO != 0775)
seq_printf(m, ",mode=%o", root->i_mode);
+#endif
if (sbi->debug)
seq_puts(m, ",debug");
return 0;
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_show_options':
arch/powerpc/platforms/cell/spufs/inode.c:612:18: error: 'struct dentry' has no 
member named 'i_uid'
  if (!uid_eq(root->i_uid, GLOBAL_ROOT_UID))
  ^
arch/powerpc/platforms/cell/spufs/inode.c:614:43: error: 'struct dentry' has no 
member named 'i_uid'
   from_kuid_munged(_user_ns, root->i_uid));
   ^
arch/powerpc/platforms/cell/spufs/inode.c:615:18: error: 'struct dentry' has no 
member named 'i_gid'
  if (!gid_eq(root->i_gid, GLOBAL_ROOT_GID))
  ^
arch/powerpc/platforms/cell/spufs/inode.c:617:43: error: 'struct dentry' has no 
member named 'i_gid'
   from_kgid_munged(_user_ns, root->i_gid));
   ^
arch/powerpc/platforms/cell/spufs/inode.c:618:10: error: 'struct dentry' has no 
member named 'i_mode'
  if (root->i_mode & S_IALLUGO != 0775)
  ^
arch/powerpc/platforms/cell/spufs/inode.c:619:33: error: 'struct dentry' has no 
member named 'i_mode'
   seq_printf(m, ",mode=%o", root->i_mode);
 ^

Caused by commit

  4f9365d9e2e7 ("spufs: Implement show_options")

A bit hard to revert this, so I added the below patch for now ... please
fix it up.

Also, isn't this a bit late for this merge window?

From: Stephen Rothwell 
Date: Mon, 10 Jul 2017 11:05:31 +1000
Subject: [PATCH] disable the spufs show options for now

Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/platforms/cell/spufs/inode.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/platforms/cell/spufs/inode.c 
b/arch/powerpc/platforms/cell/spufs/inode.c
index 27a51a60bc33..fafbf88326d8 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -609,6 +609,7 @@ static int spufs_show_options(struct seq_file *m, struct 
dentry *root)
 {
struct spufs_sb_info *sbi = spufs_get_sb_info(root->d_sb);
 
+#if 0
if (!uid_eq(root->i_uid, GLOBAL_ROOT_UID))
seq_printf(m, ",uid=%u",
   from_kuid_munged(_user_ns, root->i_uid));
@@ -617,6 +618,7 @@ static int spufs_show_options(struct seq_file *m, struct 
dentry *root)
   from_kgid_munged(_user_ns, root->i_gid));
if (root->i_mode & S_IALLUGO != 0775)
seq_printf(m, ",mode=%o", root->i_mode);
+#endif
if (sbi->debug)
seq_puts(m, ",debug");
return 0;
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell

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

[David Howells]

Stephen Rothwell  wrote:

> From: Stephen Rothwell 
> Date: Mon, 27 Feb 2017 11:21:47 +1100
> Subject: [PATCH] statx: disable the sample code for now
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  samples/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/samples/Kconfig b/samples/Kconfig
> index e1fc9a6a96fa..9cb63188d3ef 100644
> --- a/samples/Kconfig
> +++ b/samples/Kconfig
> @@ -114,6 +114,7 @@ config SAMPLE_VFIO_MDEV_MTTY
>  
>  config SAMPLE_STATX
>   bool "Build example extended-stat using code"
> + depends on BROKEN
>   help
> Build example userspace program to use the new extended-stat syscall.
>  

It turns out that the statx sample depends on the header installation phase of
the build.  I'm not sure how to encode that fact in the Makefile, so marking
it broken for now is fine.

Acked-by: David Howells