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

[Stephen Rothwell]

Hi Dan,

On Fri, 5 Jul 2019 15:32:19 -0700 Dan Williams  wrote:
>
> On Fri, Jul 5, 2019 at 12:20 AM Stephen Rothwell  
> wrote:
> >
> > After merging the nvdimm tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from :32:
> > ./usr/include/linux/virtio_pmem.h:19:2: error: unknown type name 'uint64_t'
> >   uint64_t start;
> >   ^~~~
> > ./usr/include/linux/virtio_pmem.h:20:2: error: unknown type name 'uint64_t'
> >   uint64_t size;
> >   ^~~~  
> 
> /me boggles at how this sat in 0day visible tree for a long while
> without this report?

These messages are produced by a new test in the kbuild tree, so you
need both it and the nvdimm tree together to get them.  That will
change after the merge window, of course.

-- 
Cheers,
Stephen Rothwell


pgprPiDpkHvI1.pgp
Description: OpenPGP digital signature

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

[Dan Williams]

On Fri, Jul 5, 2019 at 12:20 AM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the nvdimm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from :32:
> ./usr/include/linux/virtio_pmem.h:19:2: error: unknown type name 'uint64_t'
>   uint64_t start;
>   ^~~~
> ./usr/include/linux/virtio_pmem.h:20:2: error: unknown type name 'uint64_t'
>   uint64_t size;
>   ^~~~

/me boggles at how this sat in 0day visible tree for a long while
without this report?

>
> Caused by commit
>
>   403b7f973855 ("virtio-pmem: Add virtio pmem driver")
>
> I have used the nvdimm tree from next-20190704 for today.

Thanks Stephen, sorry for the noise.

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

[Pankaj Gupta]

> 
> Hi Pankaj,
> 
> On Fri, 5 Jul 2019 04:45:43 -0400 (EDT) Pankaj Gupta 
> wrote:
> >
> > Thank you for the report.
> 
> That's what I am here for :-)

:-)

> 
> > Can we apply below patch [1] on top to complete linux-next build for today.
> > I have tested this locally.
> 
> Its a bit of a pain to go back and linux-next is done for today (after
> 13 hours :-)).  You really should do a proper fix patch and get it
> added to the nvdimm tree.

Sure, Thank you! Stephen.

Best regards,
Pankaj

> 
> --
> Cheers,
> Stephen Rothwell
> 

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

[Stephen Rothwell]

Hi Pankaj,

On Fri, 5 Jul 2019 04:45:43 -0400 (EDT) Pankaj Gupta  wrote:
>
> Thank you for the report.

That's what I am here for :-)

> Can we apply below patch [1] on top to complete linux-next build for today.
> I have tested this locally.

Its a bit of a pain to go back and linux-next is done for today (after
13 hours :-)).  You really should do a proper fix patch and get it
added to the nvdimm tree.

-- 
Cheers,
Stephen Rothwell


pgpXsumFJXAyC.pgp
Description: OpenPGP digital signature

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

[Pankaj Gupta]

Hi Stephen,
> 
> Hi all,
> 
> After merging the nvdimm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from :32:
> ./usr/include/linux/virtio_pmem.h:19:2: error: unknown type name 'uint64_t'
>   uint64_t start;
>   ^~~~
> ./usr/include/linux/virtio_pmem.h:20:2: error: unknown type name 'uint64_t'
>   uint64_t size;
>   ^~~~
> 
> Caused by commit
> 
>   403b7f973855 ("virtio-pmem: Add virtio pmem driver")
> 
> I have used the nvdimm tree from next-20190704 for today.

Thank you for the report.

Can we apply below patch [1] on top to complete linux-next build for today.
I have tested this locally.

Thanks,
Pankaj



[1]

diff --git a/drivers/nvdimm/virtio_pmem.h b/drivers/nvdimm/virtio_pmem.h
index 998efbc7660c..dbc12dfe8067 100644
--- a/drivers/nvdimm/virtio_pmem.h
+++ b/drivers/nvdimm/virtio_pmem.h
@@ -46,8 +46,8 @@ struct virtio_pmem {
spinlock_t pmem_lock;
 
/* Memory region information */
-   uint64_t start;
-   uint64_t size;
+   u64 start;
+   u64 size;
 };
 
 void virtio_pmem_host_ack(struct virtqueue *vq);
diff --git a/include/uapi/linux/virtio_pmem.h b/include/uapi/linux/virtio_pmem.h
index 379861f114f1..efcd72f2d20d 100644
--- a/include/uapi/linux/virtio_pmem.h
+++ b/include/uapi/linux/virtio_pmem.h
@@ -11,25 +11,24 @@
 #define _UAPI_LINUX_VIRTIO_PMEM_H
 
 #include 
-#include 
 #include 
 #include 
 
 struct virtio_pmem_config {
-   uint64_t start;
-   uint64_t size;
+   __u64 start;
+   __u64 size;
 };
 
 #define VIRTIO_PMEM_REQ_TYPE_FLUSH  0
 
 struct virtio_pmem_resp {
/* Host return status corresponding to flush request */
-   __virtio32 ret;
+   __u32 ret;
 };
 
 struct virtio_pmem_req {
/* command type */
-   __virtio32 type;
+   __u32 type;
 };

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

[Pankaj Gupta]

> Hi Dan,
> 
> After merging the nvdimm tree, today's linux-next build (i386 defconfig)
> failed like this:
> 
> drivers/md/dm-table.c: In function 'device_synchronous':
> drivers/md/dm-table.c:897:9: error: implicit declaration of function
> 'dax_synchronous'; did you mean 'device_synchronous'?
> [-Werror=implicit-function-declaration]
>   return dax_synchronous(dev->dax_dev);
>  ^~~
>  device_synchronous
> drivers/md/dm-table.c: In function 'dm_table_set_restrictions':
> drivers/md/dm-table.c:1925:4: error: implicit declaration of function
> 'set_dax_synchronous'; did you mean 'device_synchronous'?
> [-Werror=implicit-function-declaration]
> set_dax_synchronous(t->md->dax_dev);
> ^~~
> device_synchronous
> cc1: some warnings being treated as errors
> 
> Caused by commit
> 
>   38887edec247 ("dm: enable synchronous dax")
> 
> CONFIG_DAX is not set for this build.

Moving 'dax_synchronous' & 'set_dax_synchronous' function declaration
out of CONFIG_DAX should fix this. This will make compiler aware about 
'device_synchronous' function for non DAX archs as well.

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

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

[Dan Williams]

On Mon, Apr 9, 2018 at 10:11 AM, Dan Williams  wrote:
> On Mon, Apr 9, 2018 at 12:34 AM, Oliver  wrote:
>> On Mon, Apr 9, 2018 at 1:38 PM, Oliver  wrote:
>>> On Mon, Apr 9, 2018 at 1:16 PM, Stephen Rothwell  
>>> wrote:
 Hi Dan,

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

 ERROR: "of_node_to_nid" [drivers/nvdimm/of_pmem.ko] undefined!

 Caused by commit

   717197608952 ("libnvdimm: Add device-tree based driver")

 X86 seems to not have a version of of_node_to_nid() even though CONFIG_OF
 and CONFIG_NUMA are both 'y' in this build.
>>>
>>> It's a side effect of a driver selecting CONFIG_OF accidently. There's
>>> a patch to fix this in the drm-misc-next tree:
>>>
>>> https://lkml.org/lkml/2018/4/3/17
>>>
 I have used the nvdimm tree from next-20180406 for today.
>>>
>>> That works too.
>>
>> Hmm, on closer inspection this is actually a bug in the of driver. The
>> patch above fixes the specific problem that we hit on ia64 due to
>> CONFIG_OF being selected by accident, but the underlying issue will
>> affect any platform that doesn't provide an implementation of
>> of_node_to_nid().
>>
>> The fundamental problem is that the various actual implementations of
>> of_node_to_nid (ppc, sparc and the generic one in of_numa.c) export
>> the symbol. While the fallback implementation does not because it is
>> defined as a weak symbol. As a result we'll get this build failure iff
>> there's a call to of_node_to_nid() in a module.
>>
>> The one-line fix is just to delete the call to of_node_to_nid() in
>> of_pmem.c. I have a patch that adds a Kconfig options and removes the
>> weak symbol games. That needs Acks from the ppc, sparc and DT
>> maintainers though so it'll take longer to organise.
>
> How about just marking OF_PMEM as bool for the time being until all of
> these other reworks land upstream?

I went ahead and just pushed this workaround for now:

https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/commit/?h=libnvdimm-for-next=291717b6fbdb175da88ae2144fc58d63a490128d

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

[Dan Williams]

On Mon, Apr 9, 2018 at 10:11 AM, Dan Williams  wrote:
> On Mon, Apr 9, 2018 at 12:34 AM, Oliver  wrote:
>> On Mon, Apr 9, 2018 at 1:38 PM, Oliver  wrote:
>>> On Mon, Apr 9, 2018 at 1:16 PM, Stephen Rothwell  
>>> wrote:
 Hi Dan,

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

 ERROR: "of_node_to_nid" [drivers/nvdimm/of_pmem.ko] undefined!

 Caused by commit

   717197608952 ("libnvdimm: Add device-tree based driver")

 X86 seems to not have a version of of_node_to_nid() even though CONFIG_OF
 and CONFIG_NUMA are both 'y' in this build.
>>>
>>> It's a side effect of a driver selecting CONFIG_OF accidently. There's
>>> a patch to fix this in the drm-misc-next tree:
>>>
>>> https://lkml.org/lkml/2018/4/3/17
>>>
 I have used the nvdimm tree from next-20180406 for today.
>>>
>>> That works too.
>>
>> Hmm, on closer inspection this is actually a bug in the of driver. The
>> patch above fixes the specific problem that we hit on ia64 due to
>> CONFIG_OF being selected by accident, but the underlying issue will
>> affect any platform that doesn't provide an implementation of
>> of_node_to_nid().
>>
>> The fundamental problem is that the various actual implementations of
>> of_node_to_nid (ppc, sparc and the generic one in of_numa.c) export
>> the symbol. While the fallback implementation does not because it is
>> defined as a weak symbol. As a result we'll get this build failure iff
>> there's a call to of_node_to_nid() in a module.
>>
>> The one-line fix is just to delete the call to of_node_to_nid() in
>> of_pmem.c. I have a patch that adds a Kconfig options and removes the
>> weak symbol games. That needs Acks from the ppc, sparc and DT
>> maintainers though so it'll take longer to organise.
>
> How about just marking OF_PMEM as bool for the time being until all of
> these other reworks land upstream?

I went ahead and just pushed this workaround for now:

https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/commit/?h=libnvdimm-for-next=291717b6fbdb175da88ae2144fc58d63a490128d

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

[Dan Williams]

On Mon, Apr 9, 2018 at 12:34 AM, Oliver  wrote:
> On Mon, Apr 9, 2018 at 1:38 PM, Oliver  wrote:
>> On Mon, Apr 9, 2018 at 1:16 PM, Stephen Rothwell  
>> wrote:
>>> Hi Dan,
>>>
>>> After merging the nvdimm tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> ERROR: "of_node_to_nid" [drivers/nvdimm/of_pmem.ko] undefined!
>>>
>>> Caused by commit
>>>
>>>   717197608952 ("libnvdimm: Add device-tree based driver")
>>>
>>> X86 seems to not have a version of of_node_to_nid() even though CONFIG_OF
>>> and CONFIG_NUMA are both 'y' in this build.
>>
>> It's a side effect of a driver selecting CONFIG_OF accidently. There's
>> a patch to fix this in the drm-misc-next tree:
>>
>> https://lkml.org/lkml/2018/4/3/17
>>
>>> I have used the nvdimm tree from next-20180406 for today.
>>
>> That works too.
>
> Hmm, on closer inspection this is actually a bug in the of driver. The
> patch above fixes the specific problem that we hit on ia64 due to
> CONFIG_OF being selected by accident, but the underlying issue will
> affect any platform that doesn't provide an implementation of
> of_node_to_nid().
>
> The fundamental problem is that the various actual implementations of
> of_node_to_nid (ppc, sparc and the generic one in of_numa.c) export
> the symbol. While the fallback implementation does not because it is
> defined as a weak symbol. As a result we'll get this build failure iff
> there's a call to of_node_to_nid() in a module.
>
> The one-line fix is just to delete the call to of_node_to_nid() in
> of_pmem.c. I have a patch that adds a Kconfig options and removes the
> weak symbol games. That needs Acks from the ppc, sparc and DT
> maintainers though so it'll take longer to organise.

How about just marking OF_PMEM as bool for the time being until all of
these other reworks land upstream?

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

[Dan Williams]

On Mon, Apr 9, 2018 at 12:34 AM, Oliver  wrote:
> On Mon, Apr 9, 2018 at 1:38 PM, Oliver  wrote:
>> On Mon, Apr 9, 2018 at 1:16 PM, Stephen Rothwell  
>> wrote:
>>> Hi Dan,
>>>
>>> After merging the nvdimm tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> ERROR: "of_node_to_nid" [drivers/nvdimm/of_pmem.ko] undefined!
>>>
>>> Caused by commit
>>>
>>>   717197608952 ("libnvdimm: Add device-tree based driver")
>>>
>>> X86 seems to not have a version of of_node_to_nid() even though CONFIG_OF
>>> and CONFIG_NUMA are both 'y' in this build.
>>
>> It's a side effect of a driver selecting CONFIG_OF accidently. There's
>> a patch to fix this in the drm-misc-next tree:
>>
>> https://lkml.org/lkml/2018/4/3/17
>>
>>> I have used the nvdimm tree from next-20180406 for today.
>>
>> That works too.
>
> Hmm, on closer inspection this is actually a bug in the of driver. The
> patch above fixes the specific problem that we hit on ia64 due to
> CONFIG_OF being selected by accident, but the underlying issue will
> affect any platform that doesn't provide an implementation of
> of_node_to_nid().
>
> The fundamental problem is that the various actual implementations of
> of_node_to_nid (ppc, sparc and the generic one in of_numa.c) export
> the symbol. While the fallback implementation does not because it is
> defined as a weak symbol. As a result we'll get this build failure iff
> there's a call to of_node_to_nid() in a module.
>
> The one-line fix is just to delete the call to of_node_to_nid() in
> of_pmem.c. I have a patch that adds a Kconfig options and removes the
> weak symbol games. That needs Acks from the ppc, sparc and DT
> maintainers though so it'll take longer to organise.

How about just marking OF_PMEM as bool for the time being until all of
these other reworks land upstream?

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

[Oliver]

On Mon, Apr 9, 2018 at 1:38 PM, Oliver  wrote:
> On Mon, Apr 9, 2018 at 1:16 PM, Stephen Rothwell  
> wrote:
>> Hi Dan,
>>
>> After merging the nvdimm tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> ERROR: "of_node_to_nid" [drivers/nvdimm/of_pmem.ko] undefined!
>>
>> Caused by commit
>>
>>   717197608952 ("libnvdimm: Add device-tree based driver")
>>
>> X86 seems to not have a version of of_node_to_nid() even though CONFIG_OF
>> and CONFIG_NUMA are both 'y' in this build.
>
> It's a side effect of a driver selecting CONFIG_OF accidently. There's
> a patch to fix this in the drm-misc-next tree:
>
> https://lkml.org/lkml/2018/4/3/17
>
>> I have used the nvdimm tree from next-20180406 for today.
>
> That works too.

Hmm, on closer inspection this is actually a bug in the of driver. The
patch above fixes the specific problem that we hit on ia64 due to
CONFIG_OF being selected by accident, but the underlying issue will
affect any platform that doesn't provide an implementation of
of_node_to_nid().

The fundamental problem is that the various actual implementations of
of_node_to_nid (ppc, sparc and the generic one in of_numa.c) export
the symbol. While the fallback implementation does not because it is
defined as a weak symbol. As a result we'll get this build failure iff
there's a call to of_node_to_nid() in a module.

The one-line fix is just to delete the call to of_node_to_nid() in
of_pmem.c. I have a patch that adds a Kconfig options and removes the
weak symbol games. That needs Acks from the ppc, sparc and DT
maintainers though so it'll take longer to organise.

Oliver

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

[Oliver]

On Mon, Apr 9, 2018 at 1:38 PM, Oliver  wrote:
> On Mon, Apr 9, 2018 at 1:16 PM, Stephen Rothwell  
> wrote:
>> Hi Dan,
>>
>> After merging the nvdimm tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> ERROR: "of_node_to_nid" [drivers/nvdimm/of_pmem.ko] undefined!
>>
>> Caused by commit
>>
>>   717197608952 ("libnvdimm: Add device-tree based driver")
>>
>> X86 seems to not have a version of of_node_to_nid() even though CONFIG_OF
>> and CONFIG_NUMA are both 'y' in this build.
>
> It's a side effect of a driver selecting CONFIG_OF accidently. There's
> a patch to fix this in the drm-misc-next tree:
>
> https://lkml.org/lkml/2018/4/3/17
>
>> I have used the nvdimm tree from next-20180406 for today.
>
> That works too.

Hmm, on closer inspection this is actually a bug in the of driver. The
patch above fixes the specific problem that we hit on ia64 due to
CONFIG_OF being selected by accident, but the underlying issue will
affect any platform that doesn't provide an implementation of
of_node_to_nid().

The fundamental problem is that the various actual implementations of
of_node_to_nid (ppc, sparc and the generic one in of_numa.c) export
the symbol. While the fallback implementation does not because it is
defined as a weak symbol. As a result we'll get this build failure iff
there's a call to of_node_to_nid() in a module.

The one-line fix is just to delete the call to of_node_to_nid() in
of_pmem.c. I have a patch that adds a Kconfig options and removes the
weak symbol games. That needs Acks from the ppc, sparc and DT
maintainers though so it'll take longer to organise.

Oliver

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

[Oliver]

On Mon, Apr 9, 2018 at 1:16 PM, Stephen Rothwell  wrote:
> Hi Dan,
>
> After merging the nvdimm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "of_node_to_nid" [drivers/nvdimm/of_pmem.ko] undefined!
>
> Caused by commit
>
>   717197608952 ("libnvdimm: Add device-tree based driver")
>
> X86 seems to not have a version of of_node_to_nid() even though CONFIG_OF
> and CONFIG_NUMA are both 'y' in this build.

It's a side effect of a driver selecting CONFIG_OF accidently. There's
a patch to fix this in the drm-misc-next tree:

https://lkml.org/lkml/2018/4/3/17

> I have used the nvdimm tree from next-20180406 for today.

That works too.

Oliver

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

[Oliver]

On Mon, Apr 9, 2018 at 1:16 PM, Stephen Rothwell  wrote:
> Hi Dan,
>
> After merging the nvdimm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "of_node_to_nid" [drivers/nvdimm/of_pmem.ko] undefined!
>
> Caused by commit
>
>   717197608952 ("libnvdimm: Add device-tree based driver")
>
> X86 seems to not have a version of of_node_to_nid() even though CONFIG_OF
> and CONFIG_NUMA are both 'y' in this build.

It's a side effect of a driver selecting CONFIG_OF accidently. There's
a patch to fix this in the drm-misc-next tree:

https://lkml.org/lkml/2018/4/3/17

> I have used the nvdimm tree from next-20180406 for today.

That works too.

Oliver

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

[Dan Williams]

On Fri, Nov 3, 2017 at 12:19 AM, Stephen Rothwell  wrote:
> Hi Dan,
>
> After merging the nvdimm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from arch/powerpc/kernel/asm-offsets.c:22:0:
> include/linux/mman.h: In function 'calc_vm_flag_bits':
> include/linux/mman.h:109:48: warning: division by zero [-Wdiv-by-zero]
>((bit1) <= (bit2) ? ((x) & (bit1)) * ((bit2) / (bit1)) \
> ^
> include/linux/mman.h:133:9: note: in expansion of macro '_calc_vm_trans'
>  _calc_vm_trans(flags, MAP_SYNC,  VM_SYNC  );
>  ^
> cc1: all warnings being treated as errors
>
> and more like these ...
>
> Caused by commit
>
>   ebd0722a382c ("mm: Define MAP_SYNC and VM_SYNC flags")
>
> Not all architectures use asm-generic/mman.h
>
> I have used the nvdimm tree from next-20171102 for today.

Thanks, Stephen. I included Jan's fix for this issue in today's
version of the libnvdimm-for-next branch.

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

[Dan Williams]

On Fri, Nov 3, 2017 at 12:19 AM, Stephen Rothwell  wrote:
> Hi Dan,
>
> After merging the nvdimm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from arch/powerpc/kernel/asm-offsets.c:22:0:
> include/linux/mman.h: In function 'calc_vm_flag_bits':
> include/linux/mman.h:109:48: warning: division by zero [-Wdiv-by-zero]
>((bit1) <= (bit2) ? ((x) & (bit1)) * ((bit2) / (bit1)) \
> ^
> include/linux/mman.h:133:9: note: in expansion of macro '_calc_vm_trans'
>  _calc_vm_trans(flags, MAP_SYNC,  VM_SYNC  );
>  ^
> cc1: all warnings being treated as errors
>
> and more like these ...
>
> Caused by commit
>
>   ebd0722a382c ("mm: Define MAP_SYNC and VM_SYNC flags")
>
> Not all architectures use asm-generic/mman.h
>
> I have used the nvdimm tree from next-20171102 for today.

Thanks, Stephen. I included Jan's fix for this issue in today's
version of the libnvdimm-for-next branch.

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

[Dan Williams]

On Mon, Sep 4, 2017 at 12:34 AM, Stephen Rothwell  wrote:
> Hi Dan,
>
> After merging the nvdimm tree, today's linux-next build (i386 defconfig)
> failed like this:
>
> drivers/dax/super.c:64:20: error: redefinition of 'fs_dax_get_by_bdev'
>  struct dax_device *fs_dax_get_by_bdev(struct block_device *bdev)
> ^
> In file included from drivers/dax/super.c:22:0:
> include/linux/dax.h:76:34: note: previous definition of 'fs_dax_get_by_bdev' 
> was here
>  static inline struct dax_device *fs_dax_get_by_bdev(struct block_device 
> *bdev)
>   ^
>
> Caused by commit
>
>   78f354735081 ("dax: introduce a fs_dax_get_by_bdev() helper")
>
> The protection in drivers/dax/super.c is CONFIG_BLOCK, while in
> include/linux/dax.h it is IS_ENABLED(CONFIG_FS_DAX) and the Makefile
> uses CONFIG_DAX.
>
> I have reverted that commit and the following 3 for today.

Thanks Stephen, I have appended a fix to that branch.

https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/commit/?h=libnvdimm-for-next=26f2f4de0bd93

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

[Dan Williams]

On Mon, Sep 4, 2017 at 12:34 AM, Stephen Rothwell  wrote:
> Hi Dan,
>
> After merging the nvdimm tree, today's linux-next build (i386 defconfig)
> failed like this:
>
> drivers/dax/super.c:64:20: error: redefinition of 'fs_dax_get_by_bdev'
>  struct dax_device *fs_dax_get_by_bdev(struct block_device *bdev)
> ^
> In file included from drivers/dax/super.c:22:0:
> include/linux/dax.h:76:34: note: previous definition of 'fs_dax_get_by_bdev' 
> was here
>  static inline struct dax_device *fs_dax_get_by_bdev(struct block_device 
> *bdev)
>   ^
>
> Caused by commit
>
>   78f354735081 ("dax: introduce a fs_dax_get_by_bdev() helper")
>
> The protection in drivers/dax/super.c is CONFIG_BLOCK, while in
> include/linux/dax.h it is IS_ENABLED(CONFIG_FS_DAX) and the Makefile
> uses CONFIG_DAX.
>
> I have reverted that commit and the following 3 for today.

Thanks Stephen, I have appended a fix to that branch.

https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/commit/?h=libnvdimm-for-next=26f2f4de0bd93

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

[Dan Williams]

On Mon, Apr 24, 2017 at 1:39 AM, Al Viro  wrote:
> On Mon, Apr 24, 2017 at 04:11:30PM +1000, Stephen Rothwell wrote:
>> Hi Dan,
>>
>> After merging the nvdimm tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/nvdimm/x86.c: In function 'pmem_from_user':
>> drivers/nvdimm/x86.c:115:11: error: implicit declaration of function 
>> '__copy_from_user_nocache' [-Werror=implicit-function-declaration]
>>   int rc = __copy_from_user_nocache(dst, src, size);
>>^
>>
>> Caused by commit
>>
>>   6e704ff67315 ("uio, libnvdimm, pmem: implement cache bypass for all 
>> copy_from_iter() operations")
>>
>> interacting with commit
>>
>>   3f763453e6f2 ("kill __copy_from_user_nocache()")
>>
>> from the vfs tree.
>>
>> I have no idea why Al removed that function,
>
> Because the entire nocache pile is messy and misguided and the fewer of
> those we have, the easier it will be to untangle the damn thing.  This
> particular turdlet had no users in mainline.  Unfortunately, it has
> grown one in nvdimm, so we'll probably have to drop that removal for now
> and hope that it won't be too painful to untangle come next cycle.
>
> Oh, well...  Guess we'll need to resurrect memcpy_nocache() threads from
> December and deal witht that mess for good.

Al, I've kicked this new usage of __copy_from_user_nocache out of
-next and I'll rebase my pmem vs uaccess work on vfs.git/for-next.

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

[Dan Williams]

On Mon, Apr 24, 2017 at 1:39 AM, Al Viro  wrote:
> On Mon, Apr 24, 2017 at 04:11:30PM +1000, Stephen Rothwell wrote:
>> Hi Dan,
>>
>> After merging the nvdimm tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/nvdimm/x86.c: In function 'pmem_from_user':
>> drivers/nvdimm/x86.c:115:11: error: implicit declaration of function 
>> '__copy_from_user_nocache' [-Werror=implicit-function-declaration]
>>   int rc = __copy_from_user_nocache(dst, src, size);
>>^
>>
>> Caused by commit
>>
>>   6e704ff67315 ("uio, libnvdimm, pmem: implement cache bypass for all 
>> copy_from_iter() operations")
>>
>> interacting with commit
>>
>>   3f763453e6f2 ("kill __copy_from_user_nocache()")
>>
>> from the vfs tree.
>>
>> I have no idea why Al removed that function,
>
> Because the entire nocache pile is messy and misguided and the fewer of
> those we have, the easier it will be to untangle the damn thing.  This
> particular turdlet had no users in mainline.  Unfortunately, it has
> grown one in nvdimm, so we'll probably have to drop that removal for now
> and hope that it won't be too painful to untangle come next cycle.
>
> Oh, well...  Guess we'll need to resurrect memcpy_nocache() threads from
> December and deal witht that mess for good.

Al, I've kicked this new usage of __copy_from_user_nocache out of
-next and I'll rebase my pmem vs uaccess work on vfs.git/for-next.

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

[Dan Williams]

On Mon, Apr 24, 2017 at 1:39 AM, Al Viro  wrote:
> On Mon, Apr 24, 2017 at 04:11:30PM +1000, Stephen Rothwell wrote:
>> Hi Dan,
>>
>> After merging the nvdimm tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/nvdimm/x86.c: In function 'pmem_from_user':
>> drivers/nvdimm/x86.c:115:11: error: implicit declaration of function 
>> '__copy_from_user_nocache' [-Werror=implicit-function-declaration]
>>   int rc = __copy_from_user_nocache(dst, src, size);
>>^
>>
>> Caused by commit
>>
>>   6e704ff67315 ("uio, libnvdimm, pmem: implement cache bypass for all 
>> copy_from_iter() operations")
>>
>> interacting with commit
>>
>>   3f763453e6f2 ("kill __copy_from_user_nocache()")
>>
>> from the vfs tree.
>>
>> I have no idea why Al removed that function,
>
> Because the entire nocache pile is messy and misguided and the fewer of
> those we have, the easier it will be to untangle the damn thing.  This
> particular turdlet had no users in mainline.  Unfortunately, it has
> grown one in nvdimm, so we'll probably have to drop that removal for now
> and hope that it won't be too painful to untangle come next cycle.
>
> Oh, well...  Guess we'll need to resurrect memcpy_nocache() threads from
> December and deal witht that mess for good.

Hi Al, this conflict is hitting my attempt to "deal with that mess for good".

Can you give me your take on the sanity of the patches I cc'd you on
in the thread called "[resend PATCH v2 00/33] dax: introduce
dax_operations"

Here are some links:
[resend PATCH v2 00/33] dax: introduce dax_operations:
https://lists.01.org/pipermail/linux-nvdimm/2017-April/009711.html
[resend PATCH v2 19/33] dax, pmem: introduce 'copy_from_iter' dax
operation: https://lists.01.org/pipermail/linux-nvdimm/2017-April/009730.html
[resend PATCH v2 28/33] x86, libnvdimm, dax: stop abusing
__copy_user_nocache:
https://lists.01.org/pipermail/linux-nvdimm/2017-April/009738.html
[resend PATCH v2 29/33] uio, libnvdimm, pmem: implement cache bypass
for all copy_from_iter() operations:
https://lists.01.org/pipermail/linux-nvdimm/2017-April/009739.html

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

[Dan Williams]

On Mon, Apr 24, 2017 at 1:39 AM, Al Viro  wrote:
> On Mon, Apr 24, 2017 at 04:11:30PM +1000, Stephen Rothwell wrote:
>> Hi Dan,
>>
>> After merging the nvdimm tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/nvdimm/x86.c: In function 'pmem_from_user':
>> drivers/nvdimm/x86.c:115:11: error: implicit declaration of function 
>> '__copy_from_user_nocache' [-Werror=implicit-function-declaration]
>>   int rc = __copy_from_user_nocache(dst, src, size);
>>^
>>
>> Caused by commit
>>
>>   6e704ff67315 ("uio, libnvdimm, pmem: implement cache bypass for all 
>> copy_from_iter() operations")
>>
>> interacting with commit
>>
>>   3f763453e6f2 ("kill __copy_from_user_nocache()")
>>
>> from the vfs tree.
>>
>> I have no idea why Al removed that function,
>
> Because the entire nocache pile is messy and misguided and the fewer of
> those we have, the easier it will be to untangle the damn thing.  This
> particular turdlet had no users in mainline.  Unfortunately, it has
> grown one in nvdimm, so we'll probably have to drop that removal for now
> and hope that it won't be too painful to untangle come next cycle.
>
> Oh, well...  Guess we'll need to resurrect memcpy_nocache() threads from
> December and deal witht that mess for good.

Hi Al, this conflict is hitting my attempt to "deal with that mess for good".

Can you give me your take on the sanity of the patches I cc'd you on
in the thread called "[resend PATCH v2 00/33] dax: introduce
dax_operations"

Here are some links:
[resend PATCH v2 00/33] dax: introduce dax_operations:
https://lists.01.org/pipermail/linux-nvdimm/2017-April/009711.html
[resend PATCH v2 19/33] dax, pmem: introduce 'copy_from_iter' dax
operation: https://lists.01.org/pipermail/linux-nvdimm/2017-April/009730.html
[resend PATCH v2 28/33] x86, libnvdimm, dax: stop abusing
__copy_user_nocache:
https://lists.01.org/pipermail/linux-nvdimm/2017-April/009738.html
[resend PATCH v2 29/33] uio, libnvdimm, pmem: implement cache bypass
for all copy_from_iter() operations:
https://lists.01.org/pipermail/linux-nvdimm/2017-April/009739.html

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

[Al Viro]

On Mon, Apr 24, 2017 at 04:11:30PM +1000, Stephen Rothwell wrote:
> Hi Dan,
> 
> After merging the nvdimm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/nvdimm/x86.c: In function 'pmem_from_user':
> drivers/nvdimm/x86.c:115:11: error: implicit declaration of function 
> '__copy_from_user_nocache' [-Werror=implicit-function-declaration]
>   int rc = __copy_from_user_nocache(dst, src, size);
>^
> 
> Caused by commit
> 
>   6e704ff67315 ("uio, libnvdimm, pmem: implement cache bypass for all 
> copy_from_iter() operations")
> 
> interacting with commit
> 
>   3f763453e6f2 ("kill __copy_from_user_nocache()")
> 
> from the vfs tree.
> 
> I have no idea why Al removed that function,

Because the entire nocache pile is messy and misguided and the fewer of
those we have, the easier it will be to untangle the damn thing.  This
particular turdlet had no users in mainline.  Unfortunately, it has
grown one in nvdimm, so we'll probably have to drop that removal for now
and hope that it won't be too painful to untangle come next cycle.

Oh, well...  Guess we'll need to resurrect memcpy_nocache() threads from
December and deal witht that mess for good.

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

[Al Viro]

On Mon, Apr 24, 2017 at 04:11:30PM +1000, Stephen Rothwell wrote:
> Hi Dan,
> 
> After merging the nvdimm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/nvdimm/x86.c: In function 'pmem_from_user':
> drivers/nvdimm/x86.c:115:11: error: implicit declaration of function 
> '__copy_from_user_nocache' [-Werror=implicit-function-declaration]
>   int rc = __copy_from_user_nocache(dst, src, size);
>^
> 
> Caused by commit
> 
>   6e704ff67315 ("uio, libnvdimm, pmem: implement cache bypass for all 
> copy_from_iter() operations")
> 
> interacting with commit
> 
>   3f763453e6f2 ("kill __copy_from_user_nocache()")
> 
> from the vfs tree.
> 
> I have no idea why Al removed that function,

Because the entire nocache pile is messy and misguided and the fewer of
those we have, the easier it will be to untangle the damn thing.  This
particular turdlet had no users in mainline.  Unfortunately, it has
grown one in nvdimm, so we'll probably have to drop that removal for now
and hope that it won't be too painful to untangle come next cycle.

Oh, well...  Guess we'll need to resurrect memcpy_nocache() threads from
December and deal witht that mess for good.

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

[Dan Williams]

On Fri, Jul 22, 2016 at 6:04 PM, Dan Williams  wrote:
> On Thu, Jul 21, 2016 at 11:13 PM, Stephen Rothwell  
> wrote:
>> Hi Dan,
>>
>> After merging the nvdimm tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> In file included from drivers/md/dm.h:14:0,
>>  from drivers/md/dm-uevent.c:27:
>> include/linux/device-mapper.h:134:22: error: expected ';', ',' or ')' before 
>> '*' token
>>   void __pmem **kaddr, pfn_t *pfn, long size);
>>   ^
>> include/linux/device-mapper.h:182:2: error: unknown type name 
>> 'dm_direct_access_fn'
>>   dm_direct_access_fn direct_access;
>>   ^
>>
>> Caused by commit
>>
>>   7a9eb2066631 ("pmem: kill __pmem address space")
>>
>> interacting with commit
>>
>>   545ed20e6df6 ("dm: add infrastructure for DAX support")
>>
>> from the device-mapper tree.
>>
>> I applied the following merge fix patch for today.  Someone needs to
>> tell Linus about this when he merges the trees.
>
> There's no real rush to remove "__pmem" I'll pull this out until after
> DM DAX support has merged.
>
> Thanks Stephen!

Sorry, I forgot that some ARM patches already depend on this change...
so we'll need to roll forward and notify Linus about this merge
interaction.

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

[Dan Williams]

On Fri, Jul 22, 2016 at 6:04 PM, Dan Williams  wrote:
> On Thu, Jul 21, 2016 at 11:13 PM, Stephen Rothwell  
> wrote:
>> Hi Dan,
>>
>> After merging the nvdimm tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> In file included from drivers/md/dm.h:14:0,
>>  from drivers/md/dm-uevent.c:27:
>> include/linux/device-mapper.h:134:22: error: expected ';', ',' or ')' before 
>> '*' token
>>   void __pmem **kaddr, pfn_t *pfn, long size);
>>   ^
>> include/linux/device-mapper.h:182:2: error: unknown type name 
>> 'dm_direct_access_fn'
>>   dm_direct_access_fn direct_access;
>>   ^
>>
>> Caused by commit
>>
>>   7a9eb2066631 ("pmem: kill __pmem address space")
>>
>> interacting with commit
>>
>>   545ed20e6df6 ("dm: add infrastructure for DAX support")
>>
>> from the device-mapper tree.
>>
>> I applied the following merge fix patch for today.  Someone needs to
>> tell Linus about this when he merges the trees.
>
> There's no real rush to remove "__pmem" I'll pull this out until after
> DM DAX support has merged.
>
> Thanks Stephen!

Sorry, I forgot that some ARM patches already depend on this change...
so we'll need to roll forward and notify Linus about this merge
interaction.

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

[Dan Williams]

On Thu, Jul 21, 2016 at 11:13 PM, Stephen Rothwell  
wrote:
> Hi Dan,
>
> After merging the nvdimm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from drivers/md/dm.h:14:0,
>  from drivers/md/dm-uevent.c:27:
> include/linux/device-mapper.h:134:22: error: expected ';', ',' or ')' before 
> '*' token
>   void __pmem **kaddr, pfn_t *pfn, long size);
>   ^
> include/linux/device-mapper.h:182:2: error: unknown type name 
> 'dm_direct_access_fn'
>   dm_direct_access_fn direct_access;
>   ^
>
> Caused by commit
>
>   7a9eb2066631 ("pmem: kill __pmem address space")
>
> interacting with commit
>
>   545ed20e6df6 ("dm: add infrastructure for DAX support")
>
> from the device-mapper tree.
>
> I applied the following merge fix patch for today.  Someone needs to
> tell Linus about this when he merges the trees.

There's no real rush to remove "__pmem" I'll pull this out until after
DM DAX support has merged.

Thanks Stephen!

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

[Dan Williams]

On Thu, Jul 21, 2016 at 11:13 PM, Stephen Rothwell  
wrote:
> Hi Dan,
>
> After merging the nvdimm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from drivers/md/dm.h:14:0,
>  from drivers/md/dm-uevent.c:27:
> include/linux/device-mapper.h:134:22: error: expected ';', ',' or ')' before 
> '*' token
>   void __pmem **kaddr, pfn_t *pfn, long size);
>   ^
> include/linux/device-mapper.h:182:2: error: unknown type name 
> 'dm_direct_access_fn'
>   dm_direct_access_fn direct_access;
>   ^
>
> Caused by commit
>
>   7a9eb2066631 ("pmem: kill __pmem address space")
>
> interacting with commit
>
>   545ed20e6df6 ("dm: add infrastructure for DAX support")
>
> from the device-mapper tree.
>
> I applied the following merge fix patch for today.  Someone needs to
> tell Linus about this when he merges the trees.

There's no real rush to remove "__pmem" I'll pull this out until after
DM DAX support has merged.

Thanks Stephen!

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

[Dan Williams]

On Wed, Jul 20, 2016 at 11:13 PM, Stephen Rothwell  
wrote:
> Hi Dan,
>
> After merging the nvdimm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/sysdev/axonram.c: In function 'axon_ram_direct_access':
> arch/powerpc/sysdev/axonram.c:151:9: error: assignment makes pointer from 
> integer without a cast [-Werror=int-conversion]
>   *kaddr = bank->io_addr + offset;
>  ^
>
> Caused by commit
>
>   6e9c9dda79d9 ("pmem: kill __pmem address space")
>
> I have used the nvdimm tree from next-20160720 for today.

Sorry about that.  I had received a positive build notification from
the kbuild robot for ppc64_defconfig, but it seems that was a false
positive.

I've fixed it up and refreshed the branch.

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

[Dan Williams]

On Wed, Jul 20, 2016 at 11:13 PM, Stephen Rothwell  
wrote:
> Hi Dan,
>
> After merging the nvdimm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/sysdev/axonram.c: In function 'axon_ram_direct_access':
> arch/powerpc/sysdev/axonram.c:151:9: error: assignment makes pointer from 
> integer without a cast [-Werror=int-conversion]
>   *kaddr = bank->io_addr + offset;
>  ^
>
> Caused by commit
>
>   6e9c9dda79d9 ("pmem: kill __pmem address space")
>
> I have used the nvdimm tree from next-20160720 for today.

Sorry about that.  I had received a positive build notification from
the kbuild robot for ppc64_defconfig, but it seems that was a false
positive.

I've fixed it up and refreshed the branch.