lkml.org 
[lkml]   [2018]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: linux-next: build failure after merge of the xarray tree
On Sun, Jun 17, 2018 at 8:27 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the xarray tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from arch/powerpc/include/asm/bug.h:128:0,
> from include/linux/bug.h:5,
> from arch/powerpc/include/asm/cmpxchg.h:9,
> from arch/powerpc/include/asm/atomic.h:11,
> from include/linux/atomic.h:5,
> from fs/dax.c:17:
> fs/dax.c: In function 'dax_lock_page':
> fs/dax.c:392:21: error: implicit declaration of function 'radix_tree_exceptional_entry'; did you mean 'radix_tree_exception'? [-Werror=implicit-function-declaration]
> WARN_ON_ONCE(!radix_tree_exceptional_entry(entry))) {
> ^
> include/asm-generic/bug.h:69:25: note: in definition of macro 'WARN_ON_ONCE'
> int __ret_warn_on = !!(condition); \
> ^~~~~~~~~
> fs/dax.c:395:15: error: implicit declaration of function 'slot_locked'; did you mean 'iget_locked'? [-Werror=implicit-function-declaration]
> } else if (!slot_locked(mapping, slot)) {
> ^~~~~~~~~~~
> iget_locked
> fs/dax.c:396:4: error: implicit declaration of function 'lock_slot'; did you mean 'local_set'? [-Werror=implicit-function-declaration]
> lock_slot(mapping, slot);
> ^~~~~~~~~
> local_set
> fs/dax.c:402:28: error: passing argument 1 of 'dax_entry_waitqueue' from incompatible pointer type [-Werror=incompatible-pointer-types]
> wq = dax_entry_waitqueue(mapping, index, entry, &ewait.key);
> ^~~~~~~
> fs/dax.c:152:27: note: expected 'struct xa_state *' but argument is of type 'struct address_space *'
> static wait_queue_head_t *dax_entry_waitqueue(struct xa_state *xas,
> ^~~~~~~~~~~~~~~~~~~
> fs/dax.c:402:37: warning: passing argument 2 of 'dax_entry_waitqueue' makes pointer from integer without a cast [-Wint-conversion]
> wq = dax_entry_waitqueue(mapping, index, entry, &ewait.key);
> ^~~~~
> fs/dax.c:152:27: note: expected 'void *' but argument is of type 'long unsigned int'
> static wait_queue_head_t *dax_entry_waitqueue(struct xa_state *xas,
> ^~~~~~~~~~~~~~~~~~~
> fs/dax.c:402:8: error: too many arguments to function 'dax_entry_waitqueue'
> wq = dax_entry_waitqueue(mapping, index, entry, &ewait.key);
> ^~~~~~~~~~~~~~~~~~~
> fs/dax.c:152:27: note: declared here
> static wait_queue_head_t *dax_entry_waitqueue(struct xa_state *xas,
> ^~~~~~~~~~~~~~~~~~~
> fs/dax.c: In function 'dax_unlock_page':
> fs/dax.c:424:2: error: implicit declaration of function 'dax_unlock_mapping_entry'; did you mean 'dax_delete_mapping_entry'? [-Werror=implicit-function-declaration]
> dax_unlock_mapping_entry(mapping, page->index);
> ^~~~~~~~~~~~~~~~~~~~~~~~
> dax_delete_mapping_entry
>
> Caused by commits in the xarray tree interacting with commit
>
> 9b3d53936caa ("filesystem-dax: Introduce dax_lock_page()")
>
> from the nvdimm tree.
>
> Willy thanks for the heads up about this.
>
> I have applied the following merge fix patch (taken from the diff between
> the -next tree at this point and the xarray-20180615 branch from the
> xarray tree) for today.

I was hoping that dax_lock_page() and the memory_failure() handling
could go in before the xarray rework. This helps -stable and distros
that need to backport this error handling support. Willy, would you be
amenable to rebasing on top of the next rev of the
dax+memory_failure() work?

Apologies for the thrash.

\
 
 \ /
  Last update: 2018-06-18 18:51    [W:1.356 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site