Re: linux-next: build failure after merge of the vfs tree
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 ;-/
Re: linux-next: build failure after merge of the vfs tree
Hi Al, On Tue, 10 Nov 2020 19:00:36 + Al Viro wrote: > > On Tue, Oct 27, 2020 at 04:59:12AM +, Al Viro wrote: > > > I'll rebase that branch on top of sparc tree tomorrow (and eventually I'd > > like > > it to go through the sparc tree anyway). > > Done - sorry for disappearing ;-/ No worries and thanks. -- Cheers, Stephen Rothwell pgpCFDkflbNrs.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
On Tue, Oct 27, 2020 at 04:59:12AM +, Al Viro wrote: > I'll rebase that branch on top of sparc tree tomorrow (and eventually I'd like > it to go through the sparc tree anyway). Done - sorry for disappearing ;-/
Re: linux-next: build failure after merge of the vfs tree
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).
Re: linux-next: build failure after merge of the vfs tree
On Wed, Oct 07, 2020 at 08:04:05AM +1100, Stephen Rothwell wrote: > Hi Josh, > > On Tue, 6 Oct 2020 09:30:12 -0500 Josh Poimboeuf wrote: > > > > On Mon, Sep 28, 2020 at 11:10:56PM -0500, Josh Poimboeuf wrote: > > > > Josh, any ideas? We could, of course, make it "r"(size), but that would > > > > be unpleasant in all existing callers... > > > > > > Sorry, I've been traveling. I'd just vote for making it "r". > > > > > > array_index_nospec() is always called after a usercopy. I don't think > > > anyone will notice the extra mov, for the cases where it would be > > > propagated as an immediate. And the argument *is* an unsigned long > > > after all. > > > > > > Stephen, can you confirm this fixes it? > > > > Still traveling, I didn't see an update on this. Any objections to the > > below? I assume it fixes Stephen's build issue. > > Yes, it does fix my x86_64 allnoconfig build. Stephen, thanks! Al, do you want to fold that change in? Or shall I post another version? -- Josh
Re: linux-next: build failure after merge of the vfs tree
Hi Josh, On Tue, 6 Oct 2020 09:30:12 -0500 Josh Poimboeuf wrote: > > On Mon, Sep 28, 2020 at 11:10:56PM -0500, Josh Poimboeuf wrote: > > > Josh, any ideas? We could, of course, make it "r"(size), but that would > > > be unpleasant in all existing callers... > > > > Sorry, I've been traveling. I'd just vote for making it "r". > > > > array_index_nospec() is always called after a usercopy. I don't think > > anyone will notice the extra mov, for the cases where it would be > > propagated as an immediate. And the argument *is* an unsigned long > > after all. > > > > Stephen, can you confirm this fixes it? > > Still traveling, I didn't see an update on this. Any objections to the > below? I assume it fixes Stephen's build issue. Yes, it does fix my x86_64 allnoconfig build. -- Cheers, Stephen Rothwell pgpWJSjxfb9J9.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
On Mon, Sep 28, 2020 at 11:10:56PM -0500, Josh Poimboeuf wrote:
> > Josh, any ideas? We could, of course, make it "r"(size), but that would
> > be unpleasant in all existing callers...
>
> Sorry, I've been traveling. I'd just vote for making it "r".
>
> array_index_nospec() is always called after a usercopy. I don't think
> anyone will notice the extra mov, for the cases where it would be
> propagated as an immediate. And the argument *is* an unsigned long
> after all.
>
> Stephen, can you confirm this fixes it?
Still traveling, I didn't see an update on this. Any objections to the
below? I assume it fixes Stephen's build issue.
>
> diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
> index d158ea1fa250..69045ac62f58 100644
> --- a/arch/x86/include/asm/barrier.h
> +++ b/arch/x86/include/asm/barrier.h
> @@ -40,7 +40,7 @@ static inline unsigned long
> array_index_mask_nospec(unsigned long index,
>
> asm volatile ("cmp %1,%2; sbb %0,%0;"
> :"=r" (mask)
> - :"g"(size),"r" (index)
> + :"r"(size), "r"(index)
> :"cc");
> return mask;
> }
>
--
Josh
Re: linux-next: build failure after merge of the vfs tree
On Fri, Sep 25, 2020 at 02:38:20PM +0100, Al Viro wrote:
> On Fri, Sep 25, 2020 at 10:01:28PM +1000, Stephen Rothwell wrote:
> > $ x86_64-linux-gnu-gcc --version
> > x86_64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0
> > $ x86_64-linux-gnu-ld --version
> > GNU ld (GNU Binutils for Debian) 2.35
> >
> > and the gcc plugins don't get built for the allnoconfig builds.
>
> > I reverted my Revert commit after I finished linux-next today and built
> > the x86_64 allnoconfig verion of lib/iov_iter.s:
> >
> > $ grep -A 1 '41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h"'
> > lib/iov_iter.s
> > # 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
> > cmp $140737488351232,%rdx; sbb %rcx,%rcx; #, uaddr, mask
>
> Wait a sec...
> static inline unsigned long array_index_mask_nospec(unsigned long index,
> unsigned long size)
> {
> unsigned long mask;
>
> asm volatile ("cmp %1,%2; sbb %0,%0;"
> :"=r" (mask)
> :"g"(size),"r" (index)
> :"cc");
> return mask;
> }
>
> used with large constant size will blow up - "g" is wrong, since cmp allows
> 64bit arguments to be register or memory ones; immediates can't go past
> 32bit.
>
> Looks like on the configs where it builds we end up with not seeing it's
> a constant...
>
> Josh, any ideas? We could, of course, make it "r"(size), but that would
> be unpleasant in all existing callers...
Sorry, I've been traveling. I'd just vote for making it "r".
array_index_nospec() is always called after a usercopy. I don't think
anyone will notice the extra mov, for the cases where it would be
propagated as an immediate. And the argument *is* an unsigned long
after all.
Stephen, can you confirm this fixes it?
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index d158ea1fa250..69045ac62f58 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -40,7 +40,7 @@ static inline unsigned long array_index_mask_nospec(unsigned
long index,
asm volatile ("cmp %1,%2; sbb %0,%0;"
:"=r" (mask)
- :"g"(size),"r" (index)
+ :"r"(size), "r"(index)
:"cc");
return mask;
}
Re: linux-next: build failure after merge of the vfs tree
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.
Re: linux-next: build failure after merge of the vfs tree
On Fri, Sep 25, 2020 at 10:01:28PM +1000, Stephen Rothwell wrote:
> $ x86_64-linux-gnu-gcc --version
> x86_64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0
> $ x86_64-linux-gnu-ld --version
> GNU ld (GNU Binutils for Debian) 2.35
>
> and the gcc plugins don't get built for the allnoconfig builds.
> I reverted my Revert commit after I finished linux-next today and built
> the x86_64 allnoconfig verion of lib/iov_iter.s:
>
> $ grep -A 1 '41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h"'
> lib/iov_iter.s
> # 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
> cmp $140737488351232,%rdx; sbb %rcx,%rcx; #, uaddr, mask
Wait a sec...
static inline unsigned long array_index_mask_nospec(unsigned long index,
unsigned long size)
{
unsigned long mask;
asm volatile ("cmp %1,%2; sbb %0,%0;"
:"=r" (mask)
:"g"(size),"r" (index)
:"cc");
return mask;
}
used with large constant size will blow up - "g" is wrong, since cmp allows
64bit arguments to be register or memory ones; immediates can't go past
32bit.
Looks like on the configs where it builds we end up with not seeing it's
a constant...
Josh, any ideas? We could, of course, make it "r"(size), but that would
be unpleasant in all existing callers...
Re: linux-next: build failure after merge of the vfs tree
Hi Al,
On Thu, 24 Sep 2020 21:08:07 +0100 Al Viro wrote:
>
> On Thu, Sep 24, 2020 at 06:30:38PM +1000, Stephen Rothwell wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> > failed like this:
> >
> > arch/x86/include/asm/barrier.h: Assembler messages:
> > arch/x86/include/asm/barrier.h:41: Error: operand type mismatch for `cmp'
> > arch/x86/include/asm/barrier.h:41: Error: operand type mismatch for `cmp'
> >
> > and many more ...
> >
> > Caused by commit
> >
> > e33ea6e5ba6a ("x86/uaccess: Use pointer masking to limit uaccess
> > speculation")
> >
> > I am not exactly sure why (but reverting it fixes the build).
> >
> > I have reverted that commit for today.
>
> Can't reproduce here... This on top of today's -next seems to build with
> allnoconfig here:
I don't know what to tell you ... it still fails for me today.
$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0
$ x86_64-linux-gnu-ld --version
GNU ld (GNU Binutils for Debian) 2.35
and the gcc plugins don't get built for the allnoconfig builds.
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 35293ad83297..aca828b9b831 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -647,7 +647,7 @@ static int copyout_mc(void __user *to, const void *from,
> size_t n)
> {
> if (access_ok(to, n)) {
> instrument_copy_to_user(to, from, n);
> - n = copy_mc_to_user((__force void *) to, from, n);
> + n = copy_mc_to_user((__force void *)force_user_ptr(to), from,
> n);
BTW, You can't do that because force_user_ptr is only defined for x86 ...
I reverted my Revert commit after I finished linux-next today and built
the x86_64 allnoconfig verion of lib/iov_iter.s:
$ grep -A 1 '41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h"'
lib/iov_iter.s
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdx; sbb %rcx,%rcx; #, uaddr, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%r8; sbb %rdx,%rdx;#, end, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdx; sbb %rcx,%rcx; #, uaddr, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdi; sbb %rdx,%rdx; #, end, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdi; sbb %rax,%rax; #, to.29_334, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdi; sbb %rax,%rax; #, to.29_367, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax; #, from.37_239, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax; #, from.37_272, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax; #, _i, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax; #, _i, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax; #, _i, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax; #, _i, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdi; sbb %rax,%rax; #, to.29_96, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rdi; sbb %rax,%rax; #, to.29_244, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax; #, from.37_68, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax; #, from.37_221, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %r10,%r10; #, from.37_281, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax; #, from.37_314, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %r10,%r10; #, from.37_177, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax; #, from.37_210, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%r10; sbb %rsi,%rsi; #, _i, mask
--
# 41 "/home/sfr/next/next/arch/x86/include/asm/barrier.h" 1
cmp $140737488351232,%rsi; sbb %rax,%rax; #, _i, mask
I don't know if that helps.
--
Cheers,
Stephen Rothwell
pgpOQn7xVDEPt.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
On Thu, Sep 24, 2020 at 06:30:38PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
>
> arch/x86/include/asm/barrier.h: Assembler messages:
> arch/x86/include/asm/barrier.h:41: Error: operand type mismatch for `cmp'
> arch/x86/include/asm/barrier.h:41: Error: operand type mismatch for `cmp'
>
> and many more ...
>
> Caused by commit
>
> e33ea6e5ba6a ("x86/uaccess: Use pointer masking to limit uaccess
> speculation")
>
> I am not exactly sure why (but reverting it fixes the build).
>
> I have reverted that commit for today.
Can't reproduce here... This on top of today's -next seems to build with
allnoconfig here:
diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst
b/Documentation/admin-guide/hw-vuln/spectre.rst
index e05e581af5cf..27a8adedd2b8 100644
--- a/Documentation/admin-guide/hw-vuln/spectre.rst
+++ b/Documentation/admin-guide/hw-vuln/spectre.rst
@@ -426,9 +426,9 @@ Spectre variant 1
` to avoid any usable disclosure gadgets. However, it may
not cover all attack vectors for Spectre variant 1.
- Copy-from-user code has an LFENCE barrier to prevent the access_ok()
- check from being mis-speculated. The barrier is done by the
- barrier_nospec() macro.
+ Usercopy code uses user pointer masking to prevent the access_ok()
+ check from being mis-speculated in the success path with a kernel
+ address. The masking is done by the force_user_ptr() macro.
For the swapgs variant of Spectre variant 1, LFENCE barriers are
added to interrupt, exception and NMI entry where needed. These
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index 7f828fe49797..d158ea1fa250 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -48,9 +48,6 @@ static inline unsigned long array_index_mask_nospec(unsigned
long index,
/* Override the default implementation from linux/nospec.h. */
#define array_index_mask_nospec array_index_mask_nospec
-/* Prevent speculative execution past this barrier. */
-#define barrier_nospec() alternative("", "lfence", X86_FEATURE_LFENCE_RDTSC)
-
#define dma_rmb() barrier()
#define dma_wmb() barrier()
diff --git a/arch/x86/include/asm/checksum_32.h
b/arch/x86/include/asm/checksum_32.h
index 17da95387997..c7ebc40c6fb9 100644
--- a/arch/x86/include/asm/checksum_32.h
+++ b/arch/x86/include/asm/checksum_32.h
@@ -49,7 +49,8 @@ static inline __wsum csum_and_copy_from_user(const void
__user *src,
might_sleep();
if (!user_access_begin(src, len))
return 0;
- ret = csum_partial_copy_generic((__force void *)src, dst, len);
+ ret = csum_partial_copy_generic((__force void *)force_user_ptr(src),
+ dst, len);
user_access_end();
return ret;
@@ -177,8 +178,7 @@ static inline __wsum csum_and_copy_to_user(const void *src,
might_sleep();
if (!user_access_begin(dst, len))
return 0;
-
- ret = csum_partial_copy_generic(src, (__force void *)dst, len);
+ ret = csum_partial_copy_generic(src, (__force void
*)force_user_ptr(dst), len);
user_access_end();
return ret;
}
diff --git a/arch/x86/include/asm/futex.h b/arch/x86/include/asm/futex.h
index f9c00110a69a..0cecdaa362b1 100644
--- a/arch/x86/include/asm/futex.h
+++ b/arch/x86/include/asm/futex.h
@@ -59,6 +59,8 @@ static __always_inline int arch_futex_atomic_op_inuser(int
op, int oparg, int *o
if (!user_access_begin(uaddr, sizeof(u32)))
return -EFAULT;
+ uaddr = force_user_ptr(uaddr);
+
switch (op) {
case FUTEX_OP_SET:
unsafe_atomic_op1("xchgl %0, %2", oval, uaddr, oparg, Efault);
@@ -94,6 +96,9 @@ static inline int futex_atomic_cmpxchg_inatomic(u32 *uval,
u32 __user *uaddr,
if (!user_access_begin(uaddr, sizeof(u32)))
return -EFAULT;
+
+ uaddr = force_user_ptr(uaddr);
+
asm volatile("\n"
"1:\t" LOCK_PREFIX "cmpxchgl %4, %2\n"
"2:\n"
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index b24f8623bcda..cad8d0b1dbbb 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -67,13 +68,24 @@ static inline bool pagefault_disabled(void);
* Return: true (nonzero) if the memory block may be valid, false (zero)
* if it is definitely invalid.
*/
-#define access_ok(addr, size) \
+#define access_ok(addr, size) \
({ \
WARN_ON_IN_IRQ(); \
likely(!__range_not_ok(addr, size, TASK_SIZE_MAX)); \
})
/*
+ * Sanitize a user p
Re: linux-next: build failure after merge of the vfs tree
On Wed, Jul 29, 2020 at 08:33:05AM +0200, Christoph Hellwig wrote: > Thanks, > > I've sent out a fixed version. #work.quota-compat and #for-next rebuilt (and pushed) with it...
Re: linux-next: build failure after merge of the vfs tree
Thanks, I've sent out a fixed version.
Re: linux-next: build failure after merge of the vfs tree
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
Re: linux-next: build failure after merge of the vfs tree
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
Re: linux-next: build failure after merge of the vfs tree
Hi all,
On Wed, 2 Jan 2019 15:01:40 +1100 Stephen Rothwell
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
>
> fs/fs_context.c: In function 'logfc':
> fs/fs_context.c:400:3: error: implicit declaration of function
> 'vprintk_emit'; did you mean 'dev_printk_emit'?
> [-Werror=implicit-function-declaration]
>vprintk_emit(0, LOGLEVEL_WARNING, NULL, 0, fmt, va);
>^~~~
>dev_printk_emit
>
> Caused by commit
>
> e6d72ffc503f ("vfs: Implement logging through fs_context")
>
> # CONFIG_PRINTK is not set
>
> I added the following hack for today:
>
> From: Stephen Rothwell
> Date: Wed, 2 Jan 2019 14:57:36 +1100
> Subject: [PATCH] vfs: work around CONFIG_PRINTK=n in fs_context logging code
>
> Signed-off-by: Stephen Rothwell
> ---
> fs/fs_context.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/fs_context.c b/fs/fs_context.c
> index 8728d49c7871..b0324598f573 100644
> --- a/fs/fs_context.c
> +++ b/fs/fs_context.c
> @@ -391,6 +391,7 @@ EXPORT_SYMBOL(vfs_dup_fs_context);
> */
> void logfc(struct fs_context *fc, const char *fmt, ...)
> {
> +#ifdef CONFIG_PRINTK
> va_list va;
>
> va_start(va, fmt);
> @@ -409,6 +410,7 @@ void logfc(struct fs_context *fc, const char *fmt, ...)
>
> pr_cont("\n");
> va_end(va);
> +#endif
> }
> EXPORT_SYMBOL(logfc);
>
Ping?
--
Cheers,
Stephen Rothwell
pgp966dJkI160.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
Hi David, On Mon, 29 Oct 2018 09:21:20 + David Howells wrote: > > I think these changes should cover them all. Yep, that fixes the build for me, thanks. Tested-by: Stephen Rothwell -- Cheers, Stephen Rothwell pgpUP0DRJWa3r.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
I think these changes should cover them all.
David
---
diff --git a/samples/vfs/test-fs-query.c b/samples/vfs/test-fs-query.c
index 511541d12b9e..4635bf1eb3d4 100644
--- a/samples/vfs/test-fs-query.c
+++ b/samples/vfs/test-fs-query.c
@@ -27,6 +27,13 @@
#include
#include
+#ifndef __NR_fsopen
+#define __NR_fsopen -1
+#endif
+#ifndef __NR_fsinfo
+#define __NR_fsinfo -1
+#endif
+
static int fsopen(const char *fs_name, unsigned int flags)
{
return syscall(__NR_fsopen, fs_name, flags);
diff --git a/samples/vfs/test-fsinfo.c b/samples/vfs/test-fsinfo.c
index 75f5c2a61445..125010212eee 100644
--- a/samples/vfs/test-fsinfo.c
+++ b/samples/vfs/test-fsinfo.c
@@ -28,6 +28,10 @@
#include
#include
+#ifndef __NR_fsinfo
+#define __NR_fsinfo -1
+#endif
+
static bool debug = 0;
static __attribute__((unused))
diff --git a/samples/vfs/test-statx.c b/samples/vfs/test-statx.c
index 9ac4b7707aba..4ef0c914a62a 100644
--- a/samples/vfs/test-statx.c
+++ b/samples/vfs/test-statx.c
@@ -161,7 +161,8 @@ static void dump_statx(struct statx *stx)
"?dai?c??" /* 7- 00x-00ff */
;
- printf("Attributes: %016llx (", stx->stx_attributes);
+ printf("Attributes: %016llx (",
+ (unsigned long long)stx->stx_attributes);
for (byte = 64 - 8; byte >= 0; byte -= 8) {
bits = stx->stx_attributes >> byte;
mbits = stx->stx_attributes_mask >> byte;
Re: linux-next: build failure after merge of the vfs tree
Hi David,
On Mon, 29 Oct 2018 15:33:34 +1100 Stephen Rothwell
wrote:
>
> Hi Al, David,
>
> These have returned, so I have disabled CONFIG_SAMPLE_VFS again.
Here is the current set of errors I git today (this is from a PowerPC
allyesconfig build native compiler on a PowerPC64 LE machine):
samples/vfs/test-fsinfo.c: In function 'fsinfo':
samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use in
this function); did you mean 'fsinfo'?
return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
^~~
fsinfo
samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported
only once for each function it appears in
samples/vfs/test-fsinfo.c:38:1: warning: control reaches end of non-void
function [-Wreturn-type]
}
^
samples/vfs/test-fs-query.c: In function 'fsopen':
samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use
in this function); did you mean 'fsopen'?
return syscall(__NR_fsopen, fs_name, flags);
^~~
fsopen
samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is reported
only once for each function it appears in
samples/vfs/test-fs-query.c: In function 'fsinfo':
samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use
in this function); did you mean 'fsinfo'?
return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
^~~
fsinfo
samples/vfs/test-fs-query.c: In function 'fsopen':
samples/vfs/test-fs-query.c:33:1: warning: control reaches end of non-void
function [-Wreturn-type]
}
^
samples/vfs/test-fs-query.c: In function 'fsinfo':
samples/vfs/test-fs-query.c:39:1: warning: control reaches end of non-void
function [-Wreturn-type]
}
^
samples/vfs/test-statx.c: In function 'dump_statx':
samples/vfs/test-statx.c:164:29: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
unsigned int'} [-Wformat=]
printf("Attributes: %016llx (", stx->stx_attributes);
~~^ ~~~
%016lx
--
Cheers,
Stephen Rothwell
pgp35wEErfoA1.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
Hi Al, David,
These have returned, so I have disabled CONFIG_SAMPLE_VFS again.
On Mon, 10 Sep 2018 13:35:25 +1000 Stephen Rothwell
wrote:
>
> After merging the vfs tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> samples/vfs/test-fsinfo.c: In function 'fsinfo':
> samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use
> in this function); did you mean 'fsinfo'?
> return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
> ^~~
> fsinfo
> samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported
> only once for each function it appears in
> samples/vfs/test-fsinfo.c: In function 'dump_attr_LIMITS':
> samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax file size: %llx\n", f->max_file_size);
>~~~^
>%lx
> samples/vfs/test-fsinfo.c:181:32: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax ids : u=%llx g=%llx p=%llx\n",
> ~~~^
> %lx
> f->max_uid, f->max_gid, f->max_projid);
> ~~
> samples/vfs/test-fsinfo.c:181:39: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax ids : u=%llx g=%llx p=%llx\n",
> ~~~^
> %lx
> f->max_uid, f->max_gid, f->max_projid);
> ~~
> samples/vfs/test-fsinfo.c:181:46: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax ids : u=%llx g=%llx p=%llx\n",
>~~~^
>%lx
> f->max_uid, f->max_gid, f->max_projid);
> ~
> samples/vfs/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
> samples/vfs/test-fsinfo.c:197:24: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tstx_attr=%llx\n", f->stx_attributes);
> ~~~^ ~
> %lx
> samples/vfs/test-fsmount.c: In function 'fsopen':
> samples/vfs/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first use
> in this function); did you mean 'fsopen'?
> return syscall(__NR_fsopen, fs_name, flags);
> ^~~
> fsopen
> samples/vfs/test-fsmount.c:63:17: note: each undeclared identifier is
> reported only once for each function it appears in
> samples/vfs/test-fsmount.c: In function 'fsmount':
> samples/vfs/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first use
> in this function); did you mean 'fsmount'?
> return syscall(__NR_fsmount, fsfd, flags, ms_flags);
> ^~~~
> fsmount
> samples/vfs/test-fsmount.c: In function 'fsconfig':
> samples/vfs/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared (first
> use in this function); did you mean 'fsconfig'?
> return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
> ^
> fsconfig
> samples/vfs/test-fsmount.c: In function 'move_mount':
> samples/vfs/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared (first
> use in this function); did you mean 'move_mount'?
> return syscall(__NR_move_mount,
> ^~~
> move_mount
> samples/vfs/test-fs-query.c: In function 'fsopen':
> samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use
> in this function); did you mean 'fsopen'?
> return syscall(__NR_fsopen, fs_name, flags);
> ^~~
> fsopen
> samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is
> reported only once for each function it appears in
> samples/vfs/test-fs-query.c: In function 'fsinfo':
> samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use
> in this function); did you mean 'fsinfo'?
> return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
> ^~~
> fsinfo
> samples/vfs/test-statx.c: In function 'dump_statx':
> samples/vfs/test-statx.c:160:29: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
>printf("Attributes: %016llx (", stx->stx_attributes);
>
Re: linux-next: build failure after merge of the vfs tree
Hi Jaegeuk, On Tue, 16 Oct 2018 09:37:44 -0700 Jaegeuk Kim wrote: > > I've modified this patch in f2fs tree to use SB_RDONLY. Thanks for that. -- Cheers, Stephen Rothwell pgpFgDa4GbUu9.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
On 10/16, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 3 Oct 2018 10:32:22 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > /home/sfr/next/next/fs/f2fs/super.c: In function 'f2fs_remount':
> > /home/sfr/next/next/fs/f2fs/super.c:1589:16: error: 'MS_RDONLY' undeclared
> > (first use in this function); did you mean 'IS_RDONLY'?
> > if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> > ^
> > IS_RDONLY
> >
> > Caused by commit
> >
> > dcf8001d292b ("vfs: Suppress MS_* flag defs within the kernel unless
> > explicitly enabled")
> >
> > interacting with commit
> >
> > f80f781514ef ("f2fs: checkpoint disabling")
> >
> > from the f2fs tree.
> >
> > I have added the following merge fix patch for today. If it is correct,
> > I assume that it could be applied to f2fs tree as the the other uses of
> > MS_RDONLY have already been changed to SB_RDONLY. (There is another
> > use of MS_READONLY in this function that is already cleaned up in the
> > vfs tree commit.)
>
> Can this be applied to the f2fs tree?
Hi Stephen,
I've modified this patch in f2fs tree to use SB_RDONLY.
Thanks,
>
> > From: Stephen Rothwell
> > Date: Wed, 3 Oct 2018 10:27:04 +1000
> > Subject: [PATCH] f2fs: update for MS_* flags mostly going away
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > fs/f2fs/super.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > index 6ed77589ff2b..b612a9e4a35e 100644
> > --- a/fs/f2fs/super.c
> > +++ b/fs/f2fs/super.c
> > @@ -1586,7 +1586,7 @@ static int f2fs_remount(struct super_block *sb, int
> > *flags,
> > goto restore_opts;
> > }
> >
> > - if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> > + if ((*flags & SB_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> > err = -EINVAL;
> > f2fs_msg(sbi->sb, KERN_WARNING,
> > "disabling checkpoint not compatible with read-only");
> > --
> > 2.18.0
>
> --
> Cheers,
> Stephen Rothwell
Re: linux-next: build failure after merge of the vfs tree
Hi all,
On Wed, 3 Oct 2018 10:32:22 +1000 Stephen Rothwell
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> /home/sfr/next/next/fs/f2fs/super.c: In function 'f2fs_remount':
> /home/sfr/next/next/fs/f2fs/super.c:1589:16: error: 'MS_RDONLY' undeclared
> (first use in this function); did you mean 'IS_RDONLY'?
> if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> ^
> IS_RDONLY
>
> Caused by commit
>
> dcf8001d292b ("vfs: Suppress MS_* flag defs within the kernel unless
> explicitly enabled")
>
> interacting with commit
>
> f80f781514ef ("f2fs: checkpoint disabling")
>
> from the f2fs tree.
>
> I have added the following merge fix patch for today. If it is correct,
> I assume that it could be applied to f2fs tree as the the other uses of
> MS_RDONLY have already been changed to SB_RDONLY. (There is another
> use of MS_READONLY in this function that is already cleaned up in the
> vfs tree commit.)
Can this be applied to the f2fs tree?
> From: Stephen Rothwell
> Date: Wed, 3 Oct 2018 10:27:04 +1000
> Subject: [PATCH] f2fs: update for MS_* flags mostly going away
>
> Signed-off-by: Stephen Rothwell
> ---
> fs/f2fs/super.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 6ed77589ff2b..b612a9e4a35e 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -1586,7 +1586,7 @@ static int f2fs_remount(struct super_block *sb, int
> *flags,
> goto restore_opts;
> }
>
> - if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> + if ((*flags & SB_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
> err = -EINVAL;
> f2fs_msg(sbi->sb, KERN_WARNING,
> "disabling checkpoint not compatible with read-only");
> --
> 2.18.0
--
Cheers,
Stephen Rothwell
pgpxZe7Lo_ATH.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
Michael Ellerman wrote: > I realise these are in samples rather than selftests, but what most of > the selftests do is just #define the syscall number if it's not defined, > so that you're not dependent on getting the headers. The reason I don't want to do that is that syscall numbers aren't consistent across arches - they aren't even consistent within arches. I've made the VFS samples contingent on X86 in Kconfig for the moment. David
Re: linux-next: build failure after merge of the vfs tree
Stephen Rothwell writes: > Hi David, > > On Wed, 19 Sep 2018 07:01:00 +0100 David Howells wrote: >> >> Stephen Rothwell wrote: >> >> > > I think the problem is that I haven't allocated system call numbers for >> > > any arches other than x86 - even the x86 syscall numbers are provisional >> > > until the patchset is taken upstream. I'm not sure of the best way to >> > > deal with this - make the samples dependent on the X86 arch? >> > >> > But the sample programs are built with HOSTCC, so you can't depend on >> > ARCH (since I, for one, am cross compiling). Maybe SUBARCH. Better >> > would be to use either Kconfig's shell primitive or some make magic to >> > figure out if the syscall number define's are defined. >> >> I meant put the dependency in the Kconfig. > > Yeah, sure. Kconfig now has the ability for that dependency to be the > result of an external program "$(shell )", so you could have a > script or program that checked to see if the syscall numbers are > defined and then have the Kconfig symbol(s) for the tests depend on that. I realise these are in samples rather than selftests, but what most of the selftests do is just #define the syscall number if it's not defined, so that you're not dependent on getting the headers. cheers
Re: linux-next: build failure after merge of the vfs tree
David Howells writes:
> Stephen Rothwell wrote:
>
>> > After merging the vfs tree, today's linux-next build (powerpc
>> > allyesconfig) failed like this:
>> >
>> > samples/vfs/test-fsinfo.c: In function 'fsinfo':
>> > samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first
>> > use in this function); did you mean 'fsinfo'?
>
> I think the problem is that I haven't allocated system call numbers for any
> arches other than x86 - even the x86 syscall numbers are provisional until the
> patchset is taken upstream. I'm not sure of the best way to deal with this -
> make the samples dependent on the X86 arch?
>
>> > samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects argument
>> > of type 'long long unsigned int', but argument 2 has type '__u64' {aka
>> > 'long unsigned int'} [-Wformat=]
>> > printf("\tmax file size: %llx\n", f->max_file_size);
>
> Sigh. On powerpc __u64 is unsigned long, but on x86_64 it's unsigned long
> long. Is it possible to shift all arches to use unsigned long long for __u64?
You can #define SANE_USERSPACE_TYPES to get ll64 for powerpc.
cheers
Re: linux-next: build failure after merge of the vfs tree
On Wed, Sep 19, 2018 at 1:50 AM Stephen Rothwell wrote:
> On Tue, 18 Sep 2018 23:17:21 +0100 David Howells wrote:
> > Stephen Rothwell wrote:
> > > > After merging the vfs tree, today's linux-next build (powerpc
> > > > allyesconfig) failed like this:
> > > >
> > > > samples/vfs/test-fsinfo.c: In function 'fsinfo':
> > > > samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first
> > > > use in this function); did you mean 'fsinfo'?
> >
> > I think the problem is that I haven't allocated system call numbers for any
> > arches other than x86 - even the x86 syscall numbers are provisional until
> > the
> > patchset is taken upstream. I'm not sure of the best way to deal with this
> > -
> > make the samples dependent on the X86 arch?
>
> But the sample programs are built with HOSTCC, so you can't depend on
> ARCH (since I, for one, am cross compiling). Maybe SUBARCH. Better
> would be to use either Kconfig's shell primitive or some make magic to
> figure out if the syscall number define's are defined.
>
> > > > samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects
> > > > argument of type 'long long unsigned int', but argument 2 has type
> > > > '__u64' {aka 'long unsigned int'} [-Wformat=]
> > > > printf("\tmax file size: %llx\n", f->max_file_size);
> >
> > Sigh. On powerpc __u64 is unsigned long, but on x86_64 it's unsigned long
> > long. Is it possible to shift all arches to use unsigned long long for
> > __u64?
>
> I doubt it - that would probably cause more warnings in the arch code.
In kernelspace, it's unsigned long long on all architectures.
In userspace, it may still be unsigned long on early 64-bit architectures.
> Instead, just explicitly cast it to unsigned long long.
Or use C99's PRIx64?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: linux-next: build failure after merge of the vfs tree
Hi David, On Wed, 19 Sep 2018 07:01:00 +0100 David Howells wrote: > > Stephen Rothwell wrote: > > > > I think the problem is that I haven't allocated system call numbers for > > > any arches other than x86 - even the x86 syscall numbers are provisional > > > until the patchset is taken upstream. I'm not sure of the best way to > > > deal with this - make the samples dependent on the X86 arch? > > > > But the sample programs are built with HOSTCC, so you can't depend on > > ARCH (since I, for one, am cross compiling). Maybe SUBARCH. Better > > would be to use either Kconfig's shell primitive or some make magic to > > figure out if the syscall number define's are defined. > > I meant put the dependency in the Kconfig. Yeah, sure. Kconfig now has the ability for that dependency to be the result of an external program "$(shell )", so you could have a script or program that checked to see if the syscall numbers are defined and then have the Kconfig symbol(s) for the tests depend on that. -- Cheers, Stephen Rothwell pgpKC7z8d1KX6.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
Stephen Rothwell wrote: > > I think the problem is that I haven't allocated system call numbers for > > any arches other than x86 - even the x86 syscall numbers are provisional > > until the patchset is taken upstream. I'm not sure of the best way to > > deal with this - make the samples dependent on the X86 arch? > > But the sample programs are built with HOSTCC, so you can't depend on > ARCH (since I, for one, am cross compiling). Maybe SUBARCH. Better > would be to use either Kconfig's shell primitive or some make magic to > figure out if the syscall number define's are defined. I meant put the dependency in the Kconfig. David
Re: linux-next: build failure after merge of the vfs tree
Hi David,
On Tue, 18 Sep 2018 23:17:21 +0100 David Howells wrote:
>
> Stephen Rothwell wrote:
>
> > > After merging the vfs tree, today's linux-next build (powerpc
> > > allyesconfig) failed like this:
> > >
> > > samples/vfs/test-fsinfo.c: In function 'fsinfo':
> > > samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first
> > > use in this function); did you mean 'fsinfo'?
>
> I think the problem is that I haven't allocated system call numbers for any
> arches other than x86 - even the x86 syscall numbers are provisional until the
> patchset is taken upstream. I'm not sure of the best way to deal with this -
> make the samples dependent on the X86 arch?
But the sample programs are built with HOSTCC, so you can't depend on
ARCH (since I, for one, am cross compiling). Maybe SUBARCH. Better
would be to use either Kconfig's shell primitive or some make magic to
figure out if the syscall number define's are defined.
> > > samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects argument
> > > of type 'long long unsigned int', but argument 2 has type '__u64' {aka
> > > 'long unsigned int'} [-Wformat=]
> > > printf("\tmax file size: %llx\n", f->max_file_size);
>
> Sigh. On powerpc __u64 is unsigned long, but on x86_64 it's unsigned long
> long. Is it possible to shift all arches to use unsigned long long for __u64?
I doubt it - that would probably cause more warnings in the arch code.
Instead, just explicitly cast it to unsigned long long.
--
Cheers,
Stephen Rothwell
pgpNMMUCxl2Y0.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
Stephen Rothwell wrote:
> > After merging the vfs tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> >
> > samples/vfs/test-fsinfo.c: In function 'fsinfo':
> > samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use
> > in this function); did you mean 'fsinfo'?
I think the problem is that I haven't allocated system call numbers for any
arches other than x86 - even the x86 syscall numbers are provisional until the
patchset is taken upstream. I'm not sure of the best way to deal with this -
make the samples dependent on the X86 arch?
> > samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects argument
> > of type 'long long unsigned int', but argument 2 has type '__u64' {aka
> > 'long unsigned int'} [-Wformat=]
> > printf("\tmax file size: %llx\n", f->max_file_size);
Sigh. On powerpc __u64 is unsigned long, but on x86_64 it's unsigned long
long. Is it possible to shift all arches to use unsigned long long for __u64?
David
Re: linux-next: build failure after merge of the vfs tree
Hi David, Al,
On Mon, 10 Sep 2018 13:35:25 +1000 Stephen Rothwell
wrote:
>
> After merging the vfs tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> samples/vfs/test-fsinfo.c: In function 'fsinfo':
> samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use
> in this function); did you mean 'fsinfo'?
> return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
> ^~~
> fsinfo
> samples/vfs/test-fsinfo.c:37:17: note: each undeclared identifier is reported
> only once for each function it appears in
> samples/vfs/test-fsinfo.c: In function 'dump_attr_LIMITS':
> samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax file size: %llx\n", f->max_file_size);
>~~~^
>%lx
> samples/vfs/test-fsinfo.c:181:32: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax ids : u=%llx g=%llx p=%llx\n",
> ~~~^
> %lx
> f->max_uid, f->max_gid, f->max_projid);
> ~~
> samples/vfs/test-fsinfo.c:181:39: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 3 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax ids : u=%llx g=%llx p=%llx\n",
> ~~~^
> %lx
> f->max_uid, f->max_gid, f->max_projid);
> ~~
> samples/vfs/test-fsinfo.c:181:46: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 4 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tmax ids : u=%llx g=%llx p=%llx\n",
>~~~^
>%lx
> f->max_uid, f->max_gid, f->max_projid);
> ~
> samples/vfs/test-fsinfo.c: In function 'dump_attr_SUPPORTS':
> samples/vfs/test-fsinfo.c:197:24: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
> printf("\tstx_attr=%llx\n", f->stx_attributes);
> ~~~^ ~
> %lx
> samples/vfs/test-fsmount.c: In function 'fsopen':
> samples/vfs/test-fsmount.c:63:17: error: '__NR_fsopen' undeclared (first use
> in this function); did you mean 'fsopen'?
> return syscall(__NR_fsopen, fs_name, flags);
> ^~~
> fsopen
> samples/vfs/test-fsmount.c:63:17: note: each undeclared identifier is
> reported only once for each function it appears in
> samples/vfs/test-fsmount.c: In function 'fsmount':
> samples/vfs/test-fsmount.c:68:17: error: '__NR_fsmount' undeclared (first use
> in this function); did you mean 'fsmount'?
> return syscall(__NR_fsmount, fsfd, flags, ms_flags);
> ^~~~
> fsmount
> samples/vfs/test-fsmount.c: In function 'fsconfig':
> samples/vfs/test-fsmount.c:74:17: error: '__NR_fsconfig' undeclared (first
> use in this function); did you mean 'fsconfig'?
> return syscall(__NR_fsconfig, fsfd, cmd, key, val, aux);
> ^
> fsconfig
> samples/vfs/test-fsmount.c: In function 'move_mount':
> samples/vfs/test-fsmount.c:81:17: error: '__NR_move_mount' undeclared (first
> use in this function); did you mean 'move_mount'?
> return syscall(__NR_move_mount,
> ^~~
> move_mount
> samples/vfs/test-fs-query.c: In function 'fsopen':
> samples/vfs/test-fs-query.c:32:17: error: '__NR_fsopen' undeclared (first use
> in this function); did you mean 'fsopen'?
> return syscall(__NR_fsopen, fs_name, flags);
> ^~~
> fsopen
> samples/vfs/test-fs-query.c:32:17: note: each undeclared identifier is
> reported only once for each function it appears in
> samples/vfs/test-fs-query.c: In function 'fsinfo':
> samples/vfs/test-fs-query.c:38:17: error: '__NR_fsinfo' undeclared (first use
> in this function); did you mean 'fsinfo'?
> return syscall(__NR_fsinfo, dfd, filename, params, buffer, buf_size);
> ^~~
> fsinfo
> samples/vfs/test-statx.c: In function 'dump_statx':
> samples/vfs/test-statx.c:160:29: warning: format '%llx' expects argument of
> type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long
> unsigned int'} [-Wformat=]
>printf("Attributes: %016llx (", stx->stx_attributes);
>~~^ ~~~
>
Re: linux-next: build failure after merge of the vfs tree
2018-08-07 9:59 GMT+09:00 Stephen Rothwell :
> Hi all,
>
> On Mon, 6 Aug 2018 22:24:01 +1000 Stephen Rothwell
> wrote:
>>
>> On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell
>> wrote:
>> >
>> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
>> > failed like this:
>> >
>> > samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such
>> > file or directory
>> > #include
>> > ^~~~
>> >
>> > Caused by commit
>> >
>> > 90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem
>> > information")
>> >
>> > I guess that headers_install (or whatever its called) has not bee run
>> > before the sample code is built.
>> >
>> > I have applied the following patch for today:
>> >
>> > From: Stephen Rothwell
>> > Date: Mon, 6 Aug 2018 10:29:34 +1000
>> > Subject: [PATCH] vfs: don;t build new sample programs yet
>> >
>> > It seems that headers_install is not done before the samples
>> > are build so some needed include files are not in the right place.
>> >
>> > Signed-off-by: Stephen Rothwell
>> > ---
>> > samples/statx/Makefile | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/samples/statx/Makefile b/samples/statx/Makefile
>> > index 05b4d30cdd3c..0b4d01822eca 100644
>> > --- a/samples/statx/Makefile
>> > +++ b/samples/statx/Makefile
>> > @@ -1,5 +1,5 @@
>> > # List of programs to build
>> > -hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
>> > +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
>> >
>> > # Tell kbuild to always build the programs
>> > always := $(hostprogs-y)
>>
>> It turns out that commit
>>
>> ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")
>>
>> removed the "depends on BROKEN" from CONFIG_SAMPLE_STATX and that
>> breaks other builds (at least allyesconfig on s390).
>
> I have added the following suggested patch (I am sorry I can't
> find/remember who pointed me to this patch) for today (I guess that it
> should be merged via the vfs tree as that is what is causing the build
> failures ... in which case a real patch should be supplied with
> appropriate SOB line). This seems to fix the current problem.
>
> From: Masahiro Yamada
> Date: Tue, 7 Aug 2018 10:33:43 +1000
> Subject: [PATCH] Try to get the headers installed before we build the samples
>
> Signed-off-by: Stephen Rothwell
> ---
> Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Makefile b/Makefile
> index 9e71826f67d7..d224d94c14be 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1023,6 +1023,7 @@ endif
> # Build samples along the rest of the kernel
> ifdef CONFIG_SAMPLES
> vmlinux-dirs += samples
> +samples: headers_install
> endif
>
> # The actual objects are generated when descending,
> --
OK, I will queue this up to my tree.
I suggested this in the discussion:
https://patchwork.kernel.org/patch/10552353/
I did not get response, though.
--
Best Regards
Masahiro Yamada
Re: linux-next: build failure after merge of the vfs tree
Hi all,
On Mon, 6 Aug 2018 22:24:01 +1000 Stephen Rothwell
wrote:
>
> On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such
> > file or directory
> > #include
> > ^~~~
> >
> > Caused by commit
> >
> > 90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem
> > information")
> >
> > I guess that headers_install (or whatever its called) has not bee run
> > before the sample code is built.
> >
> > I have applied the following patch for today:
> >
> > From: Stephen Rothwell
> > Date: Mon, 6 Aug 2018 10:29:34 +1000
> > Subject: [PATCH] vfs: don;t build new sample programs yet
> >
> > It seems that headers_install is not done before the samples
> > are build so some needed include files are not in the right place.
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > samples/statx/Makefile | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/samples/statx/Makefile b/samples/statx/Makefile
> > index 05b4d30cdd3c..0b4d01822eca 100644
> > --- a/samples/statx/Makefile
> > +++ b/samples/statx/Makefile
> > @@ -1,5 +1,5 @@
> > # List of programs to build
> > -hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
> > +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
> >
> > # Tell kbuild to always build the programs
> > always := $(hostprogs-y)
>
> It turns out that commit
>
> ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")
>
> removed the "depends on BROKEN" from CONFIG_SAMPLE_STATX and that
> breaks other builds (at least allyesconfig on s390).
I have added the following suggested patch (I am sorry I can't
find/remember who pointed me to this patch) for today (I guess that it
should be merged via the vfs tree as that is what is causing the build
failures ... in which case a real patch should be supplied with
appropriate SOB line). This seems to fix the current problem.
From: Masahiro Yamada
Date: Tue, 7 Aug 2018 10:33:43 +1000
Subject: [PATCH] Try to get the headers installed before we build the samples
Signed-off-by: Stephen Rothwell
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 9e71826f67d7..d224d94c14be 100644
--- a/Makefile
+++ b/Makefile
@@ -1023,6 +1023,7 @@ endif
# Build samples along the rest of the kernel
ifdef CONFIG_SAMPLES
vmlinux-dirs += samples
+samples: headers_install
endif
# The actual objects are generated when descending,
--
2.18.0
--
Cheers,
Stephen Rothwell
pgpL_pp3DmTjt.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
Hi all,
On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such file
> or directory
> #include
> ^~~~
>
> Caused by commit
>
> 90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem information")
>
> I guess that headers_install (or whatever its called) has not bee run
> before the sample code is built.
>
> I have applied the following patch for today:
>
> From: Stephen Rothwell
> Date: Mon, 6 Aug 2018 10:29:34 +1000
> Subject: [PATCH] vfs: don;t build new sample programs yet
>
> It seems that headers_install is not done before the samples
> are build so some needed include files are not in the right place.
>
> Signed-off-by: Stephen Rothwell
> ---
> samples/statx/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/samples/statx/Makefile b/samples/statx/Makefile
> index 05b4d30cdd3c..0b4d01822eca 100644
> --- a/samples/statx/Makefile
> +++ b/samples/statx/Makefile
> @@ -1,5 +1,5 @@
> # List of programs to build
> -hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
> +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
>
> # Tell kbuild to always build the programs
> always := $(hostprogs-y)
It turns out that commit
ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")
removed the "depends on BROKEN" from CONFIG_SAMPLE_STATX and that
breaks other builds (at least allyesconfig on s390).
--
Cheers,
Stephen Rothwell
pgppJoM7PLodw.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
Hi Al,
On Sun, 8 Apr 2018 03:19:56 +0100 Al Viro wrote:
>
> > > Caused by commit
> > >
> > > 92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
> > >
> > > I have reverted that commit for today.
> >
> > I am still doing that revert ...
>
> That's interesting, seeing that this commit is *not* in #for-next and
> 08fdc8a0138a should not have that problem...
I do the revert by applying a reverse patch (initially generated by a
"git revert"). That reverse patch still applies cleanly, so I have no
easy way to tell that this problem has been fixed (except by trying
without the reverse patch each day - which would add a significant cost
to my work as that patch touches linux/fs.h).
Anyway, thanks for letting me know, I will remove the reverse patch
from tomorrow.
--
Cheers,
Stephen Rothwell
pgpPDpY08iQ_Y.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
On Tue, Apr 03, 2018 at 12:26:29PM +1000, Stephen Rothwell wrote:
> Hi Al,
>
> On Mon, 19 Mar 2018 17:06:27 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> > failed like this:
> >
> > fs/super.c: In function 'do_thaw_all_callback':
> > fs/super.c:942:3: error: implicit declaration of function
> > 'emergency_thaw_bdev'; did you mean 'emergency_remount'?
> > [-Werror=implicit-function-declaration]
> >emergency_thaw_bdev(sb);
> >^~~
> >emergency_remount
> >
> > Caused by commit
> >
> > 92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
> >
> > I have reverted that commit for today.
>
> I am still doing that revert ...
That's interesting, seeing that this commit is *not* in #for-next and
08fdc8a0138a should not have that problem...
Re: linux-next: build failure after merge of the vfs tree
Hi Al,
On Mon, 19 Mar 2018 17:06:27 +1100 Stephen Rothwell
wrote:
>
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
>
> fs/super.c: In function 'do_thaw_all_callback':
> fs/super.c:942:3: error: implicit declaration of function
> 'emergency_thaw_bdev'; did you mean 'emergency_remount'?
> [-Werror=implicit-function-declaration]
>emergency_thaw_bdev(sb);
>^~~
>emergency_remount
>
> Caused by commit
>
> 92afc556e622 ("buffer.c: call thaw_super during emergency thaw")
>
> I have reverted that commit for today.
I am still doing that revert ...
--
Cheers,
Stephen Rothwell
pgpWF3Hbjzbmz.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
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
Re: linux-next: build failure after merge of the vfs tree
Stephen Rothwell wrote: > - if (inode->i_mode & S_IALLUGO != 0775) > + if ((inode->i_mode & S_IALLUGO) != 0775) Acked-by: David Howells
Re: linux-next: build failure after merge of the vfs tree
On Mon, Jul 10, 2017 at 12:15:11PM +1000, Stephen Rothwell wrote:
> Hi Al,
> Caused by commit
>
> 4f9365d9e2e7 ("spufs: Implement show_options")
Obvious incremental follows, will fold and push
diff --git a/arch/powerpc/platforms/cell/spufs/inode.c
b/arch/powerpc/platforms/cell/spufs/inode.c
index 27a51a60bc33..e210d69b 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -608,15 +608,16 @@ static const match_table_t spufs_tokens = {
static int spufs_show_options(struct seq_file *m, struct dentry *root)
{
struct spufs_sb_info *sbi = spufs_get_sb_info(root->d_sb);
+ struct inode *inode = root->d_inode;
- if (!uid_eq(root->i_uid, GLOBAL_ROOT_UID))
+ if (!uid_eq(inode->i_uid, GLOBAL_ROOT_UID))
seq_printf(m, ",uid=%u",
- from_kuid_munged(&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;
Re: linux-next: build failure after merge of the vfs tree
Stephen Rothwell wrote: > From: Stephen Rothwell > Date: Mon, 27 Feb 2017 11:21:47 +1100 > Subject: [PATCH] statx: disable the sample code for now > > Signed-off-by: Stephen Rothwell > --- > samples/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/samples/Kconfig b/samples/Kconfig > index e1fc9a6a96fa..9cb63188d3ef 100644 > --- a/samples/Kconfig > +++ b/samples/Kconfig > @@ -114,6 +114,7 @@ config SAMPLE_VFIO_MDEV_MTTY > > config SAMPLE_STATX > bool "Build example extended-stat using code" > + depends on BROKEN > help > Build example userspace program to use the new extended-stat syscall. > It turns out that the statx sample depends on the header installation phase of the build. I'm not sure how to encode that fact in the Makefile, so marking it broken for now is fine. Acked-by: David Howells
Re: linux-next: build failure after merge of the vfs tree
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.
Re: linux-next: build failure after merge of the vfs tree
Hi Al/Stephen
- Original Message -
> From: "Al Viro"
> To: "Stephen Rothwell"
> Cc: "Steven Whitehouse" , "Bob Peterson"
> , linux-n...@vger.kernel.org,
> linux-kernel@vger.kernel.org, "Abhi Das"
> 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
> > 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
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
> 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.
Re: linux-next: build failure after merge of the vfs tree
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
Hi all,
On Mon, 21 Dec 2015 11:23:01 +1100 Stephen Rothwell
wrote:
>
> On Thu, 10 Dec 2015 11:18:47 +1100 Stephen Rothwell
> 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
> > 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
> > ---
> > 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
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
---
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_ope
Re: linux-next: build failure after merge of the vfs tree
Hi Stephen,
On Thu, 10 Dec 2015 11:18:47 +1100 Stephen Rothwell
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
> 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
> ---
> 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 Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
> 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 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
[Just adding the origefs maintainer to the cc list]
On Thu, 10 Dec 2015 11:18:47 +1100 Stephen Rothwell
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
> 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
> ---
> 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 Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
2015-12-09 23:20 GMT+01:00 Stephen Rothwell : > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
Hi Mike, On Wed, 9 Dec 2015 16:30:34 -0500 Mike Marshall 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 Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
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 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
> Date: Wed, 9 Dec 2015 12:13:37 +1100
> Subject: [PATCH] orangefs: update for POSIX ACL name changes
>
> Signed-off-by: Stephen Rothwell
> ---
> 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 Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
Hi all,
On Mon, 11 May 2015 11:26:12 +1000 Stephen Rothwell
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
> 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
> ---
> 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
Date: Wed, 13 May 2015 11:03:18 +1000
Re: linux-next: build failure after merge of the vfs tree
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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
Hi Al,
On Fri, 13 Mar 2015 12:02:50 +1100 Stephen Rothwell
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
> 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
> ---
> 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 @@
> * (s...@redhat.com), 1993, 1998
> */
>
> +#include
> +
> #include "ext4_jbd2.h"
> #include "truncate.h"
>
> --
> 2.1.4
I am still applying the above patch every day ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp4wKKKMUsYs.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the vfs tree
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 > #include > #include > +#include > +#include 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
Hi Al,
On Tue, 22 Apr 2014 11:26:53 +1000 Stephen Rothwell
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
Date: Wed, 23 Apr 2014 10:29:35 +1000
Subject: [PATCH] vfs: using vfree requires including vmalloc.h
Signed-off-by: Stephen Rothwell
---
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
#include
#include
+#include
#include
#include
--
1.9.2
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpNvy7SIUyqL.pgp
Description: PGP signature
Re: linux-next: build failure after merge of the vfs tree
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
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
> Date: Wed, 1 May 2013 12:19:43 +1000
> Subject: [PATCH] SUNRPC: update for PDE removal
>
> Signed-off-by: Stephen Rothwell
> ---
> 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 Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
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 ;-/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the vfs tree
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
