linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: build failure after merge of the vfs tree
@ 2011-12-20  0:31 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2011-12-20  0:31 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

Hi Al,

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

In file included from ipc/util.c:28:0:
include/linux/security.h: In function 'security_real_capable':
include/linux/security.h:1885:2: error: implicit declaration of function '__task_cred' [-Werror=implicit-function-declaration]
include/linux/security.h:1885:2: warning: passing argument 2 of 'cap_capable' makes pointer from integer without a cast [enabled by default]
include/linux/security.h:69:12: note: expected 'const struct cred *' but argument is of type 'int'
include/linux/security.h: In function 'security_real_capable_noaudit':
include/linux/security.h:1897:11: warning: passing argument 2 of 'cap_capable' makes pointer from integer without a cast [enabled by default]
include/linux/security.h:69:12: note: expected 'const struct cred *' but argument is of type 'int'
In file included from kernel/groups.c:7:0:

So security.h needs to include linux/cred.h ...

include/linux/security.h: In function 'security_real_capable':
include/linux/security.h:1885:25: error: dereferencing pointer to incomplete type
include/linux/security.h:1885:25: error: dereferencing pointer to incomplete type
include/linux/security.h:1885:25: error: dereferencing pointer to incomplete type
include/linux/security.h:1885:25: error: dereferencing pointer to incomplete type
include/linux/security.h:1885:25: error: dereferencing pointer to incomplete type

And linux/cred.h needs to include linux/sched.h :-(

Caused by commit ae1a442f9d95 ("trim security.h").

I have used the vfs tree form next-20111216 again today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2021-01-04 22:36 Stephen Rothwell
@ 2021-01-04 23:28 ` Al Viro
  0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2021-01-04 23:28 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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, &t->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, &t->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 ;-/

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2021-01-04 22:36 Stephen Rothwell
  2021-01-04 23:28 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2021-01-04 22:36 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

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, &t->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, &t->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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-11-10 19:00   ` Al Viro
@ 2020-11-10 21:24     ` Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2020-11-10 21:24 UTC (permalink / raw)
  To: Al Viro
  Cc: David S. Miller, Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

Hi Al,

On Tue, 10 Nov 2020 19:00:36 +0000 Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Tue, Oct 27, 2020 at 04:59:12AM +0000, 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-10-27  4:59 ` Al Viro
@ 2020-11-10 19:00   ` Al Viro
  2020-11-10 21:24     ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Al Viro @ 2020-11-10 19:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David S. Miller, Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Oct 27, 2020 at 04:59:12AM +0000, 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 ;-/

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-10-27  4:14 Stephen Rothwell
@ 2020-10-27  4:59 ` Al Viro
  2020-11-10 19:00   ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Al Viro @ 2020-10-27  4:59 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David S. Miller, Linux Kernel Mailing List, Linux Next Mailing List

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

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2020-10-27  4:14 Stephen Rothwell
  2020-10-27  4:59 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2020-10-27  4:14 UTC (permalink / raw)
  To: Al Viro, David S. Miller
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]

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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-10-06 21:04           ` Stephen Rothwell
@ 2020-10-07 15:46             ` Josh Poimboeuf
  0 siblings, 0 replies; 132+ messages in thread
From: Josh Poimboeuf @ 2020-10-07 15:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Linux Next Mailing List, Linux Kernel Mailing List,
	Peter Zijlstra (Intel),
	Thomas Gleixner, Borislav Petkov

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 <jpoimboe@redhat.com> 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


^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-10-06 14:30         ` Josh Poimboeuf
@ 2020-10-06 21:04           ` Stephen Rothwell
  2020-10-07 15:46             ` Josh Poimboeuf
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2020-10-06 21:04 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Al Viro, Linux Next Mailing List, Linux Kernel Mailing List,
	Peter Zijlstra (Intel),
	Thomas Gleixner, Borislav Petkov

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

Hi Josh,

On Tue, 6 Oct 2020 09:30:12 -0500 Josh Poimboeuf <jpoimboe@redhat.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-09-29  4:10       ` Josh Poimboeuf
@ 2020-10-06 14:30         ` Josh Poimboeuf
  2020-10-06 21:04           ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Josh Poimboeuf @ 2020-10-06 14:30 UTC (permalink / raw)
  To: Al Viro
  Cc: Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Peter Zijlstra (Intel),
	Thomas Gleixner, Borislav Petkov

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


^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-09-25 13:38     ` Al Viro
@ 2020-09-29  4:10       ` Josh Poimboeuf
  2020-10-06 14:30         ` Josh Poimboeuf
  0 siblings, 1 reply; 132+ messages in thread
From: Josh Poimboeuf @ 2020-09-29  4:10 UTC (permalink / raw)
  To: Al Viro
  Cc: Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Peter Zijlstra (Intel),
	Thomas Gleixner, Borislav Petkov

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;
 }


^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-09-28  1:31 Stephen Rothwell
@ 2020-09-28  6:05 ` Christoph Hellwig
  0 siblings, 0 replies; 132+ messages in thread
From: Christoph Hellwig @ 2020-09-28  6:05 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Christoph Hellwig, Linux Next Mailing List,
	Linux Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2020-09-28  1:31 Stephen Rothwell
  2020-09-28  6:05 ` Christoph Hellwig
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2020-09-28  1:31 UTC (permalink / raw)
  To: Al Viro
  Cc: Christoph Hellwig, Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 17442 bytes --]

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, &uiov[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, &uiov[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, &uiov[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, &uiov[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, &uiov[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, &uiov[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, &uiov[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, &uiov[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, &uiov[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, &uiov[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, &uiov[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, &uiov[i].iov_len, uaccess_end);
      |   ^~~~~~~~~~~~~~~
lib/iov_iter.c:1666:29: error: invalid use of undefined type 'struct compat_iovec'
 1666 |   unsafe_get_user(buf, &uiov[i].iov_base, 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:1666:3: note: in expansion of macro 'unsafe_get_user'
 1666 |   unsafe_get_user(buf, &uiov[i].iov_base, uaccess_end);
      |   ^~~~~~~~~~~~~~~
lib/iov_iter.c:1666:32: error: invalid use of undefined type 'const struct compat_iovec'
 1666 |   unsafe_get_user(buf, &uiov[i].iov_base, 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:1666:3: note: in expansion of macro 'unsafe_get_user'
 1666 |   unsafe_get_user(buf, &uiov[i].iov_base, uaccess_end);
      |   ^~~~~~~~~~~~~~~
lib/iov_iter.c:1666:29: error: invalid use of undefined type 'struct compat_iovec'
 1666 |   unsafe_get_user(buf, &uiov[i].iov_base, 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:1666:3: note: in expansion of macro 'unsafe_get_user'
 1666 |   unsafe_get_user(buf, &uiov[i].iov_base, uaccess_end);
      |   ^~~~~~~~~~~~~~~
lib/iov_iter.c:1666:32: error: invalid use of undefined type 'const struct compat_iovec'
 1666 |   unsafe_get_user(buf, &uiov[i].iov_base, 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:1666:3: note: in expansion of macro 'unsafe_get_user'
 1666 |   unsafe_get_user(buf, &uiov[i].iov_base, uaccess_end);
      |   ^~~~~~~~~~~~~~~
lib/iov_iter.c:1666:29: error: invalid use of undefined type 'struct compat_iovec'
 1666 |   unsafe_get_user(buf, &uiov[i].iov_base, 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:1666:3: note: in expansion of macro 'unsafe_get_user'
 1666 |   unsafe_get_user(buf, &uiov[i].iov_base, uaccess_end);
      |   ^~~~~~~~~~~~~~~
lib/iov_iter.c:1666:32: error: invalid use of undefined type 'const struct compat_iovec'
 1666 |   unsafe_get_user(buf, &uiov[i].iov_base, 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:1666:3: note: in expansion of macro 'unsafe_get_user'
 1666 |   unsafe_get_user(buf, &uiov[i].iov_base, uaccess_end);
      |   ^~~~~~~~~~~~~~~

Caused by commit

  99dc3a9dd6ca ("iov_iter: refactor rw_copy_check_uvector and import_iovec")

CONFIG_COMAPT is not set for this build ...

I have added the following hack patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 28 Sep 2020 11:25:57 +1000
Subject: [PATCH] iov_iter: fix build when CONFIG_COMPAT is not set

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 lib/iov_iter.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 8a8e25f8e3e8..5892f4c40291 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -1648,6 +1648,7 @@ const void *dup_iter(struct iov_iter *new, struct iov_iter *old, gfp_t flags)
 }
 EXPORT_SYMBOL(dup_iter);
 
+#ifdef CONFIG_COMPAT
 static int copy_compat_iovec_from_user(struct iovec *iov,
 		const struct iovec __user *uvec, unsigned long nr_segs)
 {
@@ -1679,7 +1680,8 @@ static int copy_compat_iovec_from_user(struct iovec *iov,
 	user_access_end();
 	return ret;
 }
-		
+#endif /* CONFIG_COMPAT */
+
 static int copy_iovec_from_user(struct iovec *iov,
 		const struct iovec __user *uvec, unsigned long nr_segs)
 {
@@ -1717,9 +1719,11 @@ struct iovec *iovec_from_user(const struct iovec __user *uvec,
 			return ERR_PTR(-ENOMEM);
 	}
 
+#ifdef CONFIG_COMPAT
 	if (compat)
 		ret = copy_compat_iovec_from_user(iov, uvec, nr_segs);
 	else
+#endif
 		ret = copy_iovec_from_user(iov, uvec, nr_segs);
 	if (ret) {
 		if (iov != fast_iov)
-- 
2.28.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-09-25 12:01   ` Stephen Rothwell
@ 2020-09-25 13:38     ` Al Viro
  2020-09-29  4:10       ` Josh Poimboeuf
  0 siblings, 1 reply; 132+ messages in thread
From: Al Viro @ 2020-09-25 13:38 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Josh Poimboeuf, Linux Next Mailing List,
	Linux Kernel Mailing List, Peter Zijlstra (Intel),
	Thomas Gleixner, Borislav Petkov

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

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-09-24 20:08 ` Al Viro
@ 2020-09-25 12:01   ` Stephen Rothwell
  2020-09-25 13:38     ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2020-09-25 12:01 UTC (permalink / raw)
  To: Al Viro
  Cc: Josh Poimboeuf, Linux Next Mailing List,
	Linux Kernel Mailing List, Peter Zijlstra (Intel),
	Thomas Gleixner, Borislav Petkov

[-- Attachment #1: Type: text/plain, Size: 4707 bytes --]

Hi Al,

On Thu, 24 Sep 2020 21:08:07 +0100 Al Viro <viro@zeniv.linux.org.uk> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-09-24  8:30 Stephen Rothwell
@ 2020-09-24 20:08 ` Al Viro
  2020-09-25 12:01   ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Al Viro @ 2020-09-24 20:08 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Josh Poimboeuf, Linux Next Mailing List,
	Linux Kernel Mailing List, Peter Zijlstra (Intel),
	Thomas Gleixner, Borislav Petkov

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
    <spec_ref2>` 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 <linux/compiler.h>
 #include <linux/fault-inject-usercopy.h>
 #include <linux/kasan-checks.h>
+#include <linux/nospec.h>
 #include <linux/string.h>
 #include <asm/asm.h>
 #include <asm/page.h>
@@ -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 pointer such that it becomes NULL if it's not a valid user
+ * pointer.  This prevents speculative dereferences of user-controlled pointers
+ * to kernel space when access_ok() speculatively returns true.  This should be
+ * done *after* access_ok(), to avoid affecting error handling behavior.
+ */
+#define force_user_ptr(ptr)						\
+	(typeof(ptr)) array_index_nospec((__force unsigned long)ptr,	\
+					 TASK_SIZE_MAX)
+
+
+/*
  * These are the main single-value transfer routines.  They automatically
  * use the right size if we just have the right pointer type.
  *
@@ -96,11 +108,6 @@ extern int __get_user_bad(void);
 
 #define __uaccess_begin() stac()
 #define __uaccess_end()   clac()
-#define __uaccess_begin_nospec()	\
-({					\
-	stac();				\
-	barrier_nospec();		\
-})
 
 /*
  * This is the smallest unsigned integer type that can fit a value
@@ -343,7 +350,7 @@ do {									\
 	__label__ __pu_label;					\
 	int __pu_err = -EFAULT;					\
 	__typeof__(*(ptr)) __pu_val = (x);			\
-	__typeof__(ptr) __pu_ptr = (ptr);			\
+	__typeof__(ptr) __pu_ptr = force_user_ptr(ptr);	\
 	__typeof__(size) __pu_size = (size);			\
 	__uaccess_begin();					\
 	__put_user_size(__pu_val, __pu_ptr, __pu_size, __pu_label);	\
@@ -357,9 +364,9 @@ __pu_label:							\
 ({									\
 	int __gu_err;							\
 	__inttype(*(ptr)) __gu_val;					\
-	__typeof__(ptr) __gu_ptr = (ptr);				\
+	__typeof__(ptr) __gu_ptr = force_user_ptr(ptr);		\
 	__typeof__(size) __gu_size = (size);				\
-	__uaccess_begin_nospec();					\
+	__uaccess_begin();						\
 	__get_user_size(__gu_val, __gu_ptr, __gu_size, __gu_err);	\
 	__uaccess_end();						\
 	(x) = (__force __typeof__(*(ptr)))__gu_val;			\
@@ -489,7 +496,7 @@ static __must_check __always_inline bool user_access_begin(const void __user *pt
 {
 	if (unlikely(!access_ok(ptr,len)))
 		return 0;
-	__uaccess_begin_nospec();
+	__uaccess_begin();
 	return 1;
 }
 #define user_access_begin(a,b)	user_access_begin(a,b)
@@ -498,14 +505,16 @@ static __must_check __always_inline bool user_access_begin(const void __user *pt
 #define user_access_save()	smap_save()
 #define user_access_restore(x)	smap_restore(x)
 
-#define unsafe_put_user(x, ptr, label)	\
-	__put_user_size((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)), label)
+#define unsafe_put_user(x, ptr, label)						\
+	__put_user_size((__typeof__(*(ptr)))(x), force_user_ptr(ptr),		\
+			sizeof(*(ptr)), label)
 
 #define unsafe_get_user(x, ptr, err_label)					\
 do {										\
 	int __gu_err;								\
 	__inttype(*(ptr)) __gu_val;						\
-	__get_user_size(__gu_val, (ptr), sizeof(*(ptr)), __gu_err);		\
+	__get_user_size(__gu_val, force_user_ptr(ptr), sizeof(*(ptr)),	\
+			__gu_err);						\
 	(x) = (__force __typeof__(*(ptr)))__gu_val;				\
 	if (unlikely(__gu_err)) goto err_label;					\
 } while (0)
diff --git a/arch/x86/include/asm/uaccess_64.h b/arch/x86/include/asm/uaccess_64.h
index e7265a552f4f..425ffbb2a737 100644
--- a/arch/x86/include/asm/uaccess_64.h
+++ b/arch/x86/include/asm/uaccess_64.h
@@ -49,20 +49,20 @@ copy_user_generic(void *to, const void *from, unsigned len)
 static __always_inline __must_check unsigned long
 raw_copy_from_user(void *dst, const void __user *src, unsigned long size)
 {
-	return copy_user_generic(dst, (__force void *)src, size);
+	return copy_user_generic(dst, (__force void *)force_user_ptr(src), size);
 }
 
 static __always_inline __must_check unsigned long
 raw_copy_to_user(void __user *dst, const void *src, unsigned long size)
 {
-	return copy_user_generic((__force void *)dst, src, size);
+	return copy_user_generic((__force void *)force_user_ptr(dst), src, size);
 }
 
 static __always_inline __must_check
 unsigned long raw_copy_in_user(void __user *dst, const void __user *src, unsigned long size)
 {
-	return copy_user_generic((__force void *)dst,
-				 (__force void *)src, size);
+	return copy_user_generic((__force void *)force_user_ptr(dst),
+				 (__force void *)force_user_ptr(src), size);
 }
 
 extern long __copy_user_nocache(void *dst, const void __user *src,
@@ -77,13 +77,13 @@ __copy_from_user_inatomic_nocache(void *dst, const void __user *src,
 				  unsigned size)
 {
 	kasan_check_write(dst, size);
-	return __copy_user_nocache(dst, src, size, 0);
+	return __copy_user_nocache(dst, force_user_ptr(src), size, 0);
 }
 
 static inline int
 __copy_from_user_flushcache(void *dst, const void __user *src, unsigned size)
 {
 	kasan_check_write(dst, size);
-	return __copy_user_flushcache(dst, src, size);
+	return __copy_user_flushcache(dst, force_user_ptr(src), size);
 }
 #endif /* _ASM_X86_UACCESS_64_H */
diff --git a/arch/x86/lib/csum-wrappers_64.c b/arch/x86/lib/csum-wrappers_64.c
index 189344924a2b..8872f2233491 100644
--- a/arch/x86/lib/csum-wrappers_64.c
+++ b/arch/x86/lib/csum-wrappers_64.c
@@ -28,7 +28,8 @@ csum_and_copy_from_user(const void __user *src, void *dst, int len)
 	might_sleep();
 	if (!user_access_begin(src, len))
 		return 0;
-	sum = csum_partial_copy_generic((__force const void *)src, dst, len);
+	sum = csum_partial_copy_generic((__force const void *)force_user_ptr(src),
+					dst, len);
 	user_access_end();
 	return sum;
 }
@@ -53,7 +54,7 @@ csum_and_copy_to_user(const void *src, void __user *dst, int len)
 	might_sleep();
 	if (!user_access_begin(dst, len))
 		return 0;
-	sum = csum_partial_copy_generic(src, (void __force *)dst, len);
+	sum = csum_partial_copy_generic(src, (void __force *)force_user_ptr(dst), len);
 	user_access_end();
 	return sum;
 }
diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S
index 2f052bc96866..5a95ed6a0a36 100644
--- a/arch/x86/lib/getuser.S
+++ b/arch/x86/lib/getuser.S
@@ -49,7 +49,7 @@ SYM_FUNC_START(__get_user_1)
 	LOAD_TASK_SIZE_MINUS_N(0)
 	cmp %_ASM_DX,%_ASM_AX
 	jae bad_get_user
-	sbb %_ASM_DX, %_ASM_DX		/* array_index_mask_nospec() */
+	sbb %_ASM_DX, %_ASM_DX		/* force_user_ptr() */
 	and %_ASM_DX, %_ASM_AX
 	ASM_STAC
 1:	movzbl (%_ASM_AX),%edx
@@ -63,7 +63,7 @@ SYM_FUNC_START(__get_user_2)
 	LOAD_TASK_SIZE_MINUS_N(1)
 	cmp %_ASM_DX,%_ASM_AX
 	jae bad_get_user
-	sbb %_ASM_DX, %_ASM_DX		/* array_index_mask_nospec() */
+	sbb %_ASM_DX, %_ASM_DX		/* force_user_ptr() */
 	and %_ASM_DX, %_ASM_AX
 	ASM_STAC
 2:	movzwl (%_ASM_AX),%edx
@@ -77,7 +77,7 @@ SYM_FUNC_START(__get_user_4)
 	LOAD_TASK_SIZE_MINUS_N(3)
 	cmp %_ASM_DX,%_ASM_AX
 	jae bad_get_user
-	sbb %_ASM_DX, %_ASM_DX		/* array_index_mask_nospec() */
+	sbb %_ASM_DX, %_ASM_DX		/* force_user_ptr() */
 	and %_ASM_DX, %_ASM_AX
 	ASM_STAC
 3:	movl (%_ASM_AX),%edx
@@ -92,7 +92,7 @@ SYM_FUNC_START(__get_user_8)
 	LOAD_TASK_SIZE_MINUS_N(7)
 	cmp %_ASM_DX,%_ASM_AX
 	jae bad_get_user
-	sbb %_ASM_DX, %_ASM_DX		/* array_index_mask_nospec() */
+	sbb %_ASM_DX, %_ASM_DX		/* force_user_ptr() */
 	and %_ASM_DX, %_ASM_AX
 	ASM_STAC
 4:	movq (%_ASM_AX),%rdx
@@ -103,7 +103,7 @@ SYM_FUNC_START(__get_user_8)
 	LOAD_TASK_SIZE_MINUS_N(7)
 	cmp %_ASM_DX,%_ASM_AX
 	jae bad_get_user_8
-	sbb %_ASM_DX, %_ASM_DX		/* array_index_mask_nospec() */
+	sbb %_ASM_DX, %_ASM_DX		/* force_user_ptr() */
 	and %_ASM_DX, %_ASM_AX
 	ASM_STAC
 4:	movl (%_ASM_AX),%edx
diff --git a/arch/x86/lib/putuser.S b/arch/x86/lib/putuser.S
index 358239d77dff..3db4e263fcfb 100644
--- a/arch/x86/lib/putuser.S
+++ b/arch/x86/lib/putuser.S
@@ -45,6 +45,8 @@ SYM_FUNC_START(__put_user_1)
 	LOAD_TASK_SIZE_MINUS_N(0)
 	cmp %_ASM_BX,%_ASM_CX
 	jae .Lbad_put_user
+	sbb %_ASM_BX, %_ASM_BX		/* force_user_ptr() */
+	and %_ASM_BX, %_ASM_CX
 	ASM_STAC
 1:	movb %al,(%_ASM_CX)
 	xor %eax,%eax
@@ -57,6 +59,8 @@ SYM_FUNC_START(__put_user_2)
 	LOAD_TASK_SIZE_MINUS_N(1)
 	cmp %_ASM_BX,%_ASM_CX
 	jae .Lbad_put_user
+	sbb %_ASM_BX, %_ASM_BX		/* force_user_ptr() */
+	and %_ASM_BX, %_ASM_CX
 	ASM_STAC
 2:	movw %ax,(%_ASM_CX)
 	xor %eax,%eax
@@ -69,6 +73,8 @@ SYM_FUNC_START(__put_user_4)
 	LOAD_TASK_SIZE_MINUS_N(3)
 	cmp %_ASM_BX,%_ASM_CX
 	jae .Lbad_put_user
+	sbb %_ASM_BX, %_ASM_BX		/* force_user_ptr() */
+	and %_ASM_BX, %_ASM_CX
 	ASM_STAC
 3:	movl %eax,(%_ASM_CX)
 	xor %eax,%eax
@@ -81,6 +87,8 @@ SYM_FUNC_START(__put_user_8)
 	LOAD_TASK_SIZE_MINUS_N(7)
 	cmp %_ASM_BX,%_ASM_CX
 	jae .Lbad_put_user
+	sbb %_ASM_BX, %_ASM_BX		/* force_user_ptr() */
+	and %_ASM_BX, %_ASM_CX
 	ASM_STAC
 4:	mov %_ASM_AX,(%_ASM_CX)
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/lib/usercopy_32.c b/arch/x86/lib/usercopy_32.c
index 7d290777246d..1ac802c9e685 100644
--- a/arch/x86/lib/usercopy_32.c
+++ b/arch/x86/lib/usercopy_32.c
@@ -68,7 +68,7 @@ clear_user(void __user *to, unsigned long n)
 {
 	might_fault();
 	if (access_ok(to, n))
-		__do_clear_user(to, n);
+		__do_clear_user(force_user_ptr(to), n);
 	return n;
 }
 EXPORT_SYMBOL(clear_user);
@@ -331,7 +331,7 @@ do {									\
 
 unsigned long __copy_user_ll(void *to, const void *from, unsigned long n)
 {
-	__uaccess_begin_nospec();
+	__uaccess_begin();
 	if (movsl_is_ok(to, from, n))
 		__copy_user(to, from, n);
 	else
@@ -344,7 +344,7 @@ EXPORT_SYMBOL(__copy_user_ll);
 unsigned long __copy_from_user_ll_nocache_nozero(void *to, const void __user *from,
 					unsigned long n)
 {
-	__uaccess_begin_nospec();
+	__uaccess_begin();
 #ifdef CONFIG_X86_INTEL_USERCOPY
 	if (n > 64 && static_cpu_has(X86_FEATURE_XMM2))
 		n = __copy_user_intel_nocache(to, from, n);
diff --git a/arch/x86/lib/usercopy_64.c b/arch/x86/lib/usercopy_64.c
index 5617b3864586..8aa5ea7150fb 100644
--- a/arch/x86/lib/usercopy_64.c
+++ b/arch/x86/lib/usercopy_64.c
@@ -43,7 +43,8 @@ unsigned long __clear_user(void __user *addr, unsigned long size)
 		_ASM_EXTABLE_UA(0b, 3b)
 		_ASM_EXTABLE_UA(1b, 2b)
 		: [size8] "=&c"(size), [dst] "=&D" (__d0)
-		: [size1] "r"(size & 7), "[size8]" (size / 8), "[dst]"(addr));
+		: [size1] "r"(size & 7), "[size8]" (size / 8),
+		  "[dst]" (force_user_ptr(addr)));
 	clac();
 	return size;
 }
@@ -54,7 +55,7 @@ unsigned long clear_user(void __user *to, unsigned long n)
 	if (should_fail_usercopy())
 		return n;
 	if (access_ok(to, n))
-		return __clear_user(to, n);
+		return __clear_user(force_user_ptr(to), n);
 	return n;
 }
 EXPORT_SYMBOL(clear_user);
@@ -90,7 +91,7 @@ EXPORT_SYMBOL_GPL(arch_wb_cache_pmem);
 long __copy_user_flushcache(void *dst, const void __user *src, unsigned size)
 {
 	unsigned long flushed, dest = (unsigned long) dst;
-	long rc = __copy_user_nocache(dst, src, size, 0);
+	long rc = __copy_user_nocache(dst, force_user_ptr(src), size, 0);
 
 	/*
 	 * __copy_user_nocache() uses non-temporal stores for the bulk
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);
 	}
 	return n;
 }
diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c
index e6d5fcc2cdf3..99e80110d2c0 100644
--- a/lib/strncpy_from_user.c
+++ b/lib/strncpy_from_user.c
@@ -25,7 +25,7 @@
  * hit it), 'max' is the address space maximum (and we return
  * -EFAULT if we hit it).
  */
-static inline long do_strncpy_from_user(char *dst, const char __user *src,
+static __always_inline long do_strncpy_from_user(char *dst, const char __user *src,
 					unsigned long count, unsigned long max)
 {
 	const struct word_at_a_time constants = WORD_AT_A_TIME_CONSTANTS;
diff --git a/lib/strnlen_user.c b/lib/strnlen_user.c
index 1616710b8a82..bd79d6e0535d 100644
--- a/lib/strnlen_user.c
+++ b/lib/strnlen_user.c
@@ -20,7 +20,8 @@
  * if it fits in a aligned 'long'. The caller needs to check
  * the return value against "> max".
  */
-static inline long do_strnlen_user(const char __user *src, unsigned long count, unsigned long max)
+static __always_inline long do_strnlen_user(const char __user *src,
+				unsigned long count, unsigned long max)
 {
 	const struct word_at_a_time constants = WORD_AT_A_TIME_CONSTANTS;
 	unsigned long align, res = 0;

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2020-09-24  8:30 Stephen Rothwell
  2020-09-24 20:08 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2020-09-24  8:30 UTC (permalink / raw)
  To: Al Viro
  Cc: Josh Poimboeuf, Linux Next Mailing List,
	Linux Kernel Mailing List, Peter Zijlstra (Intel),
	Thomas Gleixner, Borislav Petkov

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-07-29  6:33 ` Christoph Hellwig
@ 2020-07-29 19:19   ` Al Viro
  0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2020-07-29 19:19 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-07-29  1:56 Stephen Rothwell
@ 2020-07-29  6:33 ` Christoph Hellwig
  2020-07-29 19:19   ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Christoph Hellwig @ 2020-07-29  6:33 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Linux Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig

Thanks,

I've sent out a fixed version.

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2020-07-29  1:56 Stephen Rothwell
  2020-07-29  6:33 ` Christoph Hellwig
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2020-07-29  1:56 UTC (permalink / raw)
  To: Al Viro
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Christoph Hellwig

[-- Attachment #1: Type: text/plain, Size: 35884 bytes --]

Hi all,

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

In file included from <command-line>:
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)
      |  ^~~~~~~~~~~~~~~~
arch/x86/kernel/signal_compat.c:76:2: note: in expansion of macro 'BUILD_BUG_ON'
   76 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_uid) != 0x10);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1001' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_tid) != 0x0C
  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:85:2: note: in expansion of macro 'BUILD_BUG_ON'
   85 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_tid)     != 0x0C);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1002' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_overrun) != 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)
      |  ^~~~~~~~~~~~~~~~
arch/x86/kernel/signal_compat.c:86:2: note: in expansion of macro 'BUILD_BUG_ON'
   86 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_overrun) != 0x10);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1003' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_value) != 0x14
  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:87:2: note: in expansion of macro 'BUILD_BUG_ON'
   87 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_value)   != 0x14);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1010' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_pid) != 0x0C
  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:96:2: note: in expansion of macro 'BUILD_BUG_ON'
   96 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_pid)   != 0x0C);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1011' 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)
      |  ^~~~~~~~~~~~~~~~
arch/x86/kernel/signal_compat.c:97:2: note: in expansion of macro 'BUILD_BUG_ON'
   97 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_uid)   != 0x10);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1012' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_value) != 0x14
  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:98:2: note: in expansion of macro 'BUILD_BUG_ON'
   98 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_value) != 0x14);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1021' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_pid) != 0x0C
  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:109:2: note: in expansion of macro 'BUILD_BUG_ON'
  109 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_pid)    != 0x0C);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1022' 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)
      |  ^~~~~~~~~~~~~~~~
arch/x86/kernel/signal_compat.c:110:2: note: in expansion of macro 'BUILD_BUG_ON'
  110 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_uid)    != 0x10);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1023' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_status) != 0x14
  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:111:2: note: in expansion of macro 'BUILD_BUG_ON'
  111 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_status) != 0x14);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1024' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_utime) != 0x18
  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:112:2: note: in expansion of macro 'BUILD_BUG_ON'
  112 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_utime)  != 0x18);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1025' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_stime) != 0x1C
  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:113:2: note: in expansion of macro 'BUILD_BUG_ON'
  113 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_stime)  != 0x1C);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1027' declared with attribute error: BUILD_BUG_ON failed: 7*sizeof(int) != sizeof(((compat_siginfo_t *)0)->_sifields._sigchld_x32)
  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:66:36: note: in expansion of macro 'BUILD_BUG_ON'
   66 | #define CHECK_CSI_SIZE(name, size) BUILD_BUG_ON(size != sizeof(((compat_siginfo_t *)0)->_sifields.name))
      |                                    ^~~~~~~~~~~~
arch/x86/kernel/signal_compat.c:117:2: note: in expansion of macro 'CHECK_CSI_SIZE'
  117 |  CHECK_CSI_SIZE  (_sigchld_x32, 7*sizeof(int));
      |  ^~~~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1028' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, _sifields._sigchld_x32._utime) != 0x18
  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:119:2: note: in expansion of macro 'BUILD_BUG_ON'
  119 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, _sifields._sigchld_x32._utime)  != 0x18);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1029' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, _sifields._sigchld_x32._stime) != 0x20
  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:120:2: note: in expansion of macro 'BUILD_BUG_ON'
  120 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, _sifields._sigchld_x32._stime)  != 0x20);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1034' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_addr) != 0x0C
  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:128:2: note: in expansion of macro 'BUILD_BUG_ON'
  128 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_addr) != 0x0C);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1036' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_addr_lsb) != 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)
      |  ^~~~~~~~~~~~~~~~
arch/x86/kernel/signal_compat.c:131:2: note: in expansion of macro 'BUILD_BUG_ON'
  131 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_addr_lsb) != 0x10);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1039' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_lower) != 0x14
  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:135:2: note: in expansion of macro 'BUILD_BUG_ON'
  135 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_lower) != 0x14);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1040' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_upper) != 0x18
  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:136:2: note: in expansion of macro 'BUILD_BUG_ON'
  136 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_upper) != 0x18);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1042' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_pkey) != 0x14
  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:139:2: note: in expansion of macro 'BUILD_BUG_ON'
  139 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_pkey) != 0x14);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1048' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_band) != 0x0C
  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:147:2: note: in expansion of macro 'BUILD_BUG_ON'
  147 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_band) != 0x0C);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1049' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_fd) != 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)
      |  ^~~~~~~~~~~~~~~~
arch/x86/kernel/signal_compat.c:148:2: note: in expansion of macro 'BUILD_BUG_ON'
  148 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_fd)   != 0x10);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1056' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_call_addr) != 0x0C
  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:157:2: note: in expansion of macro 'BUILD_BUG_ON'
  157 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_call_addr) != 0x0C);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1057' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_syscall) != 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)
      |  ^~~~~~~~~~~~~~~~
arch/x86/kernel/signal_compat.c:158:2: note: in expansion of macro 'BUILD_BUG_ON'
  158 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_syscall)   != 0x10);
      |  ^~~~~~~~~~~~
include/linux/compiler_types.h:313:38: error: call to '__compiletime_assert_1058' declared with attribute error: BUILD_BUG_ON failed: offsetof(compat_siginfo_t, si_arch) != 0x14
  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:159:2: note: in expansion of macro 'BUILD_BUG_ON'
  159 |  BUILD_BUG_ON(offsetof(compat_siginfo_t, si_arch)      != 0x14);
      |  ^~~~~~~~~~~~
kernel/trace/blktrace.c: In function 'blk_trace_ioctl':
kernel/trace/blktrace.c:741:2: error: duplicate case value
  741 |  case BLKTRACESETUP32:
      |  ^~~~
kernel/trace/blktrace.c:736:2: note: previously used here
  736 |  case BLKTRACESETUP:
      |  ^~~~

Caused by commit

  1ef5f0ad8784 ("compat: lift compat_s64 and compat_u64 to <linux/compat.h>")

Missing CONFIG_ prefix on COMPAT_FOR_U64_ALIGNMENT in include/linux/compat.h.

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

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2020-07-27 12:06 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2020-07-27 12:06 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

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(&pos, &count, &kbuf, &ubuf,
  ^~~
  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 <sfr@canb.auug.org.au>
Date: Mon, 27 Jul 2020 21:59:23 +1000
Subject: [PATCH] sparc32: declare ret

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-05-07  2:35 ` Al Viro
@ 2020-05-07 15:07   ` Jens Axboe
  0 siblings, 0 replies; 132+ messages in thread
From: Jens Axboe @ 2020-05-07 15:07 UTC (permalink / raw)
  To: Al Viro, Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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(&ucnt, 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


^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-05-07  0:39 Stephen Rothwell
@ 2020-05-07  2:35 ` Al Viro
  2020-05-07 15:07   ` Jens Axboe
  0 siblings, 1 reply; 132+ messages in thread
From: Al Viro @ 2020-05-07  2:35 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jens Axboe

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(&ucnt, 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

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2020-05-07  0:39 Stephen Rothwell
  2020-05-07  2:35 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2020-05-07  0:39 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jens Axboe

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

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(&ucnt, 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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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 <linux/proc_fs.h>
 #include <linux/seq_file.h>
 #include <linux/idr.h>
+#include <linux/uio.h>
 
 DEFINE_PER_CPU(int, eventfd_wake_count);
 
-- 
2.26.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-01-24  2:41 ` Stephen Rothwell
@ 2020-01-29 22:40   ` Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2020-01-29 22:40 UTC (permalink / raw)
  To: Al Viro
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Carlos Maiolino

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

Hi all,

On Fri, 24 Jan 2020 13:41:24 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> On Fri, 10 Jan 2020 17:57:29 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> > failed like this:
> > 
> > fs/inode.c:1615:5: error: redefinition of 'bmap'
> >  1615 | int bmap(struct inode *inode, sector_t *block)
> >       |     ^~~~
> > In file included from fs/inode.c:7:
> > include/linux/fs.h:2867:19: note: previous definition of 'bmap' was here
> >  2867 | static inline int bmap(struct inode *inode,  sector_t *block)
> >       |                   ^~~~
> > 
> > Caused by commit
> > 
> >   65a805fdd75f ("fibmap: Use bmap instead of ->bmap method in ioctl_fibmap")
> > 
> > I have added this patch for today:
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Fri, 10 Jan 2020 17:53:19 +1100
> > Subject: [PATCH] fs: fix up for !CONFIG_BLOCK and bmap
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  fs/inode.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/fs/inode.c b/fs/inode.c
> > index 9f894b25af2b..590f36daa006 100644
> > --- a/fs/inode.c
> > +++ b/fs/inode.c
> > @@ -1598,6 +1598,7 @@ void iput(struct inode *inode)
> >  }
> >  EXPORT_SYMBOL(iput);
> >  
> > +#ifdef CONFIG_BLOCK
> >  /**
> >   *	bmap	- find a block number in a file
> >   *	@inode:  inode owning the block number being requested
> > @@ -1621,6 +1622,7 @@ int bmap(struct inode *inode, sector_t *block)
> >  	return 0;
> >  }
> >  EXPORT_SYMBOL(bmap);
> > +#endif
> >  
> >  /*
> >   * With relative atime, only update atime if the previous atime is
> > -- 
> > 2.24.0  
> 
> I am still applying this patch each day ...

Ping?

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-01-10  6:57 Stephen Rothwell
  2020-01-10 10:00 ` Carlos Maiolino
  2020-01-10 11:03 ` Carlos Maiolino
@ 2020-01-24  2:41 ` Stephen Rothwell
  2020-01-29 22:40   ` Stephen Rothwell
  2 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2020-01-24  2:41 UTC (permalink / raw)
  To: Al Viro
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Carlos Maiolino

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]

Hi all,

On Fri, 10 Jan 2020 17:57:29 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> fs/inode.c:1615:5: error: redefinition of 'bmap'
>  1615 | int bmap(struct inode *inode, sector_t *block)
>       |     ^~~~
> In file included from fs/inode.c:7:
> include/linux/fs.h:2867:19: note: previous definition of 'bmap' was here
>  2867 | static inline int bmap(struct inode *inode,  sector_t *block)
>       |                   ^~~~
> 
> Caused by commit
> 
>   65a805fdd75f ("fibmap: Use bmap instead of ->bmap method in ioctl_fibmap")
> 
> I have added this patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 10 Jan 2020 17:53:19 +1100
> Subject: [PATCH] fs: fix up for !CONFIG_BLOCK and bmap
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/inode.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index 9f894b25af2b..590f36daa006 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1598,6 +1598,7 @@ void iput(struct inode *inode)
>  }
>  EXPORT_SYMBOL(iput);
>  
> +#ifdef CONFIG_BLOCK
>  /**
>   *	bmap	- find a block number in a file
>   *	@inode:  inode owning the block number being requested
> @@ -1621,6 +1622,7 @@ int bmap(struct inode *inode, sector_t *block)
>  	return 0;
>  }
>  EXPORT_SYMBOL(bmap);
> +#endif
>  
>  /*
>   * With relative atime, only update atime if the previous atime is
> -- 
> 2.24.0

I am still applying this patch each day ...
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-01-10 22:44   ` Stephen Rothwell
@ 2020-01-13  9:28     ` Carlos Maiolino
  0 siblings, 0 replies; 132+ messages in thread
From: Carlos Maiolino @ 2020-01-13  9:28 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Linux Next Mailing List, Linux Kernel Mailing List

On Sat, Jan 11, 2020 at 09:44:27AM +1100, Stephen Rothwell wrote:
> Hi Carlos,
> 
> On Fri, 10 Jan 2020 12:03:53 +0100 Carlos Maiolino <cmaiolino@redhat.com> wrote:
> >
> > Eitherway, I am not 100% sure this is the right fix for this case, I remember
> > some bmap() users who didn't need CONFIG_BLOCK, so we may still need to export
> > it without CONFIG_BLOCK.
> > Can you please send me your configuration?
> 
> It was a x86_64 allnoconfig build.

Thanks for the info Stephen.

I think the correct way to fix this though, is to wrap the whole bmap(){}
definition in a #ifdef block, not only the EXPORT symbol, as, by my patches, we
redefine bmap() as an inline symbol if CONFIG_BLOCK is not set. So, something
like this:


diff --git a/fs/inode.c b/fs/inode.c
index 9f894b25af2b..21e58542801b 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1612,6 +1612,8 @@ EXPORT_SYMBOL(iput);
  *	Returns -EINVAL in case of error, 0 otherwise. If mapping falls into a
  *	hole, returns 0 and *block is also set to 0.
  */
+
+#ifdef CONFIG_BLOCK
 int bmap(struct inode *inode, sector_t *block)
 {
 	if (!inode->i_mapping->a_ops->bmap)
@@ -1621,6 +1623,7 @@ int bmap(struct inode *inode, sector_t *block)
 	return 0;
 }
 EXPORT_SYMBOL(bmap);
+#endif
 
 /*
  * With relative atime, only update atime if the previous atime is

So, we preserve the original inline definition in include/fs.h (making bmap()
just returning -EINVAL). What do you think?

Viro, mind to share your opinion? I can send a 'Fixes:' patch.

Cheers



-- 
Carlos


^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-01-10 11:03 ` Carlos Maiolino
@ 2020-01-10 22:44   ` Stephen Rothwell
  2020-01-13  9:28     ` Carlos Maiolino
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2020-01-10 22:44 UTC (permalink / raw)
  To: Carlos Maiolino
  Cc: Al Viro, Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

Hi Carlos,

On Fri, 10 Jan 2020 12:03:53 +0100 Carlos Maiolino <cmaiolino@redhat.com> wrote:
>
> Eitherway, I am not 100% sure this is the right fix for this case, I remember
> some bmap() users who didn't need CONFIG_BLOCK, so we may still need to export
> it without CONFIG_BLOCK.
> Can you please send me your configuration?

It was a x86_64 allnoconfig build.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-01-10  6:57 Stephen Rothwell
  2020-01-10 10:00 ` Carlos Maiolino
@ 2020-01-10 11:03 ` Carlos Maiolino
  2020-01-10 22:44   ` Stephen Rothwell
  2020-01-24  2:41 ` Stephen Rothwell
  2 siblings, 1 reply; 132+ messages in thread
From: Carlos Maiolino @ 2020-01-10 11:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Linux Next Mailing List, Linux Kernel Mailing List

On Fri, Jan 10, 2020 at 05:57:29PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> fs/inode.c:1615:5: error: redefinition of 'bmap'
>  1615 | int bmap(struct inode *inode, sector_t *block)
>       |     ^~~~
> In file included from fs/inode.c:7:
> include/linux/fs.h:2867:19: note: previous definition of 'bmap' was here
>  2867 | static inline int bmap(struct inode *inode,  sector_t *block)
>       |                   ^~~~
> 

Oh, no, that's not the same issue I thought, and the patch applied does have the
dummy function.

/me grabs more coffee...


> ---
>  fs/inode.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index 9f894b25af2b..590f36daa006 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1598,6 +1598,7 @@ void iput(struct inode *inode)
>  }
>  EXPORT_SYMBOL(iput);
>  
> +#ifdef CONFIG_BLOCK
>  /**
>   *	bmap	- find a block number in a file
>   *	@inode:  inode owning the block number being requested
> @@ -1621,6 +1622,7 @@ int bmap(struct inode *inode, sector_t *block)
>  	return 0;
>  }
>  EXPORT_SYMBOL(bmap);
> +#endif

Eitherway, I am not 100% sure this is the right fix for this case, I remember
some bmap() users who didn't need CONFIG_BLOCK, so we may still need to export
it without CONFIG_BLOCK.
Can you please send me your configuration?

Thanks.





>  
>  /*
>   * With relative atime, only update atime if the previous atime is
> -- 
> 2.24.0
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
Carlos


^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2020-01-10  6:57 Stephen Rothwell
@ 2020-01-10 10:00 ` Carlos Maiolino
  2020-01-10 11:03 ` Carlos Maiolino
  2020-01-24  2:41 ` Stephen Rothwell
  2 siblings, 0 replies; 132+ messages in thread
From: Carlos Maiolino @ 2020-01-10 10:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Linux Next Mailing List, Linux Kernel Mailing List

Meh...

On Fri, Jan 10, 2020 at 05:57:29PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
> 
> fs/inode.c:1615:5: error: redefinition of 'bmap'
>  1615 | int bmap(struct inode *inode, sector_t *block)
>       |     ^~~~
> In file included from fs/inode.c:7:
> include/linux/fs.h:2867:19: note: previous definition of 'bmap' was here
>  2867 | static inline int bmap(struct inode *inode,  sector_t *block)
>       |                   ^~~~
> 
> Caused by commit
> 
>   65a805fdd75f ("fibmap: Use bmap instead of ->bmap method in ioctl_fibmap")
> 
> I have added this patch for today:

I had a fix to it, in one of my previous patches but I forgot to add it to this
version.

> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 10 Jan 2020 17:53:19 +1100
> Subject: [PATCH] fs: fix up for !CONFIG_BLOCK and bmap
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/inode.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index 9f894b25af2b..590f36daa006 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1598,6 +1598,7 @@ void iput(struct inode *inode)
>  }
>  EXPORT_SYMBOL(iput);
>  
> +#ifdef CONFIG_BLOCK
>  /**
>   *	bmap	- find a block number in a file
>   *	@inode:  inode owning the block number being requested
> @@ -1621,6 +1622,7 @@ int bmap(struct inode *inode, sector_t *block)
>  	return 0;
>  }
>  EXPORT_SYMBOL(bmap);
> +#endif

The problem with this fix, is the fact bmap() could still be called for some
users even withouth CONFIG_BLOCK, so, it needs to have a dummy function to
return -EINVAL in case CONFIG_BLOCK is disabled.

I'll send a patch to fix it. Thanks for spotting it Stephen.

>  
>  /*
>   * With relative atime, only update atime if the previous atime is
> -- 
> 2.24.0
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
Carlos


^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2020-01-10  6:57 Stephen Rothwell
  2020-01-10 10:00 ` Carlos Maiolino
                   ` (2 more replies)
  0 siblings, 3 replies; 132+ messages in thread
From: Stephen Rothwell @ 2020-01-10  6:57 UTC (permalink / raw)
  To: Al Viro
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Carlos Maiolino

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]

Hi all,

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

fs/inode.c:1615:5: error: redefinition of 'bmap'
 1615 | int bmap(struct inode *inode, sector_t *block)
      |     ^~~~
In file included from fs/inode.c:7:
include/linux/fs.h:2867:19: note: previous definition of 'bmap' was here
 2867 | static inline int bmap(struct inode *inode,  sector_t *block)
      |                   ^~~~

Caused by commit

  65a805fdd75f ("fibmap: Use bmap instead of ->bmap method in ioctl_fibmap")

I have added this patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 10 Jan 2020 17:53:19 +1100
Subject: [PATCH] fs: fix up for !CONFIG_BLOCK and bmap

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/inode.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/inode.c b/fs/inode.c
index 9f894b25af2b..590f36daa006 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1598,6 +1598,7 @@ void iput(struct inode *inode)
 }
 EXPORT_SYMBOL(iput);
 
+#ifdef CONFIG_BLOCK
 /**
  *	bmap	- find a block number in a file
  *	@inode:  inode owning the block number being requested
@@ -1621,6 +1622,7 @@ int bmap(struct inode *inode, sector_t *block)
 	return 0;
 }
 EXPORT_SYMBOL(bmap);
+#endif
 
 /*
  * With relative atime, only update atime if the previous atime is
-- 
2.24.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2019-01-02  4:01 Stephen Rothwell
@ 2019-01-30  3:45 ` Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2019-01-30  3:45 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux Next Mailing List, Linux Kernel Mailing List, David Howells

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

Hi all,

On Wed, 2 Jan 2019 15:01:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au>
> 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 <sfr@canb.auug.org.au>
> ---
>  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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2019-01-02  4:01 Stephen Rothwell
  2019-01-30  3:45 ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2019-01-02  4:01 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux Next Mailing List, Linux Kernel Mailing List, David Howells

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-10-29  9:21   ` David Howells
@ 2018-10-29 10:29     ` Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-10-29 10:29 UTC (permalink / raw)
  To: David Howells; +Cc: Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

Hi David,

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

Yep, that fixes the build for me, thanks.

Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-10-29  4:33 ` Stephen Rothwell
  2018-10-29  9:07   ` Stephen Rothwell
@ 2018-10-29  9:21   ` David Howells
  2018-10-29 10:29     ` Stephen Rothwell
  1 sibling, 1 reply; 132+ messages in thread
From: David Howells @ 2018-10-29  9:21 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: dhowells, Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List

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 <linux/socket.h>
 #include <sys/stat.h>
 
+#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 <sys/stat.h>
 #include <arpa/inet.h>
 
+#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- 0	0x00000000-000000ff */
 			;
 
-		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;

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-10-29  4:33 ` Stephen Rothwell
@ 2018-10-29  9:07   ` Stephen Rothwell
  2018-10-29  9:21   ` David Howells
  1 sibling, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-10-29  9:07 UTC (permalink / raw)
  To: David Howells; +Cc: Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]

Hi David,

On Mon, 29 Oct 2018 15:33:34 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-09-10  3:35 Stephen Rothwell
  2018-09-18 21:38 ` Stephen Rothwell
  2018-09-18 22:17 ` David Howells
@ 2018-10-29  4:33 ` Stephen Rothwell
  2018-10-29  9:07   ` Stephen Rothwell
  2018-10-29  9:21   ` David Howells
  2 siblings, 2 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-10-29  4:33 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Howells

[-- Attachment #1: Type: text/plain, Size: 6155 bytes --]

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 <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> samples/vfs/test-fsinfo.c: In function 'fsinfo':
> samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use in this function); did you mean 'fsinfo'?
>   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 patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 10 Sep 2018 13:19:20 +1000
> Subject: [PATCH] disable building the VFS sample programs
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  samples/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/samples/Kconfig b/samples/Kconfig
> index 0431af2589ac..c8823d9d97db 100644
> --- a/samples/Kconfig
> +++ b/samples/Kconfig
> @@ -148,6 +148,7 @@ config SAMPLE_VFIO_MDEV_MBOCHS
>  
>  config SAMPLE_VFS
>  	bool "Build example programs that use new VFS system calls"
> +	depends on BROKEN
>  	help
>  	  Build example userspace programs that use new VFS system calls such
>  	  as mount API and statx()

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-10-16 16:37   ` Jaegeuk Kim
@ 2018-10-16 20:45     ` Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-10-16 20:45 UTC (permalink / raw)
  To: Jaegeuk Kim
  Cc: Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List,
	David Howells, Daniel Rosenberg

[-- Attachment #1: Type: text/plain, Size: 207 bytes --]

Hi Jaegeuk,

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

Thanks for that.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-10-16  0:17 ` Stephen Rothwell
@ 2018-10-16 16:37   ` Jaegeuk Kim
  2018-10-16 20:45     ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Jaegeuk Kim @ 2018-10-16 16:37 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List,
	David Howells, Daniel Rosenberg

On 10/16, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 3 Oct 2018 10:32:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au>
> > Date: Wed, 3 Oct 2018 10:27:04 +1000
> > Subject: [PATCH] f2fs: update for MS_* flags mostly going away
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  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

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-10-03  0:32 Stephen Rothwell
@ 2018-10-16  0:17 ` Stephen Rothwell
  2018-10-16 16:37   ` Jaegeuk Kim
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2018-10-16  0:17 UTC (permalink / raw)
  To: Al Viro, Jaegeuk Kim
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	David Howells, Daniel Rosenberg

[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

Hi all,

On Wed, 3 Oct 2018 10:32:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au>
> Date: Wed, 3 Oct 2018 10:27:04 +1000
> Subject: [PATCH] f2fs: update for MS_* flags mostly going away
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2018-10-03  0:32 Stephen Rothwell
  2018-10-16  0:17 ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2018-10-03  0:32 UTC (permalink / raw)
  To: Al Viro, Jaegeuk Kim
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	David Howells, Daniel Rosenberg

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

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 <sfr@canb.auug.org.au>
Date: Wed, 3 Oct 2018 10:27:04 +1000
Subject: [PATCH] f2fs: update for MS_* flags mostly going away

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-09-19  6:31     ` Stephen Rothwell
  2018-09-20 10:48       ` Michael Ellerman
@ 2018-09-20 16:20       ` David Howells
  1 sibling, 0 replies; 132+ messages in thread
From: David Howells @ 2018-09-20 16:20 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: dhowells, Stephen Rothwell, Al Viro, Linux-Next Mailing List,
	Linux Kernel Mailing List

Michael Ellerman <mpe@ellerman.id.au> 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

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-09-19  6:31     ` Stephen Rothwell
@ 2018-09-20 10:48       ` Michael Ellerman
  2018-09-20 16:20       ` David Howells
  1 sibling, 0 replies; 132+ messages in thread
From: Michael Ellerman @ 2018-09-20 10:48 UTC (permalink / raw)
  To: Stephen Rothwell, David Howells
  Cc: Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List

Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi David,
>
> On Wed, 19 Sep 2018 07:01:00 +0100 David Howells <dhowells@redhat.com> wrote:
>>
>> Stephen Rothwell <sfr@canb.auug.org.au> 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

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-09-18 22:17 ` David Howells
  2018-09-18 23:49   ` Stephen Rothwell
  2018-09-19  6:01   ` David Howells
@ 2018-09-20 10:44   ` Michael Ellerman
  2 siblings, 0 replies; 132+ messages in thread
From: Michael Ellerman @ 2018-09-20 10:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: dhowells, Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List

David Howells <dhowells@redhat.com> writes:

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

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-09-18 23:49   ` Stephen Rothwell
@ 2018-09-19  7:17     ` Geert Uytterhoeven
  0 siblings, 0 replies; 132+ messages in thread
From: Geert Uytterhoeven @ 2018-09-19  7:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Howells, Al Viro, Linux-Next, Linux Kernel Mailing List

On Wed, Sep 19, 2018 at 1:50 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Tue, 18 Sep 2018 23:17:21 +0100 David Howells <dhowells@redhat.com> wrote:
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > After merging the vfs tree, today's linux-next build (powerpc
> > > > allyesconfig) failed like this:
> > > >
> > > > samples/vfs/test-fsinfo.c: In function 'fsinfo':
> > > > samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use in this function); did you mean 'fsinfo'?
> >
> > I think the problem is that I haven't allocated system call numbers for any
> > arches other than x86 - even the x86 syscall numbers are provisional until the
> > patchset is taken upstream.  I'm not sure of the best way to deal with this -
> > make the samples dependent on the X86 arch?
>
> But the sample programs are built with HOSTCC, so you can't depend on
> ARCH (since I, for one, am cross compiling).  Maybe SUBARCH.  Better
> would be to use either Kconfig's shell primitive or some make magic to
> figure out if the syscall number define's are defined.
>
> > > > samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long unsigned int'} [-Wformat=]
> > > >   printf("\tmax file size: %llx\n", f->max_file_size);
> >
> > Sigh.  On powerpc __u64 is unsigned long, but on x86_64 it's unsigned long
> > long.  Is it possible to shift all arches to use unsigned long long for __u64?
>
> I doubt it - that would probably cause more warnings in the arch code.

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 -- geert@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

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-09-19  6:01   ` David Howells
@ 2018-09-19  6:31     ` Stephen Rothwell
  2018-09-20 10:48       ` Michael Ellerman
  2018-09-20 16:20       ` David Howells
  0 siblings, 2 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-09-19  6:31 UTC (permalink / raw)
  To: David Howells; +Cc: Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

Hi David,

On Wed, 19 Sep 2018 07:01:00 +0100 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-09-18 22:17 ` David Howells
  2018-09-18 23:49   ` Stephen Rothwell
@ 2018-09-19  6:01   ` David Howells
  2018-09-19  6:31     ` Stephen Rothwell
  2018-09-20 10:44   ` Michael Ellerman
  2 siblings, 1 reply; 132+ messages in thread
From: David Howells @ 2018-09-19  6:01 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: dhowells, Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List

Stephen Rothwell <sfr@canb.auug.org.au> 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

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-09-18 22:17 ` David Howells
@ 2018-09-18 23:49   ` Stephen Rothwell
  2018-09-19  7:17     ` Geert Uytterhoeven
  2018-09-19  6:01   ` David Howells
  2018-09-20 10:44   ` Michael Ellerman
  2 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2018-09-18 23:49 UTC (permalink / raw)
  To: David Howells; +Cc: Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

Hi David,

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

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

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

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-09-10  3:35 Stephen Rothwell
  2018-09-18 21:38 ` Stephen Rothwell
@ 2018-09-18 22:17 ` David Howells
  2018-09-18 23:49   ` Stephen Rothwell
                     ` (2 more replies)
  2018-10-29  4:33 ` Stephen Rothwell
  2 siblings, 3 replies; 132+ messages in thread
From: David Howells @ 2018-09-18 22:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: dhowells, Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > After merging the vfs tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> > 
> > samples/vfs/test-fsinfo.c: In function 'fsinfo':
> > samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use in this function); did you mean 'fsinfo'?

I think the problem is that I haven't allocated system call numbers for any
arches other than x86 - even the x86 syscall numbers are provisional until the
patchset is taken upstream.  I'm not sure of the best way to deal with this -
make the samples dependent on the X86 arch?

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

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-09-10  3:35 Stephen Rothwell
@ 2018-09-18 21:38 ` Stephen Rothwell
  2018-09-18 22:17 ` David Howells
  2018-10-29  4:33 ` Stephen Rothwell
  2 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-09-18 21:38 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Howells

[-- Attachment #1: Type: text/plain, Size: 6181 bytes --]

Hi David, Al,

On Mon, 10 Sep 2018 13:35:25 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> samples/vfs/test-fsinfo.c: In function 'fsinfo':
> samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use in this function); did you mean 'fsinfo'?
>   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 patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 10 Sep 2018 13:19:20 +1000
> Subject: [PATCH] disable building the VFS sample programs
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  samples/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/samples/Kconfig b/samples/Kconfig
> index 0431af2589ac..c8823d9d97db 100644
> --- a/samples/Kconfig
> +++ b/samples/Kconfig
> @@ -148,6 +148,7 @@ config SAMPLE_VFIO_MDEV_MBOCHS
>  
>  config SAMPLE_VFS
>  	bool "Build example programs that use new VFS system calls"
> +	depends on BROKEN
>  	help
>  	  Build example userspace programs that use new VFS system calls such
>  	  as mount API and statx()

Can we have a permanent solution to this, please ... I am still
applying the above patch.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2018-09-10  3:59 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-09-10  3:59 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 11667 bytes --]

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)) & 0xffffffff)
                     ^
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)) & 0xffffffff)
                            ^
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)) & 0xffffffff)
                                          ^
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)) & 0xffffffff)
                     ^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
 #define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
                           ^~~~~~~~~~~~~~~~
fs/compat_ioctl.c:1189:1: note: in expansion of macro 'IGNORE_IOCTL'
 IGNORE_IOCTL(FBIOGCURPOS)
 ^~~~~~~~~~~~
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:114:25: note: in expansion of macro '_IOW'
 #define FBIOGCURPOS     _IOW('F', 27, struct fbcurpos)
                         ^~~~
fs/compat_ioctl.c:1189:14: note: in expansion of macro 'FBIOGCURPOS'
 IGNORE_IOCTL(FBIOGCURPOS)
              ^~~~~~~~~~~
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:28: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0xffffffff)
                            ^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
 #define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
                           ^~~~~~~~~~~~~~~~
fs/compat_ioctl.c:1189:1: note: in expansion of macro 'IGNORE_IOCTL'
 IGNORE_IOCTL(FBIOGCURPOS)
 ^~~~~~~~~~~~
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:114:25: note: in expansion of macro '_IOW'
 #define FBIOGCURPOS     _IOW('F', 27, struct fbcurpos)
                         ^~~~
fs/compat_ioctl.c:1189:14: note: in expansion of macro 'FBIOGCURPOS'
 IGNORE_IOCTL(FBIOGCURPOS)
              ^~~~~~~~~~~
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:42: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0xffffffff)
                                          ^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
 #define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
                           ^~~~~~~~~~~~~~~~
fs/compat_ioctl.c:1189:1: note: in expansion of macro 'IGNORE_IOCTL'
 IGNORE_IOCTL(FBIOGCURPOS)
 ^~~~~~~~~~~~
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:114:25: note: in expansion of macro '_IOW'
 #define FBIOGCURPOS     _IOW('F', 27, struct fbcurpos)
                         ^~~~
fs/compat_ioctl.c:1189:14: note: in expansion of macro 'FBIOGCURPOS'
 IGNORE_IOCTL(FBIOGCURPOS)
              ^~~~~~~~~~~
arch/sparc/include/uapi/asm/fbio.h:117:39: error: invalid application of 'sizeof' to incomplete type 'struct fbcurpos'
 #define FBIOGCURMAX     _IOR('F', 28, struct fbcurpos)
                                       ^
fs/compat_ioctl.c:640:21: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0xffffffff)
                     ^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
 #define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
                           ^~~~~~~~~~~~~~~~
fs/compat_ioctl.c:1190:1: note: in expansion of macro 'IGNORE_IOCTL'
 IGNORE_IOCTL(FBIOGCURMAX)
 ^~~~~~~~~~~~
arch/sparc/include/uapi/asm/ioctl.h:46:29: note: in expansion of macro '_IOC'
 #define _IOR(type,nr,size)  _IOC(_IOC_READ,(type),(nr),sizeof(size))
                             ^~~~
arch/sparc/include/uapi/asm/fbio.h:117:25: note: in expansion of macro '_IOR'
 #define FBIOGCURMAX     _IOR('F', 28, struct fbcurpos)
                         ^~~~
fs/compat_ioctl.c:1190:14: note: in expansion of macro 'FBIOGCURMAX'
 IGNORE_IOCTL(FBIOGCURMAX)
              ^~~~~~~~~~~
arch/sparc/include/uapi/asm/fbio.h:117:39: error: invalid application of 'sizeof' to incomplete type 'struct fbcurpos'
 #define FBIOGCURMAX     _IOR('F', 28, struct fbcurpos)
                                       ^
fs/compat_ioctl.c:640:28: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0xffffffff)
                            ^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
 #define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
                           ^~~~~~~~~~~~~~~~
fs/compat_ioctl.c:1190:1: note: in expansion of macro 'IGNORE_IOCTL'
 IGNORE_IOCTL(FBIOGCURMAX)
 ^~~~~~~~~~~~
arch/sparc/include/uapi/asm/ioctl.h:46:29: note: in expansion of macro '_IOC'
 #define _IOR(type,nr,size)  _IOC(_IOC_READ,(type),(nr),sizeof(size))
                             ^~~~
arch/sparc/include/uapi/asm/fbio.h:117:25: note: in expansion of macro '_IOR'
 #define FBIOGCURMAX     _IOR('F', 28, struct fbcurpos)
                         ^~~~
fs/compat_ioctl.c:1190:14: note: in expansion of macro 'FBIOGCURMAX'
 IGNORE_IOCTL(FBIOGCURMAX)
              ^~~~~~~~~~~
arch/sparc/include/uapi/asm/fbio.h:117:39: error: invalid application of 'sizeof' to incomplete type 'struct fbcurpos'
 #define FBIOGCURMAX     _IOR('F', 28, struct fbcurpos)
                                       ^
fs/compat_ioctl.c:640:42: note: in definition of macro 'XFORM'
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0xffffffff)
                                          ^
fs/compat_ioctl.c:650:27: note: in expansion of macro 'COMPATIBLE_IOCTL'
 #define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
                           ^~~~~~~~~~~~~~~~
fs/compat_ioctl.c:1190:1: note: in expansion of macro 'IGNORE_IOCTL'
 IGNORE_IOCTL(FBIOGCURMAX)
 ^~~~~~~~~~~~
arch/sparc/include/uapi/asm/ioctl.h:46:29: note: in expansion of macro '_IOC'
 #define _IOR(type,nr,size)  _IOC(_IOC_READ,(type),(nr),sizeof(size))
                             ^~~~
arch/sparc/include/uapi/asm/fbio.h:117:25: note: in expansion of macro '_IOR'
 #define FBIOGCURMAX     _IOR('F', 28, struct fbcurpos)
                         ^~~~
fs/compat_ioctl.c:1190:14: note: in expansion of macro 'FBIOGCURMAX'
 IGNORE_IOCTL(FBIOGCURMAX)
              ^~~~~~~~~~~

Caused by commit

  be248ed54d65 ("compat_ioctl: trim the pointless includes")

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2018-09-10  3:35 Stephen Rothwell
  2018-09-18 21:38 ` Stephen Rothwell
                   ` (2 more replies)
  0 siblings, 3 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-09-10  3:35 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Howells

[-- Attachment #1: Type: text/plain, Size: 5797 bytes --]

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 patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 10 Sep 2018 13:19:20 +1000
Subject: [PATCH] disable building the VFS sample programs

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 samples/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/samples/Kconfig b/samples/Kconfig
index 0431af2589ac..c8823d9d97db 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -148,6 +148,7 @@ config SAMPLE_VFIO_MDEV_MBOCHS
 
 config SAMPLE_VFS
 	bool "Build example programs that use new VFS system calls"
+	depends on BROKEN
 	help
 	  Build example userspace programs that use new VFS system calls such
 	  as mount API and statx()
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2018-09-06  2:28 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-09-06  2:28 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Howells

[-- Attachment #1: Type: text/plain, Size: 5984 bytes --]

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 information")

I have added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 6 Sep 2018 12:15:23 +1000
Subject: [PATCH] mark samples/{mount_api,statx} as broken again

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 samples/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/samples/Kconfig b/samples/Kconfig
index 1c5658bc6224..daa17e9f3197 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -148,11 +148,13 @@ config SAMPLE_VFIO_MDEV_MBOCHS
 
 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.
 
 config SAMPLE_MOUNT_API
 	bool "Build example code using the new mount API"
+	depends on BROKEN
 	help
 	  Build example userspace program(s) that use the new mount API.
 
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2018-08-07 10:58 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-08-07 10:58 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Howells

[-- Attachment #1: Type: text/plain, Size: 4515 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-08-07  0:59   ` Stephen Rothwell
@ 2018-08-07  2:20     ` Masahiro Yamada
  0 siblings, 0 replies; 132+ messages in thread
From: Masahiro Yamada @ 2018-08-07  2:20 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List,
	David Howells, Michal Marek, Linux Kbuild mailing list,
	Arnd Bergmann, Nicolas Pitre

2018-08-07 9:59 GMT+09:00 Stephen Rothwell <sfr@canb.auug.org.au>:
> Hi all,
>
> On Mon, 6 Aug 2018 22:24:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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 <linux/fsinfo.h>
>> >           ^~~~~~~~~~~~~~~~
>> >
>> > 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 <sfr@canb.auug.org.au>
>> > 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 <sfr@canb.auug.org.au>
>> > ---
>> >  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 <yamada.masahiro@socionext.com>
> 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 <sfr@canb.auug.org.au>
> ---
>  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

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2018-08-07  1:11 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-08-07  1:11 UTC (permalink / raw)
  To: Al Viro, Masahiro Yamada
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Laura Abbott,
	David Howells

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

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 <sfr@canb.auug.org.au>
Date: Tue, 7 Aug 2018 11:01:32 +1000
Subject: [PATCH] vfs: samples: fix up for HOSTLOADLIBES rename

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-08-06 12:24 ` Stephen Rothwell
@ 2018-08-07  0:59   ` Stephen Rothwell
  2018-08-07  2:20     ` Masahiro Yamada
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2018-08-07  0:59 UTC (permalink / raw)
  To: Al Viro, Masahiro Yamada
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	David Howells, Michal Marek, Linux Kbuild mailing list,
	Arnd Bergmann, Nicolas Pitre

[-- Attachment #1: Type: text/plain, Size: 2917 bytes --]

Hi all,

On Mon, 6 Aug 2018 22:24:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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 <linux/fsinfo.h>
> >           ^~~~~~~~~~~~~~~~
> > 
> > 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 <sfr@canb.auug.org.au>
> > 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 <sfr@canb.auug.org.au>
> > ---
> >  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 <yamada.masahiro@socionext.com>
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 <sfr@canb.auug.org.au>
---
 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-08-06  0:37 Stephen Rothwell
@ 2018-08-06 12:24 ` Stephen Rothwell
  2018-08-07  0:59   ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2018-08-06 12:24 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Howells

[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]

Hi all,

On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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 <linux/fsinfo.h>
>           ^~~~~~~~~~~~~~~~
> 
> 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 <sfr@canb.auug.org.au>
> 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 <sfr@canb.auug.org.au>
> ---
>  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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2018-08-06  0:37 Stephen Rothwell
  2018-08-06 12:24 ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2018-08-06  0:37 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Howells

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

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 <linux/fsinfo.h>
          ^~~~~~~~~~~~~~~~

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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2018-06-19  1:47 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-06-19  1:47 UTC (permalink / raw)
  To: Al Viro
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Uma Krishnan,
	Martin K. Petersen

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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, &ocxlflash_fs_dops,
 			    OCXLFLASH_FS_MAGIC);
-- 
2.17.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-04-08  2:19   ` Al Viro
@ 2018-04-08  2:55     ` Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-04-08  2:55 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mateusz Guzik

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

Hi Al,

On Sun, 8 Apr 2018 03:19:56 +0100 Al Viro <viro@ZenIV.linux.org.uk> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-04-03  2:26 ` Stephen Rothwell
@ 2018-04-08  2:19   ` Al Viro
  2018-04-08  2:55     ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Al Viro @ 2018-04-08  2:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mateusz Guzik

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 <sfr@canb.auug.org.au> 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...

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-03-19  6:06 Stephen Rothwell
  2018-03-19 19:56 ` Mateusz Guzik
@ 2018-04-03  2:26 ` Stephen Rothwell
  2018-04-08  2:19   ` Al Viro
  1 sibling, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2018-04-03  2:26 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mateusz Guzik

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

Hi Al,

On Mon, 19 Mar 2018 17:06:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2018-03-19  6:06 Stephen Rothwell
@ 2018-03-19 19:56 ` Mateusz Guzik
  2018-04-03  2:26 ` Stephen Rothwell
  1 sibling, 0 replies; 132+ messages in thread
From: Mateusz Guzik @ 2018-03-19 19:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List

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(&sb->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

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2018-03-19  6:06 Stephen Rothwell
  2018-03-19 19:56 ` Mateusz Guzik
  2018-04-03  2:26 ` Stephen Rothwell
  0 siblings, 2 replies; 132+ messages in thread
From: Stephen Rothwell @ 2018-03-19  6:06 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mateusz Guzik

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2017-12-03 23:16 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2017-12-03 23:16 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List

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, &page, 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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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, &page, flags);
+	npages = get_user_pages_unlocked(addr, 1, &page, flags);
 	if (npages != 1)
 		return npages;
 
-- 
2.15.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2017-07-11  0:55 Stephen Rothwell
@ 2017-07-11  9:21 ` David Howells
  0 siblings, 0 replies; 132+ messages in thread
From: David Howells @ 2017-07-11  9:21 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: dhowells, Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

Acked-by: David Howells <dhowells@redhat.com>

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2017-07-11  0:55 Stephen Rothwell
  2017-07-11  9:21 ` David Howells
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2017-07-11  0:55 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Howells

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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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 e210d69beeee..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(&init_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

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2017-07-10  2:15 Stephen Rothwell
@ 2017-07-10  2:34 ` Al Viro
  0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2017-07-10  2:34 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	David Howells, Jeremy Kerr, Linux PPC Development List

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..e210d69beeee 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(&init_user_ns, root->i_uid));
-	if (!gid_eq(root->i_gid, GLOBAL_ROOT_GID))
+			   from_kuid_munged(&init_user_ns, inode->i_uid));
+	if (!gid_eq(inode->i_gid, GLOBAL_ROOT_GID))
 		seq_printf(m, ",gid=%u",
-			   from_kgid_munged(&init_user_ns, root->i_gid));
-	if (root->i_mode & S_IALLUGO != 0775)
-		seq_printf(m, ",mode=%o", root->i_mode);
+			   from_kgid_munged(&init_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;

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2017-07-10  2:15 Stephen Rothwell
  2017-07-10  2:34 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2017-07-10  2:15 UTC (permalink / raw)
  To: Al Viro
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	David Howells, Jeremy Kerr, Linux PPC Development List

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(&init_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(&init_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 <sfr@canb.auug.org.au>
Date: Mon, 10 Jul 2017 11:05:31 +1000
Subject: [PATCH] disable the spufs show options for now

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 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(&init_user_ns, root->i_uid));
@@ -617,6 +618,7 @@ static int spufs_show_options(struct seq_file *m, struct dentry *root)
 			   from_kgid_munged(&init_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

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2017-02-27  0:27 Stephen Rothwell
@ 2017-02-27  8:31 ` David Howells
  0 siblings, 0 replies; 132+ messages in thread
From: David Howells @ 2017-02-27  8:31 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: dhowells, Al Viro, linux-next, linux-kernel

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 27 Feb 2017 11:21:47 +1100
> Subject: [PATCH] statx: disable the sample code for now
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  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 <dhowells@redhat.com>

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2017-02-27  0:27 Stephen Rothwell
  2017-02-27  8:31 ` David Howells
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2017-02-27  0:27 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, David Howells

Hi Al,

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

samples/statx/test-statx.c:37:34: warning: 'struct statx' declared inside parameter list will not be visible outside of this definition or declaration
        unsigned int mask, struct statx *buffer)
                                  ^~~~~
samples/statx/test-statx.c: In function 'statx':
samples/statx/test-statx.c:39:17: error: '__NR_statx' undeclared (first use in this function)
  return syscall(__NR_statx, dfd, filename, flags, mask, buffer);
                 ^~~~~~~~~~
samples/statx/test-statx.c:39:17: note: each undeclared identifier is reported only once for each function it appears in
samples/statx/test-statx.c: At top level:
samples/statx/test-statx.c:42:50: warning: 'struct statx_timestamp' declared inside parameter list will not be visible outside of this definition or declaration
 static void print_time(const char *field, struct statx_timestamp *ts)
                                                  ^~~~~~~~~~~~~~~
samples/statx/test-statx.c: In function 'print_time':
samples/statx/test-statx.c:49:10: error: dereferencing pointer to incomplete type 'struct statx_timestamp'
  tim = ts->tv_sec;
          ^~
samples/statx/test-statx.c: At top level:
samples/statx/test-statx.c:71:31: warning: 'struct statx' declared inside parameter list will not be visible outside of this definition or declaration
 static void dump_statx(struct statx *stx)
                               ^~~~~
samples/statx/test-statx.c: In function 'dump_statx':
samples/statx/test-statx.c:75:28: error: dereferencing pointer to incomplete type 'struct statx'
  printf("results=%x\n", stx->stx_mask);
                            ^~
samples/statx/test-statx.c:78:22: error: 'STATX_SIZE' undeclared (first use in this function)
  if (stx->stx_mask & STATX_SIZE)
                      ^~~~~~~~~~
samples/statx/test-statx.c:80:22: error: 'STATX_BLOCKS' undeclared (first use in this function)
  if (stx->stx_mask & STATX_BLOCKS)
                      ^~~~~~~~~~~~
samples/statx/test-statx.c:83:22: error: 'STATX_TYPE' undeclared (first use in this function)
  if (stx->stx_mask & STATX_TYPE) {
                      ^~~~~~~~~~
samples/statx/test-statx.c:102:22: error: 'STATX_INO' undeclared (first use in this function)
  if (stx->stx_mask & STATX_INO)
                      ^~~~~~~~~
samples/statx/test-statx.c:104:22: error: 'STATX_NLINK' undeclared (first use in this function)
  if (stx->stx_mask & STATX_NLINK)
                      ^~~~~~~~~~~
samples/statx/test-statx.c:117:22: error: 'STATX_MODE' undeclared (first use in this function)
  if (stx->stx_mask & STATX_MODE)
                      ^~~~~~~~~~
samples/statx/test-statx.c:130:22: error: 'STATX_UID' undeclared (first use in this function)
  if (stx->stx_mask & STATX_UID)
                      ^~~~~~~~~
samples/statx/test-statx.c:132:22: error: 'STATX_GID' undeclared (first use in this function)
  if (stx->stx_mask & STATX_GID)
                      ^~~~~~~~~
samples/statx/test-statx.c:135:22: error: 'STATX_ATIME' undeclared (first use in this function)
  if (stx->stx_mask & STATX_ATIME)
                      ^~~~~~~~~~~
samples/statx/test-statx.c:137:22: error: 'STATX_MTIME' undeclared (first use in this function)
  if (stx->stx_mask & STATX_MTIME)
                      ^~~~~~~~~~~
samples/statx/test-statx.c:139:22: error: 'STATX_CTIME' undeclared (first use in this function)
  if (stx->stx_mask & STATX_CTIME)
                      ^~~~~~~~~~~
samples/statx/test-statx.c:141:22: error: 'STATX_BTIME' undeclared (first use in this function)
  if (stx->stx_mask & STATX_BTIME)
                      ^~~~~~~~~~~
samples/statx/test-statx.c: In function 'main':
samples/statx/test-statx.c:207:15: error: storage size of 'stx' isn't known
  struct statx stx;
               ^~~
samples/statx/test-statx.c:210:22: error: 'STATX_ALL' undeclared (first use in this function)
  unsigned int mask = STATX_ALL;
                      ^~~~~~~~~
samples/statx/test-statx.c:228:13: error: 'STATX_BASIC_STATS' undeclared (first use in this function)
    mask &= ~STATX_BASIC_STATS;
             ^~~~~~~~~~~~~~~~~
samples/statx/test-statx.c:207:15: warning: unused variable 'stx' [-Wunused-variable]
  struct statx stx;
               ^~~

Caused by commit

  caffc373c573 ("statx: Add a system call to make enhanced file info available")

It probably would have been nice to see this in -next a bit earlier.

I have added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 27 Feb 2017 11:21:47 +1100
Subject: [PATCH] statx: disable the sample code for now

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 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.
 
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2016-07-29  1:19 Stephen Rothwell
@ 2016-07-29  4:18 ` Al Viro
  0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2016-07-29  4:18 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Linus Torvalds

On Fri, Jul 29, 2016 at 11:19:38AM +1000, Stephen Rothwell wrote:
> ---
>  fs/fuse/dir.c    | 2 +-
>  fs/fuse/fuse_i.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> index f910578e51ba..c47b7780ce37 100644
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -935,7 +935,7 @@ int fuse_update_attributes(struct inode *inode, struct kstat *stat,
>  }
>  
>  int fuse_reverse_inval_entry(struct super_block *sb, u64 parent_nodeid,
> -			     u64 child_nodeid, const struct qstr *name)
> +			     u64 child_nodeid, struct qstr *name)
>  {
>  	int err = -ENOTDIR;
>  	struct inode *parent;

I'm not sure if it's the best way to handle that, TBH...  It might be better
to pass name.name/name.len separately here.  Both callers have a _lot_ of
code duplication; I've a patch getting rid of code duplication there, will
play with it and see if it would make sense to quit messing with struct
qstr while we are at it.

BTW, I'd been toying with the following trick:

static inline const struct qstr *d_name(const struct dentry *dentry)
{
	return &dentry->d_name;
}
with subsequent switch of dentry->d_name.foo to d_name(dentry)->foo and
&dentry->d_name to d_name(dentry).  Note 'const' in the above - the point is,
there are very few places where dentry->d_name can be legitimately modified
(__d_alloc(), swap_names() and copy_name()) and it'd be nice to have cc(1)
enforce that.  Changing d_name to const struct qstr (and explicitly casting
in the aforementioned 3 functions) would do it, but it's deep in nasal daemon
territory; OTOH, conversion to the helper above with subsequent renaming of
the field to something easily greppable for would get the same effect and
stay within standard C.

FWIW, the whole "constify struct qstr * arguments" series is due to hunting
for ppc bug reported a while ago; it manifested as NULL ->d_name.name observed
in __d_lookup_rcu().  AFAICS, it's an effect of earlier memory corruption,
seeing that there was list_del() in prune_dcache_sb() hitting NULL ->prev->next
(in __list_del_entry(), probably via prune_dcache_sb()->shrink_dentry_list()->
d_shrink_del()->list_del_init(&dentry->d_lru)), but it would be nice to have
an easier way to prove that nothing would be able to bugger ->d_name.

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2016-07-29  1:19 Stephen Rothwell
  2016-07-29  4:18 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2016-07-29  1:19 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, Linus Torvalds

Hi Al,

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

fs/fuse/dir.c: In function 'fuse_reverse_inval_entry':
fs/fuse/dir.c:958:13: error: assignment of member 'hash' in read-only object
  name->hash = full_name_hash(dir, name->name, name->len);
             ^

Caused by commit

  8387ff2577eb ("vfs: make the string hashes salt the hash")

from Linus' tree interacting with commit

  5e70178ae20b ("qstr: constify instances in fuse")

from the vfs tree.

I added this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 29 Jul 2016 11:07:45 +1000
Subject: [PATCH] qstr: unconstify fuse_reverse_inval_entry parameter

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/fuse/dir.c    | 2 +-
 fs/fuse/fuse_i.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index f910578e51ba..c47b7780ce37 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -935,7 +935,7 @@ int fuse_update_attributes(struct inode *inode, struct kstat *stat,
 }
 
 int fuse_reverse_inval_entry(struct super_block *sb, u64 parent_nodeid,
-			     u64 child_nodeid, const struct qstr *name)
+			     u64 child_nodeid, struct qstr *name)
 {
 	int err = -ENOTDIR;
 	struct inode *parent;
diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
index 6df761726a53..d98d8cc84def 100644
--- a/fs/fuse/fuse_i.h
+++ b/fs/fuse/fuse_i.h
@@ -929,7 +929,7 @@ int fuse_reverse_inval_inode(struct super_block *sb, u64 nodeid,
  * then the dentry is unhashed (d_delete()).
  */
 int fuse_reverse_inval_entry(struct super_block *sb, u64 parent_nodeid,
-			     u64 child_nodeid, const struct qstr *name);
+			     u64 child_nodeid, struct qstr *name);
 
 int fuse_do_open(struct fuse_conn *fc, u64 nodeid, struct file *file,
 		 bool isdir);
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2016-05-02  1:31 ` Al Viro
@ 2016-05-02  4:48   ` Abhijith Das
  0 siblings, 0 replies; 132+ messages in thread
From: Abhijith Das @ 2016-05-02  4:48 UTC (permalink / raw)
  To: Al Viro
  Cc: Stephen Rothwell, Steven Whitehouse, Bob Peterson, linux-next,
	linux-kernel

Hi Al/Stephen

----- Original Message -----
> From: "Al Viro" <viro@ZenIV.linux.org.uk>
> To: "Stephen Rothwell" <sfr@canb.auug.org.au>
> Cc: "Steven Whitehouse" <swhiteho@redhat.com>, "Bob Peterson" <rpeterso@redhat.com>, linux-next@vger.kernel.org,
> linux-kernel@vger.kernel.org, "Abhi Das" <adas@redhat.com>
> Sent: Sunday, May 1, 2016 8:31:03 PM
> Subject: Re: linux-next: build failure after merge of the vfs tree
> 
> On Mon, May 02, 2016 at 11:25:27AM +1000, Stephen Rothwell wrote:
> > Hi Al,
> > 
> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > In file included from include/linux/notifier.h:13:0,
> >                  from include/linux/memory_hotplug.h:6,
> >                  from include/linux/mmzone.h:744,
> >                  from include/linux/gfp.h:5,
> >                  from include/linux/slab.h:14,
> >                  from fs/gfs2/file.c:10:
> > fs/gfs2/file.c: In function 'gfs2_file_splice_read':
> > fs/gfs2/file.c:963:19: error: 'struct inode' has no member named 'i_mutex'
> >   mutex_lock(&inode->i_mutex);
> >                    ^
> > include/linux/mutex.h:146:44: note: in definition of macro 'mutex_lock'
> >  #define mutex_lock(lock) mutex_lock_nested(lock, 0)
> >                                             ^
> > fs/gfs2/file.c:967:22: error: 'struct inode' has no member named 'i_mutex'
> >    mutex_unlock(&inode->i_mutex);
> >                       ^
> > fs/gfs2/file.c:972:21: error: 'struct inode' has no member named 'i_mutex'
> >   mutex_unlock(&inode->i_mutex);
> >                      ^
> > 
> > Caused by commit
> > 
> >   ad10a307a918 ("parallel lookups: actual switch to rwsem")
> > 
> > interacting with commit
> > 
> >   611526756a3d ("gfs2: Use gfs2 wrapper to sync inode before calling
> >   generic_file_splice_read()")
> > 
> > from the gfs2 tree.
> > 
> > I applied the following merge fix patch for today (thanks Al):
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 2 May 2016 11:17:40 +1000
> > Subject: [PATCH] gfs2: fix up for i_mutex -> i_rwsem change
> 
> FWIW, that should go into gfs2 tree - inode_lock()/inode_unlock() had been
> there since the last cycle and they should've been used instead of direct
> access to ->i_mutex.  So this fix will be valid in gfs2 branch.
> 

Apologies for the oversight. I just posted Stephen's patch for linux-gfs2.
Bob, could you push it in asap?

Cheers!
--Abhi

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2016-05-02  1:25 Stephen Rothwell
@ 2016-05-02  1:31 ` Al Viro
  2016-05-02  4:48   ` Abhijith Das
  0 siblings, 1 reply; 132+ messages in thread
From: Al Viro @ 2016-05-02  1:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Steven Whitehouse, Bob Peterson, linux-next, linux-kernel, Abhi Das

On Mon, May 02, 2016 at 11:25:27AM +1000, Stephen Rothwell wrote:
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> In file included from include/linux/notifier.h:13:0,
>                  from include/linux/memory_hotplug.h:6,
>                  from include/linux/mmzone.h:744,
>                  from include/linux/gfp.h:5,
>                  from include/linux/slab.h:14,
>                  from fs/gfs2/file.c:10:
> fs/gfs2/file.c: In function 'gfs2_file_splice_read':
> fs/gfs2/file.c:963:19: error: 'struct inode' has no member named 'i_mutex'
>   mutex_lock(&inode->i_mutex);
>                    ^
> include/linux/mutex.h:146:44: note: in definition of macro 'mutex_lock'
>  #define mutex_lock(lock) mutex_lock_nested(lock, 0)
>                                             ^
> fs/gfs2/file.c:967:22: error: 'struct inode' has no member named 'i_mutex'
>    mutex_unlock(&inode->i_mutex);   
>                       ^
> fs/gfs2/file.c:972:21: error: 'struct inode' has no member named 'i_mutex'
>   mutex_unlock(&inode->i_mutex);
>                      ^
> 
> Caused by commit
> 
>   ad10a307a918 ("parallel lookups: actual switch to rwsem")
> 
> interacting with commit
> 
>   611526756a3d ("gfs2: Use gfs2 wrapper to sync inode before calling generic_file_splice_read()")
> 
> from the gfs2 tree.
> 
> I applied the following merge fix patch for today (thanks Al):
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 2 May 2016 11:17:40 +1000
> Subject: [PATCH] gfs2: fix up for i_mutex -> i_rwsem change

FWIW, that should go into gfs2 tree - inode_lock()/inode_unlock() had been
there since the last cycle and they should've been used instead of direct
access to ->i_mutex.  So this fix will be valid in gfs2 branch.

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2016-05-02  1:25 Stephen Rothwell
  2016-05-02  1:31 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2016-05-02  1:25 UTC (permalink / raw)
  To: Al Viro, Steven Whitehouse, Bob Peterson
  Cc: linux-next, linux-kernel, Abhi Das

Hi Al,

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

In file included from include/linux/notifier.h:13:0,
                 from include/linux/memory_hotplug.h:6,
                 from include/linux/mmzone.h:744,
                 from include/linux/gfp.h:5,
                 from include/linux/slab.h:14,
                 from fs/gfs2/file.c:10:
fs/gfs2/file.c: In function 'gfs2_file_splice_read':
fs/gfs2/file.c:963:19: error: 'struct inode' has no member named 'i_mutex'
  mutex_lock(&inode->i_mutex);
                   ^
include/linux/mutex.h:146:44: note: in definition of macro 'mutex_lock'
 #define mutex_lock(lock) mutex_lock_nested(lock, 0)
                                            ^
fs/gfs2/file.c:967:22: error: 'struct inode' has no member named 'i_mutex'
   mutex_unlock(&inode->i_mutex);   
                      ^
fs/gfs2/file.c:972:21: error: 'struct inode' has no member named 'i_mutex'
  mutex_unlock(&inode->i_mutex);
                     ^

Caused by commit

  ad10a307a918 ("parallel lookups: actual switch to rwsem")

interacting with commit

  611526756a3d ("gfs2: Use gfs2 wrapper to sync inode before calling generic_file_splice_read()")

from the gfs2 tree.

I applied the following merge fix patch for today (thanks Al):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 2 May 2016 11:17:40 +1000
Subject: [PATCH] gfs2: fix up for i_mutex -> i_rwsem change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/gfs2/file.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
index 3f27ab291029..76e205455503 100644
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -960,16 +960,16 @@ static ssize_t gfs2_file_splice_read(struct file *in, loff_t *ppos,
 	struct gfs2_holder gh;
 	int ret;
 
-	mutex_lock(&inode->i_mutex);
+	inode_lock(inode);
 
 	ret = gfs2_glock_nq_init(ip->i_gl, LM_ST_SHARED, 0, &gh);
 	if (ret) {
-		mutex_unlock(&inode->i_mutex);
+		inode_unlock(inode);
 		return ret;
 	}
 
 	gfs2_glock_dq_uninit(&gh);
-	mutex_unlock(&inode->i_mutex);
+	inode_unlock(inode);
 
 	return generic_file_splice_read(in, ppos, pipe, len, flags);
 }
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2016-01-07  0:42   ` Stephen Rothwell
@ 2016-01-07  2:09     ` Al Viro
  0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2016-01-07  2:09 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Mike Marshall

On Thu, Jan 07, 2016 at 11:42:53AM +1100, Stephen Rothwell wrote:

> > This patch now looks like this (after changes to the orangefs tree):
> > 

Guys, just set inode->i_link to ORANGEFS_I(dentry->d_inode)->link_target and
have ->get_link = simple_get_link.  Killing orangefs_{follow,get}_link()
entirely.

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2015-12-21  0:23 ` Stephen Rothwell
@ 2016-01-07  0:42   ` Stephen Rothwell
  2016-01-07  2:09     ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2016-01-07  0:42 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, Mike Marshall

Hi all,

On Mon, 21 Dec 2015 11:23:01 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 10 Dec 2015 11:18:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > fs/orangefs/symlink.c:26:2: error: unknown field 'follow_link' specified in initializer
> >   .follow_link = pvfs2_follow_link,
> >   ^
> > fs/orangefs/symlink.c:26:17: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
> >   .follow_link = pvfs2_follow_link, 
> >                  ^
> > fs/orangefs/symlink.c:26:17: note: (near initialization for 'pvfs2_symlink_inode_operations.put_link')
> > 
> > Caused by commit
> > 
> >   6b2553918d8b ("replace ->follow_link() with new method that could stay in RCU mode")
> > 
> > [I wish there was some way to stage these API changes :-(]
> > 
> > I applied the following merge fix patch (which may need more work):
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 10 Dec 2015 11:12:36 +1100
> > Subject: [PATCH] orangfs: update for follow_link to get_link change
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  fs/orangefs/symlink.c | 12 +++++++++---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/orangefs/symlink.c b/fs/orangefs/symlink.c
> > index 2adfceff7730..dbf24a98a3c9 100644
> > --- a/fs/orangefs/symlink.c
> > +++ b/fs/orangefs/symlink.c
> > @@ -8,9 +8,15 @@
> >  #include "pvfs2-kernel.h"
> >  #include "pvfs2-bufmap.h"
> >  
> > -static const char *pvfs2_follow_link(struct dentry *dentry, void **cookie)
> > +static const char *pvfs2_get_link(struct dentry *dentry, struct inode *inode,
> > +				  void **cookie)
> >  {
> > -	char *target =  PVFS2_I(dentry->d_inode)->link_target;
> > +	char *target;
> > +
> > +	if (!dentry)
> > +		return ERR_PTR(-ECHILD);
> > +
> > +	target =  PVFS2_I(inode)->link_target;
> >  
> >  	gossip_debug(GOSSIP_INODE_DEBUG,
> >  		     "%s: called on %s (target is %p)\n",
> > @@ -23,7 +29,7 @@ static const char *pvfs2_follow_link(struct dentry *dentry, void **cookie)
> >  
> >  struct inode_operations pvfs2_symlink_inode_operations = {
> >  	.readlink = generic_readlink,
> > -	.follow_link = pvfs2_follow_link,
> > +	.get_link = pvfs2_get_link,
> >  	.setattr = pvfs2_setattr,
> >  	.getattr = pvfs2_getattr,
> >  	.listxattr = pvfs2_listxattr,  
> 
> This patch now looks like this (after changes to the orangefs tree):
> 
> diff --git a/fs/orangefs/symlink.c b/fs/orangefs/symlink.c
> index 1b3ae63463dc..01977e88e95d 100644
> --- a/fs/orangefs/symlink.c
> +++ b/fs/orangefs/symlink.c
> @@ -8,9 +8,15 @@
>  #include "orangefs-kernel.h"
>  #include "orangefs-bufmap.h"
>  
> -static const char *orangefs_follow_link(struct dentry *dentry, void **cookie)
> +static const char *orangefs_get_link(struct dentry *dentry, struct inode *inode,
> +				     void **cookie)
>  {
> -	char *target =  ORANGEFS_I(dentry->d_inode)->link_target;
> +	char *target;
> +
> +	if (!dentry)
> +		return ERR_PTR(-ECHILD);
> +
> +	target = ORANGEFS_I(inode)->link_target;
>  
>  	gossip_debug(GOSSIP_INODE_DEBUG,
>  		     "%s: called on %s (target is %p)\n",
> @@ -23,7 +29,7 @@ static const char *orangefs_follow_link(struct dentry *dentry, void **cookie)
>  
>  struct inode_operations orangefs_symlink_inode_operations = {
>  	.readlink = generic_readlink,
> -	.follow_link = orangefs_follow_link,
> +	.get_link = orangefs_get_link,
>  	.setattr = orangefs_setattr,
>  	.getattr = orangefs_getattr,
>  	.listxattr = orangefs_listxattr,

This patch now looks like this (I think this is right):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 7 Jan 2016 11:37:17 +1100
Subject: [PATCH] orangfs: update for follow_link to get_link change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/orangefs/symlink.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/fs/orangefs/symlink.c b/fs/orangefs/symlink.c
index 1b3ae63463dc..a21083790fb8 100644
--- a/fs/orangefs/symlink.c
+++ b/fs/orangefs/symlink.c
@@ -8,22 +8,26 @@
 #include "orangefs-kernel.h"
 #include "orangefs-bufmap.h"
 
-static const char *orangefs_follow_link(struct dentry *dentry, void **cookie)
+static const char *orangefs_get_link(struct dentry *dentry, struct inode *inode,
+				     struct delayed_call *done)
 {
-	char *target =  ORANGEFS_I(dentry->d_inode)->link_target;
+	char *target;
+
+	if (!dentry)
+		return ERR_PTR(-ECHILD);
+
+	target =  ORANGEFS_I(dentry->d_inode)->link_target;
 
 	gossip_debug(GOSSIP_INODE_DEBUG,
 		     "%s: called on %s (target is %p)\n",
 		     __func__, (char *)dentry->d_name.name, target);
 
-	*cookie = target;
-
 	return target;
 }
 
 struct inode_operations orangefs_symlink_inode_operations = {
 	.readlink = generic_readlink,
-	.follow_link = orangefs_follow_link,
+	.get_link = orangefs_get_link,
 	.setattr = orangefs_setattr,
 	.getattr = orangefs_getattr,
 	.listxattr = orangefs_listxattr,
-- 
2.6.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2015-12-10  0:18 Stephen Rothwell
  2015-12-10  0:23 ` Stephen Rothwell
@ 2015-12-21  0:23 ` Stephen Rothwell
  2016-01-07  0:42   ` Stephen Rothwell
  1 sibling, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2015-12-21  0:23 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, Mike Marshall

Hi Stephen,

On Thu, 10 Dec 2015 11:18:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> fs/orangefs/symlink.c:26:2: error: unknown field 'follow_link' specified in initializer
>   .follow_link = pvfs2_follow_link,
>   ^
> fs/orangefs/symlink.c:26:17: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
>   .follow_link = pvfs2_follow_link, 
>                  ^
> fs/orangefs/symlink.c:26:17: note: (near initialization for 'pvfs2_symlink_inode_operations.put_link')
> 
> Caused by commit
> 
>   6b2553918d8b ("replace ->follow_link() with new method that could stay in RCU mode")
> 
> [I wish there was some way to stage these API changes :-(]
> 
> I applied the following merge fix patch (which may need more work):
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 10 Dec 2015 11:12:36 +1100
> Subject: [PATCH] orangfs: update for follow_link to get_link change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/orangefs/symlink.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/orangefs/symlink.c b/fs/orangefs/symlink.c
> index 2adfceff7730..dbf24a98a3c9 100644
> --- a/fs/orangefs/symlink.c
> +++ b/fs/orangefs/symlink.c
> @@ -8,9 +8,15 @@
>  #include "pvfs2-kernel.h"
>  #include "pvfs2-bufmap.h"
>  
> -static const char *pvfs2_follow_link(struct dentry *dentry, void **cookie)
> +static const char *pvfs2_get_link(struct dentry *dentry, struct inode *inode,
> +				  void **cookie)
>  {
> -	char *target =  PVFS2_I(dentry->d_inode)->link_target;
> +	char *target;
> +
> +	if (!dentry)
> +		return ERR_PTR(-ECHILD);
> +
> +	target =  PVFS2_I(inode)->link_target;
>  
>  	gossip_debug(GOSSIP_INODE_DEBUG,
>  		     "%s: called on %s (target is %p)\n",
> @@ -23,7 +29,7 @@ static const char *pvfs2_follow_link(struct dentry *dentry, void **cookie)
>  
>  struct inode_operations pvfs2_symlink_inode_operations = {
>  	.readlink = generic_readlink,
> -	.follow_link = pvfs2_follow_link,
> +	.get_link = pvfs2_get_link,
>  	.setattr = pvfs2_setattr,
>  	.getattr = pvfs2_getattr,
>  	.listxattr = pvfs2_listxattr,

This patch now looks like this (after changes to the orangefs tree):

diff --git a/fs/orangefs/symlink.c b/fs/orangefs/symlink.c
index 1b3ae63463dc..01977e88e95d 100644
--- a/fs/orangefs/symlink.c
+++ b/fs/orangefs/symlink.c
@@ -8,9 +8,15 @@
 #include "orangefs-kernel.h"
 #include "orangefs-bufmap.h"
 
-static const char *orangefs_follow_link(struct dentry *dentry, void **cookie)
+static const char *orangefs_get_link(struct dentry *dentry, struct inode *inode,
+				     void **cookie)
 {
-	char *target =  ORANGEFS_I(dentry->d_inode)->link_target;
+	char *target;
+
+	if (!dentry)
+		return ERR_PTR(-ECHILD);
+
+	target = ORANGEFS_I(inode)->link_target;
 
 	gossip_debug(GOSSIP_INODE_DEBUG,
 		     "%s: called on %s (target is %p)\n",
@@ -23,7 +29,7 @@ static const char *orangefs_follow_link(struct dentry *dentry, void **cookie)
 
 struct inode_operations orangefs_symlink_inode_operations = {
 	.readlink = generic_readlink,
-	.follow_link = orangefs_follow_link,
+	.get_link = orangefs_get_link,
 	.setattr = orangefs_setattr,
 	.getattr = orangefs_getattr,
 	.listxattr = orangefs_listxattr,

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2015-12-10  0:48   ` Al Viro
@ 2015-12-10 15:44     ` Mike Marshall
  0 siblings, 0 replies; 132+ messages in thread
From: Mike Marshall @ 2015-12-10 15:44 UTC (permalink / raw)
  To: Al Viro; +Cc: Stephen Rothwell, linux-next, LKML

 > Said that, there is an unpleasant bug in that area - link_target of a live
 > inode can be overwritten, right under the pathname resolution walking the
 > old contents of that thing

Figuring that out is on the list. This week I've been working on cleaning up
orangefs_devreq_writev, and Martin even has a version that changes
the protocol where userspace uses write instead of writev, getting rid
of the 4-or-5 iovec scheme Al hates. If he still hates it after the code
is readable, we'll probably go that direction...

And we have an infant fuzzer that we've already crashed the kernel with (and
made an easy and good fix, I think).

And also this week I have tried to address Linus' concerns about our
old fashioned waiting scheme where we used add_wait_queue and
set_current_state instead of the wait_event() model.

Yi Liu who is also working with us on this project has provided a patch
that changes all the pvfs2 occurrences to orangefs.

These patches will be in our kernel.org tree very soon I hope,
but we won't be done yet...

-Mike "you're never done..."

On Wed, Dec 9, 2015 at 7:48 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Thu, Dec 10, 2015 at 11:23:22AM +1100, Stephen Rothwell wrote:
>> [Just adding the origefs maintainer to the cc list]
>> > -static const char *pvfs2_follow_link(struct dentry *dentry, void **cookie)
>> > +static const char *pvfs2_get_link(struct dentry *dentry, struct inode *inode,
>> > +                             void **cookie)
>> >  {
>> > -   char *target =  PVFS2_I(dentry->d_inode)->link_target;
>
> Better fix is to have inode->link = PVFS2_I(dentry->d_inode)->link_target;
> when we set the latter and use .get_link = simple_get_link...
>
> Said that, there is an unpleasant bug in that area - link_target of a live
> inode can be overwritten, right under the pathname resolution walking the
> old contents of that thing.
>
> copy_attributes_to_inode() is triggered by ->d_revalidate() and by ->getattr()
> and it's really, really unsafe for a live inode.  Just look what it does
> to ->i_mode...  Sure, normally a server won't return different symlink bodies
> on subsequent getattr requests.  As long as it's sane (and not compromised,
> etc.), but relying upon that is not a good idea.

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2015-12-10  0:23 ` Stephen Rothwell
@ 2015-12-10  0:48   ` Al Viro
  2015-12-10 15:44     ` Mike Marshall
  0 siblings, 1 reply; 132+ messages in thread
From: Al Viro @ 2015-12-10  0:48 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Mike Marshall

On Thu, Dec 10, 2015 at 11:23:22AM +1100, Stephen Rothwell wrote:
> [Just adding the origefs maintainer to the cc list]
> > -static const char *pvfs2_follow_link(struct dentry *dentry, void **cookie)
> > +static const char *pvfs2_get_link(struct dentry *dentry, struct inode *inode,
> > +				  void **cookie)
> >  {
> > -	char *target =  PVFS2_I(dentry->d_inode)->link_target;

Better fix is to have inode->link = PVFS2_I(dentry->d_inode)->link_target;
when we set the latter and use .get_link = simple_get_link...

Said that, there is an unpleasant bug in that area - link_target of a live
inode can be overwritten, right under the pathname resolution walking the
old contents of that thing.

copy_attributes_to_inode() is triggered by ->d_revalidate() and by ->getattr()
and it's really, really unsafe for a live inode.  Just look what it does
to ->i_mode...  Sure, normally a server won't return different symlink bodies
on subsequent getattr requests.  As long as it's sane (and not compromised,
etc.), but relying upon that is not a good idea.

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2015-12-10  0:18 Stephen Rothwell
@ 2015-12-10  0:23 ` Stephen Rothwell
  2015-12-10  0:48   ` Al Viro
  2015-12-21  0:23 ` Stephen Rothwell
  1 sibling, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2015-12-10  0:23 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, Mike Marshall

[Just adding the origefs maintainer to the cc list]

On Thu, 10 Dec 2015 11:18:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> fs/orangefs/symlink.c:26:2: error: unknown field 'follow_link' specified in initializer
>   .follow_link = pvfs2_follow_link,
>   ^
> fs/orangefs/symlink.c:26:17: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
>   .follow_link = pvfs2_follow_link, 
>                  ^
> fs/orangefs/symlink.c:26:17: note: (near initialization for 'pvfs2_symlink_inode_operations.put_link')
> 
> Caused by commit
> 
>   6b2553918d8b ("replace ->follow_link() with new method that could stay in RCU mode")
> 
> [I wish there was some way to stage these API changes :-(]
> 
> I applied the following merge fix patch (which may need more work):
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 10 Dec 2015 11:12:36 +1100
> Subject: [PATCH] orangfs: update for follow_link to get_link change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/orangefs/symlink.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/orangefs/symlink.c b/fs/orangefs/symlink.c
> index 2adfceff7730..dbf24a98a3c9 100644
> --- a/fs/orangefs/symlink.c
> +++ b/fs/orangefs/symlink.c
> @@ -8,9 +8,15 @@
>  #include "pvfs2-kernel.h"
>  #include "pvfs2-bufmap.h"
>  
> -static const char *pvfs2_follow_link(struct dentry *dentry, void **cookie)
> +static const char *pvfs2_get_link(struct dentry *dentry, struct inode *inode,
> +				  void **cookie)
>  {
> -	char *target =  PVFS2_I(dentry->d_inode)->link_target;
> +	char *target;
> +
> +	if (!dentry)
> +		return ERR_PTR(-ECHILD);
> +
> +	target =  PVFS2_I(inode)->link_target;
>  
>  	gossip_debug(GOSSIP_INODE_DEBUG,
>  		     "%s: called on %s (target is %p)\n",
> @@ -23,7 +29,7 @@ static const char *pvfs2_follow_link(struct dentry *dentry, void **cookie)
>  
>  struct inode_operations pvfs2_symlink_inode_operations = {
>  	.readlink = generic_readlink,
> -	.follow_link = pvfs2_follow_link,
> +	.get_link = pvfs2_get_link,
>  	.setattr = pvfs2_setattr,
>  	.getattr = pvfs2_getattr,
>  	.listxattr = pvfs2_listxattr,
> -- 
> 2.6.2

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2015-12-10  0:18 Stephen Rothwell
  2015-12-10  0:23 ` Stephen Rothwell
  2015-12-21  0:23 ` Stephen Rothwell
  0 siblings, 2 replies; 132+ messages in thread
From: Stephen Rothwell @ 2015-12-10  0:18 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

Hi Al,

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

fs/orangefs/symlink.c:26:2: error: unknown field 'follow_link' specified in initializer
  .follow_link = pvfs2_follow_link,
  ^
fs/orangefs/symlink.c:26:17: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
  .follow_link = pvfs2_follow_link, 
                 ^
fs/orangefs/symlink.c:26:17: note: (near initialization for 'pvfs2_symlink_inode_operations.put_link')

Caused by commit

  6b2553918d8b ("replace ->follow_link() with new method that could stay in RCU mode")

[I wish there was some way to stage these API changes :-(]

I applied the following merge fix patch (which may need more work):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 10 Dec 2015 11:12:36 +1100
Subject: [PATCH] orangfs: update for follow_link to get_link change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/orangefs/symlink.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/fs/orangefs/symlink.c b/fs/orangefs/symlink.c
index 2adfceff7730..dbf24a98a3c9 100644
--- a/fs/orangefs/symlink.c
+++ b/fs/orangefs/symlink.c
@@ -8,9 +8,15 @@
 #include "pvfs2-kernel.h"
 #include "pvfs2-bufmap.h"
 
-static const char *pvfs2_follow_link(struct dentry *dentry, void **cookie)
+static const char *pvfs2_get_link(struct dentry *dentry, struct inode *inode,
+				  void **cookie)
 {
-	char *target =  PVFS2_I(dentry->d_inode)->link_target;
+	char *target;
+
+	if (!dentry)
+		return ERR_PTR(-ECHILD);
+
+	target =  PVFS2_I(inode)->link_target;
 
 	gossip_debug(GOSSIP_INODE_DEBUG,
 		     "%s: called on %s (target is %p)\n",
@@ -23,7 +29,7 @@ static const char *pvfs2_follow_link(struct dentry *dentry, void **cookie)
 
 struct inode_operations pvfs2_symlink_inode_operations = {
 	.readlink = generic_readlink,
-	.follow_link = pvfs2_follow_link,
+	.get_link = pvfs2_get_link,
 	.setattr = pvfs2_setattr,
 	.getattr = pvfs2_getattr,
 	.listxattr = pvfs2_listxattr,
-- 
2.6.2

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2015-12-09 22:20   ` Stephen Rothwell
@ 2015-12-09 22:53     ` Andreas Grünbacher
  0 siblings, 0 replies; 132+ messages in thread
From: Andreas Grünbacher @ 2015-12-09 22:53 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Mike Marshall, Al Viro, linux-next, LKML, Andreas Gruenbacher

2015-12-09 23:20 GMT+01:00 Stephen Rothwell <sfr@canb.auug.org.au>:
> OK, I wrote all that and then I realised that the preferred names
> (XATTR_NAME_POSIX_ACL_..) have been in Linus' tree for a long time (in
> include/uapi/linux/xattr.h), so you could just change the orangefs tree
> to use those already. i.e. my patch should apply cleanly to the
> orangefs tree and build and work correctly independently of the vfs
> tree change (I think).

Yes, I think that would be best.

Thanks, in particular for all the linux-next work!

Andreas

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2015-12-09 21:30 ` Mike Marshall
@ 2015-12-09 22:20   ` Stephen Rothwell
  2015-12-09 22:53     ` Andreas Grünbacher
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2015-12-09 22:20 UTC (permalink / raw)
  To: Mike Marshall; +Cc: Al Viro, linux-next, LKML, Andreas Gruenbacher

Hi Mike,

On Wed, 9 Dec 2015 16:30:34 -0500 Mike Marshall <hubcap@omnibond.com> wrote:
>
> I'm having a chicken-and-egg moment here...

not really ...

> I think "posix acls: Remove duplicate xattr name definitions" got into
> linux-next after
> Linus committed  Linux 4.4-rc4.

Yes

> Unless I merge my for-next with Linus' tree at the current (arbitrary)
> point, I need to wait
> until I can merge with rc5 before I can apply this fix.
> 
> I know Linus hates to get pull requests for stuff that's not based on
> a discrete tag,
> I'm not sure what's appropriate for linux-next... ?

That commit is *not* in Linus' tree and won't be until the next merge
window.  There is nothing you can do about it until then.  I will carry
the merge resolution patch in linus-next and then someone needs to let
Linus know what needs to be done when the latter of the two trees is
merged into his.  This is pretty standard when there is a conflict like
this that cannot be automatically resolved by git.

OK, I wrote all that and then I realised that the preferred names
(XATTR_NAME_POSIX_ACL_..) have been in Linus' tree for a long time (in
include/uapi/linux/xattr.h), so you could just change the orangefs tree
to use those already. i.e. my patch should apply cleanly to the
orangefs tree and build and work correctly independently of the vfs
tree change (I think).

BTW, there is also a section just above the bit this patch affects that
could be removed completely (it has "#if 0" around it).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2015-12-09  1:19 Stephen Rothwell
@ 2015-12-09 21:30 ` Mike Marshall
  2015-12-09 22:20   ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Mike Marshall @ 2015-12-09 21:30 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Al Viro, linux-next, LKML, Andreas Gruenbacher

Hi all...

I'm having a chicken-and-egg moment here...

I think "posix acls: Remove duplicate xattr name definitions" got into
linux-next after
Linus committed  Linux 4.4-rc4.

Unless I merge my for-next with Linus' tree at the current (arbitrary)
point, I need to wait
until I can merge with rc5 before I can apply this fix.

I know Linus hates to get pull requests for stuff that's not based on
a discrete tag,
I'm not sure what's appropriate for linux-next... ?

-Mike

On Tue, Dec 8, 2015 at 8:19 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Al,
>
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from fs/orangefs/acl.c:8:0:
> fs/orangefs/acl.c: In function 'pvfs2_get_acl':
> fs/orangefs/pvfs2-kernel.h:203:38: error: 'POSIX_ACL_XATTR_ACCESS' undeclared (first use in this function)
>  #define PVFS2_XATTR_NAME_ACL_ACCESS  POSIX_ACL_XATTR_ACCESS
>                                       ^
> fs/orangefs/acl.c:21:9: note: in expansion of macro 'PVFS2_XATTR_NAME_ACL_ACCESS'
>    key = PVFS2_XATTR_NAME_ACL_ACCESS;
>          ^
> fs/orangefs/pvfs2-kernel.h:203:38: note: each undeclared identifier is reported only once for each function it appears in
>  #define PVFS2_XATTR_NAME_ACL_ACCESS  POSIX_ACL_XATTR_ACCESS
>                                       ^
> fs/orangefs/acl.c:21:9: note: in expansion of macro 'PVFS2_XATTR_NAME_ACL_ACCESS'
>    key = PVFS2_XATTR_NAME_ACL_ACCESS;
>          ^
> fs/orangefs/pvfs2-kernel.h:204:38: error: 'POSIX_ACL_XATTR_DEFAULT' undeclared (first use in this function)
>  #define PVFS2_XATTR_NAME_ACL_DEFAULT POSIX_ACL_XATTR_DEFAULT
>                                       ^
> fs/orangefs/acl.c:24:9: note: in expansion of macro 'PVFS2_XATTR_NAME_ACL_DEFAULT'
>    key = PVFS2_XATTR_NAME_ACL_DEFAULT;
>          ^
> fs/orangefs/acl.c: In function 'pvfs2_set_acl':
> fs/orangefs/pvfs2-kernel.h:203:38: error: 'POSIX_ACL_XATTR_ACCESS' undeclared (first use in this function)
>  #define PVFS2_XATTR_NAME_ACL_ACCESS  POSIX_ACL_XATTR_ACCESS
>                                       ^
> fs/orangefs/acl.c:77:10: note: in expansion of macro 'PVFS2_XATTR_NAME_ACL_ACCESS'
>    name = PVFS2_XATTR_NAME_ACL_ACCESS;
>           ^
> fs/orangefs/pvfs2-kernel.h:204:38: error: 'POSIX_ACL_XATTR_DEFAULT' undeclared (first use in this function)
>  #define PVFS2_XATTR_NAME_ACL_DEFAULT POSIX_ACL_XATTR_DEFAULT
>                                       ^
> fs/orangefs/acl.c:101:10: note: in expansion of macro 'PVFS2_XATTR_NAME_ACL_DEFAULT'
>    name = PVFS2_XATTR_NAME_ACL_DEFAULT;
>           ^
>
> Caused by commit
>
>   97d79299223b ("posix acls: Remove duplicate xattr name definitions")
>
> interacting with the addition of orangefs in the orangefs tree.
>
> I applied this merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 9 Dec 2015 12:13:37 +1100
> Subject: [PATCH] orangefs: update for POSIX ACL name changes
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/orangefs/pvfs2-kernel.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/orangefs/pvfs2-kernel.h b/fs/orangefs/pvfs2-kernel.h
> index 4295e263e25b..9beeddbf8aa9 100644
> --- a/fs/orangefs/pvfs2-kernel.h
> +++ b/fs/orangefs/pvfs2-kernel.h
> @@ -200,8 +200,8 @@ struct client_debug_mask {
>  #endif
>  #endif
>
> -#define PVFS2_XATTR_NAME_ACL_ACCESS  POSIX_ACL_XATTR_ACCESS
> -#define PVFS2_XATTR_NAME_ACL_DEFAULT POSIX_ACL_XATTR_DEFAULT
> +#define PVFS2_XATTR_NAME_ACL_ACCESS  XATTR_NAME_POSIX_ACL_ACCESS
> +#define PVFS2_XATTR_NAME_ACL_DEFAULT XATTR_NAME_POSIX_ACL_DEFAULT
>  #define PVFS2_XATTR_NAME_TRUSTED_PREFIX "trusted."
>  #define PVFS2_XATTR_NAME_DEFAULT_PREFIX ""
>
> --
> 2.6.2
>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2015-12-09  5:58 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2015-12-09  5:58 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

Hi Al,

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

In file included from include/linux/poll.h:9:0,
                 from include/linux/rtc.h:56,
                 from include/linux/mc146818rtc.h:15,
                 from drivers/char/nvram.c:105:
drivers/char/nvram.c: In function 'nvram_llseek':
include/linux/fs.h:898:36: error: 'PAGE_CACHE_SIZE' undeclared (first use in this function)
 #define MAX_LFS_FILESIZE (((loff_t)PAGE_CACHE_SIZE << (BITS_PER_LONG-1))-1)
                                    ^
drivers/char/nvram.c:216:56: note: in expansion of macro 'MAX_LFS_FILESIZE'
  return generic_file_llseek_size(file, offset, origin, MAX_LFS_FILESIZE,
                                                        ^
include/linux/fs.h:898:36: note: each undeclared identifier is reported only once for each function it appears in
 #define MAX_LFS_FILESIZE (((loff_t)PAGE_CACHE_SIZE << (BITS_PER_LONG-1))-1)
                                    ^
drivers/char/nvram.c:216:56: note: in expansion of macro 'MAX_LFS_FILESIZE'
  return generic_file_llseek_size(file, offset, origin, MAX_LFS_FILESIZE,
                                                        ^
drivers/char/nvram.c:218:1: warning: control reaches end of non-void function [-Wreturn-type]   
 }
 ^

Caused by commit

  acde094daf36 ("don't open-code generic_file_llseek_size()")

I applied the following fix patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 9 Dec 2015 16:48:00 +1100
Subject: [PATCH] fix for "don't open-code generic_file_llseek_size()"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/char/nvram.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/char/nvram.c b/drivers/char/nvram.c
index 2157787cf11b..78a1cd690c96 100644
--- a/drivers/char/nvram.c
+++ b/drivers/char/nvram.c
@@ -39,6 +39,7 @@
 
 #include <linux/module.h>
 #include <linux/nvram.h>
+#include <linux/pagemap.h>	/* for PAGE_CACHE_SIZE */
 
 #define PC		1
 #define ATARI		2
-- 
2.6.2

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2015-12-09  1:19 Stephen Rothwell
  2015-12-09 21:30 ` Mike Marshall
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2015-12-09  1:19 UTC (permalink / raw)
  To: Al Viro, Mike Marshall; +Cc: linux-next, linux-kernel, Andreas Gruenbacher

Hi Al,

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

In file included from fs/orangefs/acl.c:8:0:
fs/orangefs/acl.c: In function 'pvfs2_get_acl':
fs/orangefs/pvfs2-kernel.h:203:38: error: 'POSIX_ACL_XATTR_ACCESS' undeclared (first use in this function)
 #define PVFS2_XATTR_NAME_ACL_ACCESS  POSIX_ACL_XATTR_ACCESS
                                      ^
fs/orangefs/acl.c:21:9: note: in expansion of macro 'PVFS2_XATTR_NAME_ACL_ACCESS'
   key = PVFS2_XATTR_NAME_ACL_ACCESS;
         ^
fs/orangefs/pvfs2-kernel.h:203:38: note: each undeclared identifier is reported only once for each function it appears in
 #define PVFS2_XATTR_NAME_ACL_ACCESS  POSIX_ACL_XATTR_ACCESS
                                      ^
fs/orangefs/acl.c:21:9: note: in expansion of macro 'PVFS2_XATTR_NAME_ACL_ACCESS'
   key = PVFS2_XATTR_NAME_ACL_ACCESS;
         ^
fs/orangefs/pvfs2-kernel.h:204:38: error: 'POSIX_ACL_XATTR_DEFAULT' undeclared (first use in this function)
 #define PVFS2_XATTR_NAME_ACL_DEFAULT POSIX_ACL_XATTR_DEFAULT
                                      ^
fs/orangefs/acl.c:24:9: note: in expansion of macro 'PVFS2_XATTR_NAME_ACL_DEFAULT'
   key = PVFS2_XATTR_NAME_ACL_DEFAULT;
         ^
fs/orangefs/acl.c: In function 'pvfs2_set_acl':
fs/orangefs/pvfs2-kernel.h:203:38: error: 'POSIX_ACL_XATTR_ACCESS' undeclared (first use in this function)
 #define PVFS2_XATTR_NAME_ACL_ACCESS  POSIX_ACL_XATTR_ACCESS
                                      ^
fs/orangefs/acl.c:77:10: note: in expansion of macro 'PVFS2_XATTR_NAME_ACL_ACCESS'
   name = PVFS2_XATTR_NAME_ACL_ACCESS;
          ^
fs/orangefs/pvfs2-kernel.h:204:38: error: 'POSIX_ACL_XATTR_DEFAULT' undeclared (first use in this function)
 #define PVFS2_XATTR_NAME_ACL_DEFAULT POSIX_ACL_XATTR_DEFAULT
                                      ^
fs/orangefs/acl.c:101:10: note: in expansion of macro 'PVFS2_XATTR_NAME_ACL_DEFAULT'
   name = PVFS2_XATTR_NAME_ACL_DEFAULT;
          ^

Caused by commit

  97d79299223b ("posix acls: Remove duplicate xattr name definitions")

interacting with the addition of orangefs in the orangefs tree.

I applied this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 9 Dec 2015 12:13:37 +1100
Subject: [PATCH] orangefs: update for POSIX ACL name changes

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/orangefs/pvfs2-kernel.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/orangefs/pvfs2-kernel.h b/fs/orangefs/pvfs2-kernel.h
index 4295e263e25b..9beeddbf8aa9 100644
--- a/fs/orangefs/pvfs2-kernel.h
+++ b/fs/orangefs/pvfs2-kernel.h
@@ -200,8 +200,8 @@ struct client_debug_mask {
 #endif
 #endif
 
-#define PVFS2_XATTR_NAME_ACL_ACCESS  POSIX_ACL_XATTR_ACCESS
-#define PVFS2_XATTR_NAME_ACL_DEFAULT POSIX_ACL_XATTR_DEFAULT
+#define PVFS2_XATTR_NAME_ACL_ACCESS  XATTR_NAME_POSIX_ACL_ACCESS
+#define PVFS2_XATTR_NAME_ACL_DEFAULT XATTR_NAME_POSIX_ACL_DEFAULT
 #define PVFS2_XATTR_NAME_TRUSTED_PREFIX "trusted."
 #define PVFS2_XATTR_NAME_DEFAULT_PREFIX ""
 
-- 
2.6.2

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2015-12-07 22:42 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2015-12-07 22:42 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

Hi Al,

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

In file included from drivers/usb/core/devio.c:37:0:
drivers/usb/core/devio.c: In function 'usbdev_lseek':
include/linux/fs.h:898:36: error: 'PAGE_CACHE_SIZE' undeclared (first use in this function)
 #define MAX_LFS_FILESIZE (((loff_t)PAGE_CACHE_SIZE << (BITS_PER_LONG-1))-1)
                                    ^
drivers/usb/core/devio.c:162:48: note: in expansion of macro 'MAX_LFS_FILESIZE'
  return no_seek_end_llseek(file, offset, orig, MAX_LFS_FILESIZE);
                                                ^
include/linux/fs.h:898:36: note: each undeclared identifier is reported only once for each function it appears in
 #define MAX_LFS_FILESIZE (((loff_t)PAGE_CACHE_SIZE << (BITS_PER_LONG-1))-1)
                                    ^
drivers/usb/core/devio.c:162:48: note: in expansion of macro 'MAX_LFS_FILESIZE'
  return no_seek_end_llseek(file, offset, orig, MAX_LFS_FILESIZE);
                                                ^
drivers/usb/core/devio.c:163:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

Caused by commit

  41fb31e4f962 ("new helper: no_seek_end_llseek()")

PAGE_CACHE_SIZE is defined in linux/pagemap.h which is not included here.
I guess that adding the include to linux/fs.h may have other problems.

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

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2015-05-11  1:26 Stephen Rothwell
@ 2015-05-13  2:26 ` Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2015-05-13  2:26 UTC (permalink / raw)
  To: Al Viro, Jaegeuk Kim
  Cc: linux-next, linux-kernel, Uday Savagaonkar, Theodore Ts'o

[-- Attachment #1: Type: text/plain, Size: 6230 bytes --]

Hi all,

On Mon, 11 May 2015 11:26:12 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> fs/f2fs/namei.c: In function 'f2fs_encrypted_follow_link':
> fs/f2fs/namei.c:336:10: warning: passing argument 2 of 'f2fs_follow_link' from incompatible pointer type
>    return f2fs_follow_link(dentry, nd);
>           ^
> fs/f2fs/namei.c:311:20: note: expected 'void **' but argument is of type 'struct nameidata *'
>  static const char *f2fs_follow_link(struct dentry *dentry, void **cookie)
>                     ^
> fs/f2fs/namei.c:336:3: warning: return discards 'const' qualifier from pointer target type
>    return f2fs_follow_link(dentry, nd);
>    ^
> fs/f2fs/namei.c:379:2: error: implicit declaration of function 'nd_set_link' [-Werror=implicit-function-declaration]
>   nd_set_link(nd, paddr);
>   ^
> fs/f2fs/namei.c: In function 'f2fs_encrypted_put_link':
> fs/f2fs/namei.c:400:3: error: implicit declaration of function 'nd_get_link' [-Werror=implicit-function-declaration]
>    kfree(nd_get_link(nd));
>    ^
> fs/f2fs/namei.c:400:3: warning: passing argument 1 of 'kfree' makes pointer from integer without a cast
> In file included from fs/f2fs/f2fs.h:17:0,
>                  from fs/f2fs/namei.c:19:
> include/linux/slab.h:143:6: note: expected 'const void *' but argument is of type 'int'
>  void kfree(const void *);
>       ^
> fs/f2fs/namei.c: At top level:
> fs/f2fs/namei.c:960:2: warning: initialization from incompatible pointer type
>   .follow_link    = f2fs_encrypted_follow_link,
>   ^
> fs/f2fs/namei.c:960:2: warning: (near initialization for 'f2fs_symlink_inode_operations.follow_link')
> fs/f2fs/namei.c:961:2: warning: initialization from incompatible pointer type
>   .put_link       = f2fs_encrypted_put_link,
>   ^
> fs/f2fs/namei.c:961:2: warning: (near initialization for 'f2fs_symlink_inode_operations.put_link')
> 
> Caused by commits cf41cea5a829 ("new ->follow_link() and ->put_link()
> calling conventions") and 0ad7e33ea980 ("don't pass nameidata to
> ->follow_link()") from teh vfs tree interacting with commit
> 5270e98c341b ("f2fs crypto: add symlink encryption") from the f2fs tree.
> 
> I applied the following merge fix patch (which I suspect is not
> completely correct - especially the f2fs_encrypted_put_link part):
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 11 May 2015 11:22:19 +1000
> Subject: [PATCH] f2fs: merge fix for follow_link and put_link changes
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/f2fs/namei.c | 18 +++++++-----------
>  1 file changed, 7 insertions(+), 11 deletions(-)
> 
> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> index d7ed99ebe95b..42af89cdb9a4 100644
> --- a/fs/f2fs/namei.c
> +++ b/fs/f2fs/namei.c
> @@ -320,8 +320,8 @@ static const char *f2fs_follow_link(struct dentry *dentry, void **cookie)
>  }
>  
>  #ifdef CONFIG_F2FS_FS_ENCRYPTION
> -static void *f2fs_encrypted_follow_link(struct dentry *dentry,
> -						struct nameidata *nd)
> +static const char *f2fs_encrypted_follow_link(struct dentry *dentry,
> +					void **cookie)
>  {
>  	struct page *cpage = NULL;
>  	char *caddr, *paddr = NULL;
> @@ -333,7 +333,7 @@ static void *f2fs_encrypted_follow_link(struct dentry *dentry,
>  	u32 max_size = inode->i_sb->s_blocksize;
>  
>  	if (!f2fs_encrypted_inode(inode))
> -		return f2fs_follow_link(dentry, nd);
> +		return f2fs_follow_link(dentry, cookie);
>  
>  	res = f2fs_setup_fname_crypto(inode);
>  	if (res)
> @@ -341,7 +341,7 @@ static void *f2fs_encrypted_follow_link(struct dentry *dentry,
>  
>  	cpage = read_mapping_page(inode->i_mapping, 0, NULL);
>  	if (IS_ERR(cpage))
> -		return cpage;
> +		return ERR_CAST(cpage);
>  	caddr = kmap(cpage);
>  	caddr[size] = 0;
>  
> @@ -376,12 +376,11 @@ static void *f2fs_encrypted_follow_link(struct dentry *dentry,
>  	/* Null-terminate the name */
>  	if (res <= cstr.len)
>  		paddr[res] = '\0';
> -	nd_set_link(nd, paddr);
>  	if (cpage) {
>  		kunmap(cpage);
>  		page_cache_release(cpage);
>  	}
> -	return NULL;
> +	return *cookie = paddr;
>  errout:
>  	if (cpage) {
>  		kunmap(cpage);
> @@ -391,14 +390,11 @@ errout:
>  	return ERR_PTR(res);
>  }
>  
> -static void f2fs_encrypted_put_link(struct dentry *dentry, struct nameidata *nd,
> -			  void *cookie)
> +static void f2fs_encrypted_put_link(struct dentry *dentry, void *cookie)
>  {
>  	struct page *page = cookie;
>  
> -	if (!page) {
> -		kfree(nd_get_link(nd));
> -	} else {
> +	if (page) {
>  		kunmap(page);
>  		page_cache_release(page);
>  	}
> -- 
> 2.1.4

This merge fix patch is now:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 13 May 2015 11:03:18 +1000
Subject: [PATCH] f2fs: merge fix for follow_link changes

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/f2fs/namei.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index d58df3630b9c..9f7adba1893b 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -859,8 +859,8 @@ out:
 }
 
 #ifdef CONFIG_F2FS_FS_ENCRYPTION
-static void *f2fs_encrypted_follow_link(struct dentry *dentry,
-						struct nameidata *nd)
+static const char *f2fs_encrypted_follow_link(struct dentry *dentry,
+						void **cookie)
 {
 	struct page *cpage = NULL;
 	char *caddr, *paddr = NULL;
@@ -878,7 +878,7 @@ static void *f2fs_encrypted_follow_link(struct dentry *dentry,
 
 	cpage = read_mapping_page(inode->i_mapping, 0, NULL);
 	if (IS_ERR(cpage))
-		return cpage;
+		return ERR_CAST(cpage);
 	caddr = kmap(cpage);
 	caddr[size] = 0;
 
@@ -912,11 +912,10 @@ static void *f2fs_encrypted_follow_link(struct dentry *dentry,
 	/* Null-terminate the name */
 	if (res <= cstr.len)
 		paddr[res] = '\0';
-	nd_set_link(nd, paddr);
 
 	kunmap(cpage);
 	page_cache_release(cpage);
-	return NULL;
+	return *cookie = paddr;
 errout:
 	f2fs_fname_crypto_free_buffer(&pstr);
 	kunmap(cpage);
-- 
2.1.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2015-05-11  1:26 Stephen Rothwell
  2015-05-13  2:26 ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2015-05-11  1:26 UTC (permalink / raw)
  To: Al Viro, Jaegeuk Kim
  Cc: linux-next, linux-kernel, Uday Savagaonkar, Theodore Ts'o

[-- Attachment #1: Type: text/plain, Size: 4496 bytes --]

Hi Al,

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

fs/f2fs/namei.c: In function 'f2fs_encrypted_follow_link':
fs/f2fs/namei.c:336:10: warning: passing argument 2 of 'f2fs_follow_link' from incompatible pointer type
   return f2fs_follow_link(dentry, nd);
          ^
fs/f2fs/namei.c:311:20: note: expected 'void **' but argument is of type 'struct nameidata *'
 static const char *f2fs_follow_link(struct dentry *dentry, void **cookie)
                    ^
fs/f2fs/namei.c:336:3: warning: return discards 'const' qualifier from pointer target type
   return f2fs_follow_link(dentry, nd);
   ^
fs/f2fs/namei.c:379:2: error: implicit declaration of function 'nd_set_link' [-Werror=implicit-function-declaration]
  nd_set_link(nd, paddr);
  ^
fs/f2fs/namei.c: In function 'f2fs_encrypted_put_link':
fs/f2fs/namei.c:400:3: error: implicit declaration of function 'nd_get_link' [-Werror=implicit-function-declaration]
   kfree(nd_get_link(nd));
   ^
fs/f2fs/namei.c:400:3: warning: passing argument 1 of 'kfree' makes pointer from integer without a cast
In file included from fs/f2fs/f2fs.h:17:0,
                 from fs/f2fs/namei.c:19:
include/linux/slab.h:143:6: note: expected 'const void *' but argument is of type 'int'
 void kfree(const void *);
      ^
fs/f2fs/namei.c: At top level:
fs/f2fs/namei.c:960:2: warning: initialization from incompatible pointer type
  .follow_link    = f2fs_encrypted_follow_link,
  ^
fs/f2fs/namei.c:960:2: warning: (near initialization for 'f2fs_symlink_inode_operations.follow_link')
fs/f2fs/namei.c:961:2: warning: initialization from incompatible pointer type
  .put_link       = f2fs_encrypted_put_link,
  ^
fs/f2fs/namei.c:961:2: warning: (near initialization for 'f2fs_symlink_inode_operations.put_link')

Caused by commits cf41cea5a829 ("new ->follow_link() and ->put_link()
calling conventions") and 0ad7e33ea980 ("don't pass nameidata to
->follow_link()") from teh vfs tree interacting with commit
5270e98c341b ("f2fs crypto: add symlink encryption") from the f2fs tree.

I applied the following merge fix patch (which I suspect is not
completely correct - especially the f2fs_encrypted_put_link part):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 11 May 2015 11:22:19 +1000
Subject: [PATCH] f2fs: merge fix for follow_link and put_link changes

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/f2fs/namei.c | 18 +++++++-----------
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index d7ed99ebe95b..42af89cdb9a4 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -320,8 +320,8 @@ static const char *f2fs_follow_link(struct dentry *dentry, void **cookie)
 }
 
 #ifdef CONFIG_F2FS_FS_ENCRYPTION
-static void *f2fs_encrypted_follow_link(struct dentry *dentry,
-						struct nameidata *nd)
+static const char *f2fs_encrypted_follow_link(struct dentry *dentry,
+					void **cookie)
 {
 	struct page *cpage = NULL;
 	char *caddr, *paddr = NULL;
@@ -333,7 +333,7 @@ static void *f2fs_encrypted_follow_link(struct dentry *dentry,
 	u32 max_size = inode->i_sb->s_blocksize;
 
 	if (!f2fs_encrypted_inode(inode))
-		return f2fs_follow_link(dentry, nd);
+		return f2fs_follow_link(dentry, cookie);
 
 	res = f2fs_setup_fname_crypto(inode);
 	if (res)
@@ -341,7 +341,7 @@ static void *f2fs_encrypted_follow_link(struct dentry *dentry,
 
 	cpage = read_mapping_page(inode->i_mapping, 0, NULL);
 	if (IS_ERR(cpage))
-		return cpage;
+		return ERR_CAST(cpage);
 	caddr = kmap(cpage);
 	caddr[size] = 0;
 
@@ -376,12 +376,11 @@ static void *f2fs_encrypted_follow_link(struct dentry *dentry,
 	/* Null-terminate the name */
 	if (res <= cstr.len)
 		paddr[res] = '\0';
-	nd_set_link(nd, paddr);
 	if (cpage) {
 		kunmap(cpage);
 		page_cache_release(cpage);
 	}
-	return NULL;
+	return *cookie = paddr;
 errout:
 	if (cpage) {
 		kunmap(cpage);
@@ -391,14 +390,11 @@ errout:
 	return ERR_PTR(res);
 }
 
-static void f2fs_encrypted_put_link(struct dentry *dentry, struct nameidata *nd,
-			  void *cookie)
+static void f2fs_encrypted_put_link(struct dentry *dentry, void *cookie)
 {
 	struct page *page = cookie;
 
-	if (!page) {
-		kfree(nd_get_link(nd));
-	} else {
+	if (page) {
 		kunmap(page);
 		page_cache_release(page);
 	}
-- 
2.1.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2015-03-24  3:24 ` Stephen Rothwell
@ 2015-03-24 10:44   ` Christoph Hellwig
  0 siblings, 0 replies; 132+ messages in thread
From: Christoph Hellwig @ 2015-03-24 10:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, linux-next, linux-kernel, Christoph Hellwig, Theodore Ts'o

On Tue, Mar 24, 2015 at 02:24:22PM +1100, Stephen Rothwell wrote:
> I am still applying the above patch every day ...

Might be worth folding it.  Al, can you do that?

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2015-03-13  1:02 Stephen Rothwell
@ 2015-03-24  3:24 ` Stephen Rothwell
  2015-03-24 10:44   ` Christoph Hellwig
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2015-03-24  3:24 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, Christoph Hellwig, Theodore Ts'o

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

Hi Al,

On Fri, 13 Mar 2015 12:02:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> fs/ext4/indirect.c: In function 'ext4_ind_direct_IO':
> fs/ext4/indirect.c:653:2: error: implicit declaration of function 'iov_iter_count' [-Werror=implicit-function-declaration]
>   size_t count = iov_iter_count(iter);
>   ^
> 
> Caused by commit 3737c63e1fb0 ("fs: move struct kiocb to fs.h").  aio.h
> used to include uio.h ...
> 
> I wonder if there is more fallout from this include file diet.
> 
> It would have been nice if the more general changes to aio.h were in a
> separate patch.
> 
> I added the following patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Mar 2015 11:56:46 +1100
> Subject: [PATCH] ext4: iov_iter_count needs linux/uio.h
> 
> Fixes: 3737c63e1fb0 ("fs: move struct kiocb to fs.h")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/ext4/indirect.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/ext4/indirect.c b/fs/ext4/indirect.c
> index 33308738a06a..a9369e5d2cc1 100644
> --- a/fs/ext4/indirect.c
> +++ b/fs/ext4/indirect.c
> @@ -20,6 +20,8 @@
>   *	(sct@redhat.com), 1993, 1998
>   */
>  
> +#include <linux/uio.h>
> +
>  #include "ext4_jbd2.h"
>  #include "truncate.h"
>  
> -- 
> 2.1.4

I am still applying the above patch every day ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2015-03-13  1:02 Stephen Rothwell
  2015-03-24  3:24 ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2015-03-13  1:02 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, Christoph Hellwig, Theodore Ts'o

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

Hi Al,

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

fs/ext4/indirect.c: In function 'ext4_ind_direct_IO':
fs/ext4/indirect.c:653:2: error: implicit declaration of function 'iov_iter_count' [-Werror=implicit-function-declaration]
  size_t count = iov_iter_count(iter);
  ^

Caused by commit 3737c63e1fb0 ("fs: move struct kiocb to fs.h").  aio.h
used to include uio.h ...

I wonder if there is more fallout from this include file diet.

It would have been nice if the more general changes to aio.h were in a
separate patch.

I added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 13 Mar 2015 11:56:46 +1100
Subject: [PATCH] ext4: iov_iter_count needs linux/uio.h

Fixes: 3737c63e1fb0 ("fs: move struct kiocb to fs.h")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/ext4/indirect.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/ext4/indirect.c b/fs/ext4/indirect.c
index 33308738a06a..a9369e5d2cc1 100644
--- a/fs/ext4/indirect.c
+++ b/fs/ext4/indirect.c
@@ -20,6 +20,8 @@
  *	(sct@redhat.com), 1993, 1998
  */
 
+#include <linux/uio.h>
+
 #include "ext4_jbd2.h"
 #include "truncate.h"
 
-- 
2.1.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2014-12-10  7:45 Stephen Rothwell
@ 2014-12-11  2:32 ` Al Viro
  0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-12-11  2:32 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Wed, Dec 10, 2014 at 06:45:37PM +1100, Stephen Rothwell wrote:
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (powerpc
> allnoconfig) failed like this:

> diff --git a/fs/nsfs.c b/fs/nsfs.c
> index 0791d086804d..7d98db03c2ce 100644
> --- a/fs/nsfs.c
> +++ b/fs/nsfs.c
> @@ -3,6 +3,8 @@
>  #include <linux/fs.h>
>  #include <linux/proc_ns.h>
>  #include <linux/magic.h>
> +#include <linux/ktime.h>
> +#include <linux/timekeeping.h>

Umm...  Either it's time.h + timekeeping.h or ktime.h alone - ktime.h
pulls timekeeping.h and time.h.  For now I went with the latter variant.
However, I wonder if longer term it would be better to provide a variant
of new_inode_pseudo() that would set the timestamps that way - only two
callers (new_inode() and sock_alloc()) do not do exactly that.  Oh, well -
that can wait...

For now, fixed and force-pushed

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2014-12-10  7:45 Stephen Rothwell
  2014-12-11  2:32 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2014-12-10  7:45 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

Hi Al,

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

fs/nsfs.c: In function 'ns_get_path':
fs/nsfs.c:83:2: error: implicit declaration of function 'current_kernel_time' [-Werror=implicit-function-declaration]
  inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
  ^
fs/nsfs.c:83:51: error: incompatible types when assigning to type 'struct timespec' from type 'int'
  inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
                                                   ^

Caused by commit 87fb64a6c1f7 ("take the targets of /proc/*/ns/*
symlinks to separate fs").

I have applied the following patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 10 Dec 2014 18:37:32 +1100
Subject: [PATCH] nsfs: need include/ktime.h and timekeeping.h for CURRENT_TIME

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/nsfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/nsfs.c b/fs/nsfs.c
index 0791d086804d..7d98db03c2ce 100644
--- a/fs/nsfs.c
+++ b/fs/nsfs.c
@@ -3,6 +3,8 @@
 #include <linux/fs.h>
 #include <linux/proc_ns.h>
 #include <linux/magic.h>
+#include <linux/ktime.h>
+#include <linux/timekeeping.h>
 
 static struct vfsmount *nsfs_mnt;
 
-- 
2.1.3

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2014-04-22  1:26 Stephen Rothwell
@ 2014-04-23  0:33 ` Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2014-04-23  0:33 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

Hi Al,

On Tue, 22 Apr 2014 11:26:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/nfs/direct.c: In function 'nfs_direct_read_schedule_iovec':
> fs/nfs/direct.c:382:4: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
>     vfree(pagevec);
>     ^
> 
> Caused by commit 2703e4cd2d57 ("new helper: iov_iter_get_pages_alloc()").
> 
> I have used the vfs tree from next-20140417 for today.

With mixed feelings, I have added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 23 Apr 2014 10:29:35 +1000
Subject: [PATCH] vfs: using vfree requires including vmalloc.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/nfs/direct.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index 775cc5031eea..9116d9a49406 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -47,6 +47,7 @@
 #include <linux/slab.h>
 #include <linux/task_io_accounting_ops.h>
 #include <linux/module.h>
+#include <linux/vmalloc.h>
 
 #include <linux/nfs_fs.h>
 #include <linux/nfs_page.h>
-- 
1.9.2

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2014-04-22  1:26 Stephen Rothwell
  2014-04-23  0:33 ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2014-04-22  1:26 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

Hi Al,

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

fs/nfs/direct.c: In function 'nfs_direct_read_schedule_iovec':
fs/nfs/direct.c:382:4: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
    vfree(pagevec);
    ^

Caused by commit 2703e4cd2d57 ("new helper: iov_iter_get_pages_alloc()").

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

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2013-11-07  0:30 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2013-11-07  0:30 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

Hi Al,

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

fs/built-in.o: In function `dump_align':
file.c:(.text+0x4a7e8): undefined reference to `__aeabi_ldivmod'

Presumably caused by commit 3812867c5fcb ("new helper: dump_align()").  I
assume that there is a 64/32 bit mod operation in there somewhere?

I used the vfs tree from next-20131106 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au


[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2013-09-09  2:33 Stephen Rothwell
@ 2013-09-09  8:54 ` Ian Kent
  0 siblings, 0 replies; 132+ messages in thread
From: Ian Kent @ 2013-09-09  8:54 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Al Viro, linux-next, linux-kernel

On Mon, 2013-09-09 at 12:33 +1000, Stephen Rothwell wrote:
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/autofs4/dev-ioctl.c: In function 'find_autofs_mount':
> fs/autofs4/dev-ioctl.c:193:2: error: implicit declaration of function 'user_path_mntpointat' [-Werror=implicit-function-declaration]
>   int err = user_path_mntpointat(AT_FDCWD, pathname, 0, &path);
>   ^
> 
> Caused by commit b3a19b078049 ("autofs4 - fix device ioctl mount lookup").
> 
> I have used the vfs tree form next-20130906 for today.

As far as I can see that is already fixed in viro/vfs.git for-next.

AFAICT the problem arose because there was a difference (missed) between
what I posted and how Al wanted to do it.

Ian

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2013-09-09  2:33 Stephen Rothwell
  2013-09-09  8:54 ` Ian Kent
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2013-09-09  2:33 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, Ian Kent

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

Hi Al,

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

fs/autofs4/dev-ioctl.c: In function 'find_autofs_mount':
fs/autofs4/dev-ioctl.c:193:2: error: implicit declaration of function 'user_path_mntpointat' [-Werror=implicit-function-declaration]
  int err = user_path_mntpointat(AT_FDCWD, pathname, 0, &path);
  ^

Caused by commit b3a19b078049 ("autofs4 - fix device ioctl mount lookup").

I have used the vfs tree form next-20130906 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2013-06-24  1:35 Stephen Rothwell
@ 2013-06-24  9:34 ` Al Viro
  0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2013-06-24  9:34 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Mon, Jun 24, 2013 at 11:35:40AM +1000, Stephen Rothwell wrote:
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from arch/powerpc/xmon/xmon.c:41:0:
> arch/powerpc/include/asm/spu.h:245:43: error: 'struct coredump_params' declared inside parameter list [-Werror]
>   int (*coredump_extra_notes_write)(struct coredump_params *cprm);
>                                            ^
> arch/powerpc/include/asm/spu.h:245:43: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]
> 
> Caused by commit 27e58d7e7e6d ("[needs split] switch to saner coredump
> primitives").  Presumably, arch/powerpc/include/asm/spu.h needs to
> include linux/binfmts.h or just forward declare "struct coredump_params".

Mea culpa - it's missing forward + missing include of linux/coredump.h
in spufs/coredump.c.  I've fixed that and moved that commit to the end
of queue - it *does* need a splitup, so it'll get replaced with
several commits anyway.

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2013-06-24  1:35 Stephen Rothwell
  2013-06-24  9:34 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2013-06-24  1:35 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

Hi Al,

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

In file included from arch/powerpc/xmon/xmon.c:41:0:
arch/powerpc/include/asm/spu.h:245:43: error: 'struct coredump_params' declared inside parameter list [-Werror]
  int (*coredump_extra_notes_write)(struct coredump_params *cprm);
                                           ^
arch/powerpc/include/asm/spu.h:245:43: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]

Caused by commit 27e58d7e7e6d ("[needs split] switch to saner coredump
primitives").  Presumably, arch/powerpc/include/asm/spu.h needs to
include linux/binfmts.h or just forward declare "struct coredump_params".

I have used the vfs tree from next-20130621 for today
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2013-05-01  2:22 Stephen Rothwell
@ 2013-05-01 13:13 ` J. Bruce Fields
  0 siblings, 0 replies; 132+ messages in thread
From: J. Bruce Fields @ 2013-05-01 13:13 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, linux-next, linux-kernel, Simo Sorce, David Howells

On Wed, May 01, 2013 at 12:22:27PM +1000, Stephen Rothwell wrote:
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> net/sunrpc/auth_gss/svcauth_gss.c: In function 'write_gssp':
> net/sunrpc/auth_gss/svcauth_gss.c:1329:9: error: implicit declaration of function 'PDE' [-Werror=implicit-function-declaration]
> net/sunrpc/auth_gss/svcauth_gss.c:1329:53: error: invalid type argument of '->' (have 'int')
> net/sunrpc/auth_gss/svcauth_gss.c: In function 'read_gssp':
> net/sunrpc/auth_gss/svcauth_gss.c:1357:53: error: invalid type argument of '->' (have 'int')
> 
> Caused by commit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server
> RPCGSS authentication") from the nfsd tree interacting with commit
> c3f2cb25be4f ("proc: Make the PROC_I() and PDE() macros internal to
> procfs") from the vfs tree.
> 
> I applied the following merge fix patch (there may be a better way).

Looks fine to me, thanks!

--b.

> 
> From 62a0e3a08844eeeb6d85fb45d85c2f80d7de2797 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 1 May 2013 12:19:43 +1000
> Subject: [PATCH] SUNRPC: update for PDE removal
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  net/sunrpc/auth_gss/svcauth_gss.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
> index b70ac1c..89ef709 100644
> --- a/net/sunrpc/auth_gss/svcauth_gss.c
> +++ b/net/sunrpc/auth_gss/svcauth_gss.c
> @@ -1326,7 +1326,7 @@ static int wait_for_gss_proxy(struct net *net)
>  static ssize_t write_gssp(struct file *file, const char __user *buf,
>  			 size_t count, loff_t *ppos)
>  {
> -	struct net *net = PDE(file->f_path.dentry->d_inode)->data;
> +	struct net *net = PDE_DATA(file->f_path.dentry->d_inode);
>  	char tbuf[20];
>  	unsigned long i;
>  	int res;
> @@ -1354,7 +1354,7 @@ static ssize_t write_gssp(struct file *file, const char __user *buf,
>  static ssize_t read_gssp(struct file *file, char __user *buf,
>  			 size_t count, loff_t *ppos)
>  {
> -	struct net *net = PDE(file->f_path.dentry->d_inode)->data;
> +	struct net *net = PDE_DATA(file->f_path.dentry->d_inode);
>  	unsigned long p = *ppos;
>  	char tbuf[10];
>  	size_t len;
> -- 
> 1.8.1
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2013-05-01  2:22 Stephen Rothwell
  2013-05-01 13:13 ` J. Bruce Fields
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2013-05-01  2:22 UTC (permalink / raw)
  To: Al Viro
  Cc: linux-next, linux-kernel, Simo Sorce, J. Bruce Fields, David Howells

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

Hi Al,

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

net/sunrpc/auth_gss/svcauth_gss.c: In function 'write_gssp':
net/sunrpc/auth_gss/svcauth_gss.c:1329:9: error: implicit declaration of function 'PDE' [-Werror=implicit-function-declaration]
net/sunrpc/auth_gss/svcauth_gss.c:1329:53: error: invalid type argument of '->' (have 'int')
net/sunrpc/auth_gss/svcauth_gss.c: In function 'read_gssp':
net/sunrpc/auth_gss/svcauth_gss.c:1357:53: error: invalid type argument of '->' (have 'int')

Caused by commit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server
RPCGSS authentication") from the nfsd tree interacting with commit
c3f2cb25be4f ("proc: Make the PROC_I() and PDE() macros internal to
procfs") from the vfs tree.

I applied the following merge fix patch (there may be a better way).

From 62a0e3a08844eeeb6d85fb45d85c2f80d7de2797 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 1 May 2013 12:19:43 +1000
Subject: [PATCH] SUNRPC: update for PDE removal

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/sunrpc/auth_gss/svcauth_gss.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
index b70ac1c..89ef709 100644
--- a/net/sunrpc/auth_gss/svcauth_gss.c
+++ b/net/sunrpc/auth_gss/svcauth_gss.c
@@ -1326,7 +1326,7 @@ static int wait_for_gss_proxy(struct net *net)
 static ssize_t write_gssp(struct file *file, const char __user *buf,
 			 size_t count, loff_t *ppos)
 {
-	struct net *net = PDE(file->f_path.dentry->d_inode)->data;
+	struct net *net = PDE_DATA(file->f_path.dentry->d_inode);
 	char tbuf[20];
 	unsigned long i;
 	int res;
@@ -1354,7 +1354,7 @@ static ssize_t write_gssp(struct file *file, const char __user *buf,
 static ssize_t read_gssp(struct file *file, char __user *buf,
 			 size_t count, loff_t *ppos)
 {
-	struct net *net = PDE(file->f_path.dentry->d_inode)->data;
+	struct net *net = PDE_DATA(file->f_path.dentry->d_inode);
 	unsigned long p = *ppos;
 	char tbuf[10];
 	size_t len;
-- 
1.8.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2013-04-08  1:15 Stephen Rothwell
@ 2013-04-09 15:49 ` Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2013-04-09 15:49 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

Hi Al,

On 2013-04-08 11:15, Stephen Rothwell wrote:
>
> 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 
> 'kvm_init':
> arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:2990:2: error:
> assignment of member 'owner' in read-only object
> arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:2991:2: error:
> assignment of member 'owner' in read-only object
> arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:2992:2: error:
> assignment of member 'owner' in read-only object
>
> Caused by commit d612df096dce ("constify a bunch of struct
> file_operations instances").  Grep is your friend ...
>
> I have used the vfs tree from next-230130405 for today.

Ping?
-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2013-04-08  1:15 Stephen Rothwell
  2013-04-09 15:49 ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2013-04-08  1:15 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

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 'kvm_init':
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:2990:2: error: assignment of member 'owner' in read-only object
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:2991:2: error: assignment of member 'owner' in read-only object
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:2992:2: error: assignment of member 'owner' in read-only object

Caused by commit d612df096dce ("constify a bunch of struct
file_operations instances").  Grep is your friend ...

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

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2013-04-03  0:22 Stephen Rothwell
@ 2013-04-03  1:14 ` Al Viro
  0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2013-04-03  1:14 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Wed, Apr 03, 2013 at 11:22:35AM +1100, Stephen Rothwell wrote:
> And many, many more.
> 
> Caused by commit 1f4fbcb8700c ("create_proc_cpu_mask() doesn't need an
> argument...").  Please build test this stuff *before* publishing it.  :-(

"Remember to push the fixes", actually ;-/

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2013-04-03  0:22 Stephen Rothwell
  2013-04-03  1:14 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2013-04-03  0:22 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

Hi Al,

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

In file included from arch/powerpc/oprofile/../../../drivers/oprofile/timer_int.c:14:0:
include/linux/profile.h: In function 'create_prof_cpu_mask':
include/linux/profile.h:34:1: error: empty declaration [-Werror]
include/linux/profile.h:41:12: error: storage class specified for parameter 'prof_on'
include/linux/profile.h:41:12: error: section attribute not allowed for 'prof_on'
include/linux/profile.h:57:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
include/linux/profile.h:65:1: error: empty declaration [-Werror]
include/linux/profile.h:66:1: error: empty declaration [-Werror]
include/linux/profile.h:85:1: error: empty declaration [-Werror]

And many, many more.

Caused by commit 1f4fbcb8700c ("create_proc_cpu_mask() doesn't need an
argument...").  Please build test this stuff *before* publishing it.  :-(

I have used the vfs tree from next-20130328 again fro today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2013-04-02  0:26 Stephen Rothwell
@ 2013-04-02  0:39 ` Al Viro
  0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2013-04-02  0:39 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Tue, Apr 02, 2013 at 11:26:27AM +1100, Stephen Rothwell wrote:
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> arch/powerpc/kernel/lparcfg.c:44:31: error: 'proc_ppc64_lparcfg' defined but not used [-Werror=unused-variable]
> cc1: all warnings being treated as errors
> 
> Caused by commit dfda3a48f2e7 ("lparcfg: don't bother saving pointer to
> proc_dir_entry").
> 
> I have used the vfs tree form next-20130328 for today.

... or just remove the variable ;-)  Fixed and pushed.

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2013-04-02  0:26 Stephen Rothwell
  2013-04-02  0:39 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2013-04-02  0:26 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

Hi Al,

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

arch/powerpc/kernel/lparcfg.c:44:31: error: 'proc_ppc64_lparcfg' defined but not used [-Werror=unused-variable]
cc1: all warnings being treated as errors

Caused by commit dfda3a48f2e7 ("lparcfg: don't bother saving pointer to
proc_dir_entry").

I have used the vfs tree form next-20130328 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2012-07-16  0:59 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2012-07-16  0:59 UTC (permalink / raw)
  To: Al Viro
  Cc: linux-next, linux-kernel, Jan Kara, Christoph Hellwig,
	Steven Whitehouse, Dave Kleikamp

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

Hi Al,

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

fs/ext2/super.c: In function 'ext2_sync_fs':
fs/ext2/super.c:1191:2: error: implicit declaration of function 'dquot_writeback_dquots' [-Werror=implicit-function-declaration]
fs/ext3/super.c: In function 'ext3_sync_fs':
fs/ext3/super.c:2534:2: error: implicit declaration of function 'dquot_writeback_dquots' [-Werror=implicit-function-declaration]
fs/ext4/super.c: In function 'ext4_sync_fs':
fs/ext4/super.c:4493:2: error: implicit declaration of function 'dquot_writeback_dquots' [-Werror=implicit-function-declaration]

Caused by commits 05566b558a47 ("quota: Move quota syncing to ->sync_fs
method") and ad04033e79d2 ("quota: Split dquot_quota_sync() to writeback
and cache flushing part").  Please do build testing with and without
CONFIG QUOTA for quota changes ...

I have used the vfs tree from next-20120713 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2012-05-31  0:51 Stephen Rothwell
@ 2012-05-31  1:02 ` Al Viro
  0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2012-05-31  1:02 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Thu, May 31, 2012 at 10:51:08AM +1000, Stephen Rothwell wrote:
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from include/linux/stat.h:6:0,
>                  from include/linux/module.h:10,
>                  from init/main.c:13:
> arch/powerpc/include/asm/stat.h:33:2: error: expected specifier-qualifier-list before 'unisgned'
> 
> and many, many more. :-(
> 
> Caused by commit 9f240ea8060e ("powerpc: get rid of nlink_t uses, switch
> to explicitly-sized type").
> 
> I have used the vfs tree from next-20120529 for today.

Grr...  s/unisgned/unsigned/, of course - in two lines in there.  With that
it seems to build...

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2012-05-31  0:51 Stephen Rothwell
  2012-05-31  1:02 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2012-05-31  0:51 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

Hi Al,

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

In file included from include/linux/stat.h:6:0,
                 from include/linux/module.h:10,
                 from init/main.c:13:
arch/powerpc/include/asm/stat.h:33:2: error: expected specifier-qualifier-list before 'unisgned'

and many, many more. :-(

Caused by commit 9f240ea8060e ("powerpc: get rid of nlink_t uses, switch
to explicitly-sized type").

I have used the vfs tree from next-20120529 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2012-01-03  1:43 Stephen Rothwell
@ 2012-01-03 13:39 ` Jan Kara
  0 siblings, 0 replies; 132+ messages in thread
From: Jan Kara @ 2012-01-03 13:39 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, linux-next, linux-kernel, Mikulas Patocka, Jan Kara

  Hi,

On Tue 03-01-12 12:43:31, Stephen Rothwell wrote:
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/super.c:230:13: error: static declaration of 'put_super' follows non-static declaration
> include/linux/fs.h:2493:13: note: previous declaration of 'put_super' was here
> 
> Caused by commit eab99e355c00 ("trim fs/internal.h") interacting with
> commit 4789fd4495a4 ("quota: Fix deadlock with suspend and quotas") from
> the ext3 tree.
> 
> I applied the following (probably not the best) merge fix patch for today:
  Thanks Stephen! Al, how shall we resolve this? You wrote you can provide
a VFS helper like get_super() which will also guarantee that the fs is
unfrozen.  That could be used in quotactl_block() and fsync_bdev(). If you
plan to do this for 3.3 then I can just remove the quota fix and let you
do it.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2012-01-03  1:43 Stephen Rothwell
  2012-01-03 13:39 ` Jan Kara
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2012-01-03  1:43 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, Mikulas Patocka, Jan Kara

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

Hi Al,

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

fs/super.c:230:13: error: static declaration of 'put_super' follows non-static declaration
include/linux/fs.h:2493:13: note: previous declaration of 'put_super' was here

Caused by commit eab99e355c00 ("trim fs/internal.h") interacting with
commit 4789fd4495a4 ("quota: Fix deadlock with suspend and quotas") from
the ext3 tree.

I applied the following (probably not the best) merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 3 Jan 2012 12:38:21 +1100
Subject: [PATCH] fs: make put_super global again

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/super.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/super.c b/fs/super.c
index 3682e6c..cb6d718 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -227,7 +227,7 @@ static void __put_super(struct super_block *sb)
  *	Drops a temporary reference, frees superblock if there's no
  *	references left.
  */
-static void put_super(struct super_block *sb)
+void put_super(struct super_block *sb)
 {
 	spin_lock(&sb_lock);
 	__put_super(sb);
-- 
1.7.8.197.g73c6b

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2011-12-22  0:15 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2011-12-22  0:15 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, James Morris

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

Hi Al,

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

In file included from ipc/util.c:28:0:
include/linux/security.h: In function 'security_real_capable':
include/linux/security.h:1886:25: error: dereferencing pointer to incomplete type
include/linux/security.h:1886:25: error: dereferencing pointer to incomplete type
include/linux/security.h:1886:25: error: dereferencing pointer to incomplete type
include/linux/security.h:1886:25: error: dereferencing pointer to incomplete type
include/linux/security.h:1886:25: error: dereferencing pointer to incomplete type

And so on ... These are the references to __task_cred() which dereferences
a "struct task_struct *".  Adding an include of linux/sched.h back to
linux/security.h (which was removed by commit ae1a442f9d95 ("trim
security.h")) results in this error (to be fair, the include of
linux-sched.h really belongs in cred.h):

arch/powerpc/platforms/cell/spu_syscalls.c:68:22: error: expected ')' before 'const'

Which was caused by commit 2dbc0a0f41d4 ("switch spu_create(2) to use of
SYSCALL4, make it use umode_t").  That commit (along with a whole string
of others around it) was supposedly authored July 27, 2011, so it would
have been nice to see them earlier then this in linux-next.  :-(

I have used the vfs tree from next-20111216 (which is unfortunately
empty) again for today.

BTW, the x86_64 allmodconfig build (with out the sched.h include
restored) does not get any of these errors, so sches.h must be being
indirectly included, so you are not saving anything on x86_64 by removing
the sched.h include from security.h.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2011-12-19  1:06 Stephen Rothwell
@ 2011-12-19  1:12 ` Al Viro
  0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2011-12-19  1:12 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Mon, Dec 19, 2011 at 12:06:13PM +1100, Stephen Rothwell wrote:

> And many more similar.
> 
> Probably caused by commit 3073cb2e813c ("trim security.h") which
> presumably removed an include file that was including err.h :-(
> 
> I have used the vfs tree from next-20111216 for today.

Fixed and pushed...

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2011-12-19  1:06 Stephen Rothwell
  2011-12-19  1:12 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2011-12-19  1:06 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

Hi Al,

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

In file included from include/linux/tracehook.h:51:0,
                 from arch/powerpc/kernel/ptrace.c:25:
include/linux/security.h: In function 'securityfs_create_dir':
include/linux/security.h:3003:2: error: implicit declaration of function 'ERR_PTR' [-Werror=implicit-function-declaration]
include/linux/security.h:3003:2: error: return makes pointer from integer without a cast [-Werror]
include/linux/security.h: In function 'securityfs_create_file':
include/linux/security.h:3012:2: error: return makes pointer from integer without a cast [-Werror]
In file included from include/linux/fs.h:2283:0,
                 from include/linux/trace_seq.h:4,
                 from include/linux/ftrace_event.h:5,
                 from include/trace/syscall.h:6,
                 from arch/powerpc/kernel/ptrace.c:32:
include/linux/err.h: At top level:
include/linux/err.h:22:35: error: conflicting types for 'ERR_PTR'
include/linux/security.h:3003:9: note: previous implicit declaration of 'ERR_PTR' was here

And many more similar.

Probably caused by commit 3073cb2e813c ("trim security.h") which
presumably removed an include file that was including err.h :-(

I have used the vfs tree from next-20111216 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2011-07-25  3:20 ` Stephen Rothwell
@ 2011-07-25 18:26   ` Trond Myklebust
  0 siblings, 0 replies; 132+ messages in thread
From: Trond Myklebust @ 2011-07-25 18:26 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Al Viro

On Mon, 2011-07-25 at 13:20 +1000, Stephen Rothwell wrote: 
> Hi all,
> 
> On Sat, 16 Jul 2011 16:44:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the vfs tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > fs/nfs/read.c: In function 'nfs_do_read':
> > fs/nfs/read.c:246:42: error: 'struct nfs_open_context' has no member named 'path'
> > 
> > Caused by commit 6e4efd568574 ("NFS: Clean up nfs_read_rpcsetup and
> > nfs_write_rpcsetup") from the nfs tree interacting with commit
> > b98aad31afdc ("nfs_open_context doesn't need struct path either").
> > 
> > I have applied the following merge fixup patch:
> 
> This patch (repeasted here) is now required after mergeing the nfs tree
> and Linus' tree:

Thanks Stephen!

I've merged the contents of Linus' current tree into my NFS development
branch, and applied your patch as part of the merge commit.

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2011-07-16  6:44 Stephen Rothwell
@ 2011-07-25  3:20 ` Stephen Rothwell
  2011-07-25 18:26   ` Trond Myklebust
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2011-07-25  3:20 UTC (permalink / raw)
  To: Trond Myklebust; +Cc: linux-next, linux-kernel, Al Viro

Hi all,

On Sat, 16 Jul 2011 16:44:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/nfs/read.c: In function 'nfs_do_read':
> fs/nfs/read.c:246:42: error: 'struct nfs_open_context' has no member named 'path'
> 
> Caused by commit 6e4efd568574 ("NFS: Clean up nfs_read_rpcsetup and
> nfs_write_rpcsetup") from the nfs tree interacting with commit
> b98aad31afdc ("nfs_open_context doesn't need struct path either").
> 
> I have applied the following merge fixup patch:

This patch (repeasted here) is now required after mergeing the nfs tree
and Linus' tree:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Sat, 16 Jul 2011 16:32:06 +1000
Subject: [PATCH] vfs/nfs: fixup for nfs_open_context change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/nfs/read.c |    2 +-
 fs/nfs/write.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/read.c b/fs/nfs/read.c
index 3170712..2171c04 100644
--- a/fs/nfs/read.c
+++ b/fs/nfs/read.c
@@ -243,7 +243,7 @@ static void nfs_read_rpcsetup(struct nfs_page *req, struct nfs_read_data *data,
 static int nfs_do_read(struct nfs_read_data *data,
 		const struct rpc_call_ops *call_ops)
 {
-	struct inode *inode = data->args.context->path.dentry->d_inode;
+	struct inode *inode = data->args.context->dentry->d_inode;
 
 	return nfs_initiate_read(data, NFS_CLIENT(inode), call_ops);
 }
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 2d2c773..ebed518 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -889,7 +889,7 @@ static int nfs_do_write(struct nfs_write_data *data,
 		const struct rpc_call_ops *call_ops,
 		int how)
 {
-	struct inode *inode = data->args.context->path.dentry->d_inode;
+	struct inode *inode = data->args.context->dentry->d_inode;
 
 	return nfs_initiate_write(data, NFS_CLIENT(inode), call_ops, how);
 }
-- 
1.7.5.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2011-07-16  6:44 Stephen Rothwell
  2011-07-25  3:20 ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2011-07-16  6:44 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, Trond Myklebust

Hi Al,

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

fs/nfs/read.c: In function 'nfs_do_read':
fs/nfs/read.c:246:42: error: 'struct nfs_open_context' has no member named 'path'

Caused by commit 6e4efd568574 ("NFS: Clean up nfs_read_rpcsetup and
nfs_write_rpcsetup") from the nfs tree interacting with commit
b98aad31afdc ("nfs_open_context doesn't need struct path either").

I have applied the following merge fixup patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Sat, 16 Jul 2011 16:32:06 +1000
Subject: [PATCH] vfs/nfs: fixup for nfs_open_context change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/nfs/read.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfs/read.c b/fs/nfs/read.c
index 3170712..2171c04 100644
--- a/fs/nfs/read.c
+++ b/fs/nfs/read.c
@@ -243,7 +243,7 @@ static void nfs_read_rpcsetup(struct nfs_page *req, struct nfs_read_data *data,
 static int nfs_do_read(struct nfs_read_data *data,
 		const struct rpc_call_ops *call_ops)
 {
-	struct inode *inode = data->args.context->path.dentry->d_inode;
+	struct inode *inode = data->args.context->dentry->d_inode;
 
 	return nfs_initiate_read(data, NFS_CLIENT(inode), call_ops);
 }
-- 
1.7.5.4

I then got:

fs/nfs/write.c: In function 'nfs_do_write':
fs/nfs/write.c:892:42: error: 'struct nfs_open_context' has no member named 'path'

So I added the following patch as well:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Sat, 16 Jul 2011 16:39:22 +1000
Subject: [PATCH] vfs/nfs: another fixup for nfs_open_context change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/nfs/write.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 2d2c773..ebed518 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -889,7 +889,7 @@ static int nfs_do_write(struct nfs_write_data *data,
 		const struct rpc_call_ops *call_ops,
 		int how)
 {
-	struct inode *inode = data->args.context->path.dentry->d_inode;
+	struct inode *inode = data->args.context->dentry->d_inode;
 
 	return nfs_initiate_write(data, NFS_CLIENT(inode), call_ops, how);
 }
-- 
1.7.5.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2011-07-16  6:36 Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2011-07-16  6:36 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

Hi Al,

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

arch/powerpc/platforms/cell/spufs/syscalls.c: In function 'do_spu_create':
arch/powerpc/platforms/cell/spufs/syscalls.c:69:2: error: 'ret' undeclared (first use in this function)
arch/powerpc/platforms/cell/spufs/syscalls.c:71:3: error: 'nd' undeclared (first use in this function)

Caused by commit 05a3ade623fa ("switch do_spufs_create() to
user_path_create(), fix double-unlock").

I have used the vfs tree from next-20110707 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2010-06-22  1:22 Stephen Rothwell
@ 2010-08-04  1:50 ` Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2010-08-04  1:50 UTC (permalink / raw)
  To: Al Viro
  Cc: linux-next, linux-kernel, Sripathi Kodi, Eric Van Hensbergen,
	Christoph Hellwig

Hi Al,

On Tue, 22 Jun 2010 11:22:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
> fs/9p/vfs_inode.c:1056: error: implicit declaration of function 'inode_setattr'
> 
> Caused by commit 463942d48d7f05812f0d6426dd8051ff53ea24a3 ("9p: Implement
> client side of setattr for 9P2000.L protocol") from the v9fs tree
> interacting with commit 3d9bf66940b6001a30aa30d5ac9f816326d9b3a0 ("remove
> inode_setattr") from the vfs tree.
> 
> I have applied the following patch (using the changes in the above vfs
> tree commit as a guide) as a merge fix for today, but am not sure if it
> is correct.  I assume that this (or something similar) could be applied
> to the v9fs tree now - is that correct Christoph?

Linus has merged the v9fs tree now, so this patch can be applied to the
vfs tree.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 22 Jun 2010 11:15:01 +1000
Subject: [PATCH] v9fs: fixup for inode_setattr being removed

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/9p/vfs_inode.c |   15 ++++++++++++---
 1 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index f027a42..2ec7bfa 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -1052,10 +1052,19 @@ static int v9fs_vfs_setattr_dotl(struct dentry *dentry, struct iattr *iattr)
 		return PTR_ERR(fid);
 
 	retval = p9_client_setattr(fid, &p9attr);
-	if (retval >= 0)
-		retval = inode_setattr(dentry->d_inode, iattr);
+	if (retval < 0)
+		return retval;
 
-	return retval;
+	if ((iattr->ia_valid & ATTR_SIZE) &&
+	    iattr->ia_size != i_size_read(dentry->d_inode)) {
+		retval = vmtruncate(dentry->d_inode, iattr->ia_size);
+		if (retval)
+			return retval;
+	}
+
+	setattr_copy(dentry->d_inode, iattr);
+	mark_inode_dirty(dentry->d_inode);
+	return 0;
 }
 
 /**
-- 
1.7.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
       [not found] ` <20100719102520.a2d4f103.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
@ 2010-08-04  1:47   ` Stephen Rothwell
  0 siblings, 0 replies; 132+ messages in thread
From: Stephen Rothwell @ 2010-08-04  1:47 UTC (permalink / raw)
  To: Al Viro
  Cc: linux-next-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Suresh Jayaraman,
	Steve French, linux-cifs-u79uwXL29TY76Z2rM5mHXA

Hi Al,

On Mon, 19 Jul 2010 10:25:20 +1000 Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org> wrote:
>
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/cifs/cifsfs.c:498: error: unknown field 'clear_inode' specified in initializer
> 
> Caused by commit 139f224817a203ff434eda5e6d3f457bc1579f27 ("cifs: define
> inode-level cache object and register them") from the cifs tree
> interacting with commit a8036d5aec0547a2bd7e3040c69bd172e474d860
> ("convert remaining ->clear_inode() to ->evict_inode()") from the vfs
> tree.
> 
> I added the following merge fix patch (by effectively copy and paste from
> some of the other file system fixups in the vfs commit).  I have no idea
> if this is correct - someone should check.  I can carry this patch as
> necessary.

The cifs tree has been merged by Linus, so this patch can be applied to
the vfs tree, now.

From: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
Date: Mon, 19 Jul 2010 10:15:47 +1000
Subject: [PATCH] cifs: fix for clear_inode -> evict_inode API change

Signed-off-by: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
---
 fs/cifs/cifsfs.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index ba893b9..2fc5ed1 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -330,8 +330,10 @@ cifs_destroy_inode(struct inode *inode)
 }
 
 static void
-cifs_clear_inode(struct inode *inode)
+cifs_evict_inode(struct inode *inode)
 {
+	truncate_inode_pages(&inode->i_data, 0);
+	end_writeback(inode);
 	cifs_fscache_release_inode_cookie(inode);
 }
 
@@ -495,7 +497,7 @@ static const struct super_operations cifs_super_ops = {
 	.alloc_inode = cifs_alloc_inode,
 	.destroy_inode = cifs_destroy_inode,
 	.drop_inode	= cifs_drop_inode,
-	.clear_inode	= cifs_clear_inode,
+	.evict_inode	= cifs_evict_inode,
 /*	.delete_inode	= cifs_delete_inode,  */  /* Do not need above
 	function unless later we add lazy close of inodes or unless the
 	kernel forgets to call us with the same number of releases (closes)
-- 
1.7.1

-- 
Cheers,
Stephen Rothwell                    sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2010-07-19  0:25 Stephen Rothwell
       [not found] ` <20100719102520.a2d4f103.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2010-07-19  0:25 UTC (permalink / raw)
  To: Al Viro
  Cc: linux-next, linux-kernel, Suresh Jayaraman, Steve French, linux-cifs

Hi Al,

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

fs/cifs/cifsfs.c:498: error: unknown field 'clear_inode' specified in initializer

Caused by commit 139f224817a203ff434eda5e6d3f457bc1579f27 ("cifs: define
inode-level cache object and register them") from the cifs tree
interacting with commit a8036d5aec0547a2bd7e3040c69bd172e474d860
("convert remaining ->clear_inode() to ->evict_inode()") from the vfs
tree.

I added the following merge fix patch (by effectively copy and paste from
some of the other file system fixups in the vfs commit).  I have no idea
if this is correct - someone should check.  I can carry this patch as
necessary.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 19 Jul 2010 10:15:47 +1000
Subject: [PATCH] cifs: fix for clear_inode -> evict_inode API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/cifs/cifsfs.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index ba893b9..2fc5ed1 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -330,8 +330,10 @@ cifs_destroy_inode(struct inode *inode)
 }
 
 static void
-cifs_clear_inode(struct inode *inode)
+cifs_evict_inode(struct inode *inode)
 {
+	truncate_inode_pages(&inode->i_data, 0);
+	end_writeback(inode);
 	cifs_fscache_release_inode_cookie(inode);
 }
 
@@ -495,7 +497,7 @@ static const struct super_operations cifs_super_ops = {
 	.alloc_inode = cifs_alloc_inode,
 	.destroy_inode = cifs_destroy_inode,
 	.drop_inode	= cifs_drop_inode,
-	.clear_inode	= cifs_clear_inode,
+	.evict_inode	= cifs_evict_inode,
 /*	.delete_inode	= cifs_delete_inode,  */  /* Do not need above
 	function unless later we add lazy close of inodes or unless the
 	kernel forgets to call us with the same number of releases (closes)
-- 
1.7.1


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2010-07-12  2:24 Stephen Rothwell
@ 2010-07-12  5:31 ` Ryusuke Konishi
  0 siblings, 0 replies; 132+ messages in thread
From: Ryusuke Konishi @ 2010-07-12  5:31 UTC (permalink / raw)
  To: sfr, viro; +Cc: linux-next, linux-kernel, konishi.ryusuke

On Mon, 12 Jul 2010 12:24:58 +1000, Stephen Rothwell wrote:
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/nilfs2/inode.c: In function 'nilfs_clear_inode':
> fs/nilfs2/inode.c:630: error: implicit declaration of function 'nilfs_btnode_cache_clear'
> 
> Caused by commit 743a0a2f1a89e53d656ec6a2f715111d92642bcb ("convert
> nilfs2 to ->evict_inode()") interacting with commit
> ceb4f9c819c321e7eabf53b51f956ff959561573 ("nilfs2: get rid of
> nilfs_bmap_union") from the nilfs2 tree which removed the implicit
> inclusion of btnode.h (via bmap_union.h via nilfs.h).
> 
> I have added the following patch for today (which should be applied to
> the vfs tree or merged into the above vfs tree commit):

Thank you for the catch.

I would appreciate it if this is applied to the vfs tree.

The problem is that I didn't include btnode.h in nilfs2/super.c, but
the above handling looks natural since the current nilfs2/inode.c does
not need the inclusion of btnode.h.

Regards,
Ryusuke Konishi

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 12 Jul 2010 12:17:47 +1000
> Subject: [PATCH] nilfs2: inode.c needs to include btnode.h directly now
> 
> Due to the new usage of nilfs_btnode_cache_clear().
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/nilfs2/inode.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/nilfs2/inode.c b/fs/nilfs2/inode.c
> index 8fea40e..eccb2f2 100644
> --- a/fs/nilfs2/inode.c
> +++ b/fs/nilfs2/inode.c
> @@ -27,6 +27,7 @@
>  #include <linux/writeback.h>
>  #include <linux/uio.h>
>  #include "nilfs.h"
> +#include "btnode.h"
>  #include "segment.h"
>  #include "page.h"
>  #include "mdt.h"
> -- 
> 1.7.1
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2010-07-12  2:24 Stephen Rothwell
  2010-07-12  5:31 ` Ryusuke Konishi
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2010-07-12  2:24 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-next, linux-kernel, Ryusuke Konishi

Hi Al,

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

fs/nilfs2/inode.c: In function 'nilfs_clear_inode':
fs/nilfs2/inode.c:630: error: implicit declaration of function 'nilfs_btnode_cache_clear'

Caused by commit 743a0a2f1a89e53d656ec6a2f715111d92642bcb ("convert
nilfs2 to ->evict_inode()") interacting with commit
ceb4f9c819c321e7eabf53b51f956ff959561573 ("nilfs2: get rid of
nilfs_bmap_union") from the nilfs2 tree which removed the implicit
inclusion of btnode.h (via bmap_union.h via nilfs.h).

I have added the following patch for today (which should be applied to
the vfs tree or merged into the above vfs tree commit):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 12 Jul 2010 12:17:47 +1000
Subject: [PATCH] nilfs2: inode.c needs to include btnode.h directly now

Due to the new usage of nilfs_btnode_cache_clear().

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/nilfs2/inode.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/nilfs2/inode.c b/fs/nilfs2/inode.c
index 8fea40e..eccb2f2 100644
--- a/fs/nilfs2/inode.c
+++ b/fs/nilfs2/inode.c
@@ -27,6 +27,7 @@
 #include <linux/writeback.h>
 #include <linux/uio.h>
 #include "nilfs.h"
+#include "btnode.h"
 #include "segment.h"
 #include "page.h"
 #include "mdt.h"
-- 
1.7.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2010-06-22  1:22 Stephen Rothwell
  2010-08-04  1:50 ` Stephen Rothwell
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2010-06-22  1:22 UTC (permalink / raw)
  To: Al Viro
  Cc: linux-next, linux-kernel, Sripathi Kodi, Eric Van Hensbergen,
	Christoph Hellwig

Hi Al,

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

fs/9p/vfs_inode.c: In function 'v9fs_vfs_setattr_dotl':
fs/9p/vfs_inode.c:1056: error: implicit declaration of function 'inode_setattr'

Caused by commit 463942d48d7f05812f0d6426dd8051ff53ea24a3 ("9p: Implement
client side of setattr for 9P2000.L protocol") from the v9fs tree
interacting with commit 3d9bf66940b6001a30aa30d5ac9f816326d9b3a0 ("remove
inode_setattr") from the vfs tree.

I have applied the following patch (using the changes in the above vfs
tree commit as a guide) as a merge fix for today, but am not sure if it
is correct.  I assume that this (or something similar) could be applied
to the v9fs tree now - is that correct Christoph?

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 22 Jun 2010 11:15:01 +1000
Subject: [PATCH] v9fs: fixup for inode_setattr being removed

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/9p/vfs_inode.c |   15 ++++++++++++---
 1 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index f027a42..2ec7bfa 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -1052,10 +1052,19 @@ static int v9fs_vfs_setattr_dotl(struct dentry *dentry, struct iattr *iattr)
 		return PTR_ERR(fid);
 
 	retval = p9_client_setattr(fid, &p9attr);
-	if (retval >= 0)
-		retval = inode_setattr(dentry->d_inode, iattr);
+	if (retval < 0)
+		return retval;
 
-	return retval;
+	if ((iattr->ia_valid & ATTR_SIZE) &&
+	    iattr->ia_size != i_size_read(dentry->d_inode)) {
+		retval = vmtruncate(dentry->d_inode, iattr->ia_size);
+		if (retval)
+			return retval;
+	}
+
+	setattr_copy(dentry->d_inode, iattr);
+	mark_inode_dirty(dentry->d_inode);
+	return 0;
 }
 
 /**
-- 
1.7.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply related	[flat|nested] 132+ messages in thread

* Re: linux-next: build failure after merge of the vfs tree
  2010-05-28  1:45 Stephen Rothwell
@ 2010-05-28  1:51 ` Al Viro
  0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2010-05-28  1:51 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Christoph Hellwig, Josef Bacik,
	Chris Mason, Nick Piggin

On Fri, May 28, 2010 at 11:45:39AM +1000, Stephen Rothwell wrote:
> Hi Al,
> 
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/cell/spufs/file.c:1852: error: expected ';', ',' or ')' before 'int'
> arch/powerpc/platforms/cell/spufs/file.c:1871: error: 'spufs_mfc_fsync' undeclared here (not in a function)

Tpyo in fsync patch (missing comma in line 1852 there)

> Caused by commit 05b2fc7d1f1046fef1199e1a4d2f63df998ef3aa ("drop unused
> dentry argument to ->fsync").
 
> My merge of the vfs tree was also bad because commit
> facd07b07d2a7988f5ce849558838cc953847637 ("direct-io: add a hook for the
> fs to provide its own submit_bio function") that entered Linus' tree in
> the past 24 hours changed the prototype of __blockdev_direct_IO() and
> that probably needs reflecting in the new __blockdev_direct_IO_newtrunc().

OK, I'll rebase that stuff.

^ permalink raw reply	[flat|nested] 132+ messages in thread

* linux-next: build failure after merge of the vfs tree
@ 2010-05-28  1:45 Stephen Rothwell
  2010-05-28  1:51 ` Al Viro
  0 siblings, 1 reply; 132+ messages in thread
From: Stephen Rothwell @ 2010-05-28  1:45 UTC (permalink / raw)
  To: Al Viro
  Cc: linux-next, linux-kernel, Christoph Hellwig, Josef Bacik,
	Chris Mason, Nick Piggin

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

Hi Al,

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

arch/powerpc/platforms/cell/spufs/file.c:1852: error: expected ';', ',' or ')' before 'int'
arch/powerpc/platforms/cell/spufs/file.c:1871: error: 'spufs_mfc_fsync' undeclared here (not in a function)

Caused by commit 05b2fc7d1f1046fef1199e1a4d2f63df998ef3aa ("drop unused
dentry argument to ->fsync").

My merge of the vfs tree was also bad because commit
facd07b07d2a7988f5ce849558838cc953847637 ("direct-io: add a hook for the
fs to provide its own submit_bio function") that entered Linus' tree in
the past 24 hours changed the prototype of __blockdev_direct_IO() and
that probably needs reflecting in the new __blockdev_direct_IO_newtrunc().

I have used the vfs tree from next-20100527 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 132+ messages in thread

end of thread, other threads:[~2021-01-04 23:29 UTC | newest]

Thread overview: 132+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-20  0:31 linux-next: build failure after merge of the vfs tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2021-01-04 22:36 Stephen Rothwell
2021-01-04 23:28 ` Al Viro
2020-10-27  4:14 Stephen Rothwell
2020-10-27  4:59 ` Al Viro
2020-11-10 19:00   ` Al Viro
2020-11-10 21:24     ` Stephen Rothwell
2020-09-28  1:31 Stephen Rothwell
2020-09-28  6:05 ` Christoph Hellwig
2020-09-24  8:30 Stephen Rothwell
2020-09-24 20:08 ` Al Viro
2020-09-25 12:01   ` Stephen Rothwell
2020-09-25 13:38     ` Al Viro
2020-09-29  4:10       ` Josh Poimboeuf
2020-10-06 14:30         ` Josh Poimboeuf
2020-10-06 21:04           ` Stephen Rothwell
2020-10-07 15:46             ` Josh Poimboeuf
2020-07-29  1:56 Stephen Rothwell
2020-07-29  6:33 ` Christoph Hellwig
2020-07-29 19:19   ` Al Viro
2020-07-27 12:06 Stephen Rothwell
2020-05-07  0:39 Stephen Rothwell
2020-05-07  2:35 ` Al Viro
2020-05-07 15:07   ` Jens Axboe
2020-01-10  6:57 Stephen Rothwell
2020-01-10 10:00 ` Carlos Maiolino
2020-01-10 11:03 ` Carlos Maiolino
2020-01-10 22:44   ` Stephen Rothwell
2020-01-13  9:28     ` Carlos Maiolino
2020-01-24  2:41 ` Stephen Rothwell
2020-01-29 22:40   ` Stephen Rothwell
2019-01-02  4:01 Stephen Rothwell
2019-01-30  3:45 ` Stephen Rothwell
2018-10-03  0:32 Stephen Rothwell
2018-10-16  0:17 ` Stephen Rothwell
2018-10-16 16:37   ` Jaegeuk Kim
2018-10-16 20:45     ` Stephen Rothwell
2018-09-10  3:59 Stephen Rothwell
2018-09-10  3:35 Stephen Rothwell
2018-09-18 21:38 ` Stephen Rothwell
2018-09-18 22:17 ` David Howells
2018-09-18 23:49   ` Stephen Rothwell
2018-09-19  7:17     ` Geert Uytterhoeven
2018-09-19  6:01   ` David Howells
2018-09-19  6:31     ` Stephen Rothwell
2018-09-20 10:48       ` Michael Ellerman
2018-09-20 16:20       ` David Howells
2018-09-20 10:44   ` Michael Ellerman
2018-10-29  4:33 ` Stephen Rothwell
2018-10-29  9:07   ` Stephen Rothwell
2018-10-29  9:21   ` David Howells
2018-10-29 10:29     ` Stephen Rothwell
2018-09-06  2:28 Stephen Rothwell
2018-08-07 10:58 Stephen Rothwell
2018-08-07  1:11 Stephen Rothwell
2018-08-06  0:37 Stephen Rothwell
2018-08-06 12:24 ` Stephen Rothwell
2018-08-07  0:59   ` Stephen Rothwell
2018-08-07  2:20     ` Masahiro Yamada
2018-06-19  1:47 Stephen Rothwell
2018-03-19  6:06 Stephen Rothwell
2018-03-19 19:56 ` Mateusz Guzik
2018-04-03  2:26 ` Stephen Rothwell
2018-04-08  2:19   ` Al Viro
2018-04-08  2:55     ` Stephen Rothwell
2017-12-03 23:16 Stephen Rothwell
2017-07-11  0:55 Stephen Rothwell
2017-07-11  9:21 ` David Howells
2017-07-10  2:15 Stephen Rothwell
2017-07-10  2:34 ` Al Viro
2017-02-27  0:27 Stephen Rothwell
2017-02-27  8:31 ` David Howells
2016-07-29  1:19 Stephen Rothwell
2016-07-29  4:18 ` Al Viro
2016-05-02  1:25 Stephen Rothwell
2016-05-02  1:31 ` Al Viro
2016-05-02  4:48   ` Abhijith Das
2015-12-10  0:18 Stephen Rothwell
2015-12-10  0:23 ` Stephen Rothwell
2015-12-10  0:48   ` Al Viro
2015-12-10 15:44     ` Mike Marshall
2015-12-21  0:23 ` Stephen Rothwell
2016-01-07  0:42   ` Stephen Rothwell
2016-01-07  2:09     ` Al Viro
2015-12-09  5:58 Stephen Rothwell
2015-12-09  1:19 Stephen Rothwell
2015-12-09 21:30 ` Mike Marshall
2015-12-09 22:20   ` Stephen Rothwell
2015-12-09 22:53     ` Andreas Grünbacher
2015-12-07 22:42 Stephen Rothwell
2015-05-11  1:26 Stephen Rothwell
2015-05-13  2:26 ` Stephen Rothwell
2015-03-13  1:02 Stephen Rothwell
2015-03-24  3:24 ` Stephen Rothwell
2015-03-24 10:44   ` Christoph Hellwig
2014-12-10  7:45 Stephen Rothwell
2014-12-11  2:32 ` Al Viro
2014-04-22  1:26 Stephen Rothwell
2014-04-23  0:33 ` Stephen Rothwell
2013-11-07  0:30 Stephen Rothwell
2013-09-09  2:33 Stephen Rothwell
2013-09-09  8:54 ` Ian Kent
2013-06-24  1:35 Stephen Rothwell
2013-06-24  9:34 ` Al Viro
2013-05-01  2:22 Stephen Rothwell
2013-05-01 13:13 ` J. Bruce Fields
2013-04-08  1:15 Stephen Rothwell
2013-04-09 15:49 ` Stephen Rothwell
2013-04-03  0:22 Stephen Rothwell
2013-04-03  1:14 ` Al Viro
2013-04-02  0:26 Stephen Rothwell
2013-04-02  0:39 ` Al Viro
2012-07-16  0:59 Stephen Rothwell
2012-05-31  0:51 Stephen Rothwell
2012-05-31  1:02 ` Al Viro
2012-01-03  1:43 Stephen Rothwell
2012-01-03 13:39 ` Jan Kara
2011-12-22  0:15 Stephen Rothwell
2011-12-19  1:06 Stephen Rothwell
2011-12-19  1:12 ` Al Viro
2011-07-16  6:44 Stephen Rothwell
2011-07-25  3:20 ` Stephen Rothwell
2011-07-25 18:26   ` Trond Myklebust
2011-07-16  6:36 Stephen Rothwell
2010-07-19  0:25 Stephen Rothwell
     [not found] ` <20100719102520.a2d4f103.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
2010-08-04  1:47   ` Stephen Rothwell
2010-07-12  2:24 Stephen Rothwell
2010-07-12  5:31 ` Ryusuke Konishi
2010-06-22  1:22 Stephen Rothwell
2010-08-04  1:50 ` Stephen Rothwell
2010-05-28  1:45 Stephen Rothwell
2010-05-28  1:51 ` Al Viro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).