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

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell


pgpyApny4Uudd.pgp
Description: OpenPGP digital signature

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
> 

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

[Stephen Rothwell]

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.

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


pgpeFUJUvJQdE.pgp
Description: OpenPGP digital signature

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

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

[Stephen Rothwell]

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.

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

-- 
Cheers,
Stephen Rothwell


pgp2QOrv3z57Z.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

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.

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

-- 
Cheers,
Stephen Rothwell


pgp2QOrv3z57Z.pgp
Description: OpenPGP digital signature

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.

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell

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.

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

[Stephen Rothwell]

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, so I just applied the
following fix patch for now:

From: Stephen Rothwell 
Date: Mon, 24 Apr 2017 16:03:09 +1000
Subject: [PATCH] uio, libnvdimm, pmem: implement cache bypass for all
 copy_from_iter() operations fix

Signed-off-by: Stephen Rothwell 
---
 drivers/nvdimm/x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvdimm/x86.c b/drivers/nvdimm/x86.c
index bc145d760d43..4c15cc103713 100644
--- a/drivers/nvdimm/x86.c
+++ b/drivers/nvdimm/x86.c
@@ -112,7 +112,7 @@ EXPORT_SYMBOL_GPL(arch_memcpy_to_pmem);
 static int pmem_from_user(void *dst, const void __user *src, unsigned size)
 {
unsigned long flushed, dest = (unsigned long) dest;
-   int rc = __copy_from_user_nocache(dst, src, size);
+   int rc = __copy_from_user(dst, src, size);
 
/*
 * On x86_64 __copy_from_user_nocache() uses non-temporal stores
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

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, so I just applied the
following fix patch for now:

From: Stephen Rothwell 
Date: Mon, 24 Apr 2017 16:03:09 +1000
Subject: [PATCH] uio, libnvdimm, pmem: implement cache bypass for all
 copy_from_iter() operations fix

Signed-off-by: Stephen Rothwell 
---
 drivers/nvdimm/x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvdimm/x86.c b/drivers/nvdimm/x86.c
index bc145d760d43..4c15cc103713 100644
--- a/drivers/nvdimm/x86.c
+++ b/drivers/nvdimm/x86.c
@@ -112,7 +112,7 @@ EXPORT_SYMBOL_GPL(arch_memcpy_to_pmem);
 static int pmem_from_user(void *dst, const void __user *src, unsigned size)
 {
unsigned long flushed, dest = (unsigned long) dest;
-   int rc = __copy_from_user_nocache(dst, src, size);
+   int rc = __copy_from_user(dst, src, size);
 
/*
 * On x86_64 __copy_from_user_nocache() uses non-temporal stores
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

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!

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

[Stephen Rothwell]

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.

From: Stephen Rothwell 
Date: Fri, 22 Jul 2016 16:01:02 +1000
Subject: [PATCH] dm: merge fix for "pmem: kill __pmem address space"

Signed-off-by: Stephen Rothwell 
---
 drivers/md/dm-linear.c| 2 +-
 drivers/md/dm-snap.c  | 2 +-
 drivers/md/dm-stripe.c| 2 +-
 drivers/md/dm-target.c| 2 +-
 drivers/md/dm.c   | 2 +-
 include/linux/device-mapper.h | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c
index 6d35dd4e9efb..4788b0b989a9 100644
--- a/drivers/md/dm-linear.c
+++ b/drivers/md/dm-linear.c
@@ -142,7 +142,7 @@ static int linear_iterate_devices(struct dm_target *ti,
 }
 
 static long linear_direct_access(struct dm_target *ti, sector_t sector,
-void __pmem **kaddr, pfn_t *pfn, long size)
+void **kaddr, pfn_t *pfn, long size)
 {
struct linear_c *lc = ti->private;
struct block_device *bdev = lc->dev->bdev;
diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index 731e1f5bd895..ce2a910709f7 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -2303,7 +2303,7 @@ static int origin_map(struct dm_target *ti, struct bio 
*bio)
 }
 
 static long origin_direct_access(struct dm_target *ti, sector_t sector,
-   void __pmem **kaddr, pfn_t *pfn, long size)
+   void **kaddr, pfn_t *pfn, long size)
 {
DMWARN("device does not support dax.");
return -EIO;
diff --git a/drivers/md/dm-stripe.c b/drivers/md/dm-stripe.c
index 01bb9cf2a8c2..83f1d4667195 100644
--- a/drivers/md/dm-stripe.c
+++ b/drivers/md/dm-stripe.c
@@ -309,7 +309,7 @@ static int stripe_map(struct dm_target *ti, struct bio *bio)
 }
 
 static long stripe_direct_access(struct dm_target *ti, sector_t sector,
-void __pmem **kaddr, pfn_t *pfn, long size)
+void **kaddr, pfn_t *pfn, long size)
 {
struct stripe_c *sc = ti->private;
uint32_t stripe;
diff --git a/drivers/md/dm-target.c b/drivers/md/dm-target.c
index 6eecd6b36f76..710ae28fd618 100644
--- a/drivers/md/dm-target.c
+++ b/drivers/md/dm-target.c
@@ -149,7 +149,7 @@ static void io_err_release_clone_rq(struct request *clone)
 }
 
 static long io_err_direct_access(struct dm_target *ti, sector_t sector,
-void __pmem **kaddr, pfn_t *pfn, long size)
+void **kaddr, pfn_t *pfn, long size)
 {
return -EIO;
 }
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index ceb69fc0b10b..25d1d97154a8 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -906,7 +906,7 @@ int dm_set_target_max_io_len(struct dm_target *ti, sector_t 
len)
 EXPORT_SYMBOL_GPL(dm_set_target_max_io_len);
 
 static long dm_blk_direct_access(struct block_device *bdev, sector_t sector,
-void __pmem **kaddr, pfn_t *pfn, long size)
+void **kaddr, pfn_t *pfn, long size)
 {
struct mapped_device *md = bdev->bd_disk->private_data;
struct dm_table *map;
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index b0db857f334b..91acfce74a22 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -131,7 +131,7 @@ typedef int (*dm_busy_fn) (struct dm_target *ti);
  * >= 0 : the number of bytes accessible at the address
  */
 typedef long (*dm_direct_access_fn) (struct dm_target *ti, sector_t sector,
-void __pmem **kaddr, pfn_t *pfn, long 
size);
+void **kaddr, pfn_t *pfn, long size);
 
 void dm_error(const char *message);
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

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.

From: Stephen Rothwell 
Date: Fri, 22 Jul 2016 16:01:02 +1000
Subject: [PATCH] dm: merge fix for "pmem: kill __pmem address space"

Signed-off-by: Stephen Rothwell 
---
 drivers/md/dm-linear.c| 2 +-
 drivers/md/dm-snap.c  | 2 +-
 drivers/md/dm-stripe.c| 2 +-
 drivers/md/dm-target.c| 2 +-
 drivers/md/dm.c   | 2 +-
 include/linux/device-mapper.h | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c
index 6d35dd4e9efb..4788b0b989a9 100644
--- a/drivers/md/dm-linear.c
+++ b/drivers/md/dm-linear.c
@@ -142,7 +142,7 @@ static int linear_iterate_devices(struct dm_target *ti,
 }
 
 static long linear_direct_access(struct dm_target *ti, sector_t sector,
-void __pmem **kaddr, pfn_t *pfn, long size)
+void **kaddr, pfn_t *pfn, long size)
 {
struct linear_c *lc = ti->private;
struct block_device *bdev = lc->dev->bdev;
diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index 731e1f5bd895..ce2a910709f7 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -2303,7 +2303,7 @@ static int origin_map(struct dm_target *ti, struct bio 
*bio)
 }
 
 static long origin_direct_access(struct dm_target *ti, sector_t sector,
-   void __pmem **kaddr, pfn_t *pfn, long size)
+   void **kaddr, pfn_t *pfn, long size)
 {
DMWARN("device does not support dax.");
return -EIO;
diff --git a/drivers/md/dm-stripe.c b/drivers/md/dm-stripe.c
index 01bb9cf2a8c2..83f1d4667195 100644
--- a/drivers/md/dm-stripe.c
+++ b/drivers/md/dm-stripe.c
@@ -309,7 +309,7 @@ static int stripe_map(struct dm_target *ti, struct bio *bio)
 }
 
 static long stripe_direct_access(struct dm_target *ti, sector_t sector,
-void __pmem **kaddr, pfn_t *pfn, long size)
+void **kaddr, pfn_t *pfn, long size)
 {
struct stripe_c *sc = ti->private;
uint32_t stripe;
diff --git a/drivers/md/dm-target.c b/drivers/md/dm-target.c
index 6eecd6b36f76..710ae28fd618 100644
--- a/drivers/md/dm-target.c
+++ b/drivers/md/dm-target.c
@@ -149,7 +149,7 @@ static void io_err_release_clone_rq(struct request *clone)
 }
 
 static long io_err_direct_access(struct dm_target *ti, sector_t sector,
-void __pmem **kaddr, pfn_t *pfn, long size)
+void **kaddr, pfn_t *pfn, long size)
 {
return -EIO;
 }
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index ceb69fc0b10b..25d1d97154a8 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -906,7 +906,7 @@ int dm_set_target_max_io_len(struct dm_target *ti, sector_t 
len)
 EXPORT_SYMBOL_GPL(dm_set_target_max_io_len);
 
 static long dm_blk_direct_access(struct block_device *bdev, sector_t sector,
-void __pmem **kaddr, pfn_t *pfn, long size)
+void **kaddr, pfn_t *pfn, long size)
 {
struct mapped_device *md = bdev->bd_disk->private_data;
struct dm_table *map;
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index b0db857f334b..91acfce74a22 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -131,7 +131,7 @@ typedef int (*dm_busy_fn) (struct dm_target *ti);
  * >= 0 : the number of bytes accessible at the address
  */
 typedef long (*dm_direct_access_fn) (struct dm_target *ti, sector_t sector,
-void __pmem **kaddr, pfn_t *pfn, long 
size);
+void **kaddr, pfn_t *pfn, long size);
 
 void dm_error(const char *message);
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

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.

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Dan,

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

In file included from /home/sfr/next/next/fs/dax.c:28:0:
include/linux/pmem.h: In function 'memcpy_from_pmem':
include/linux/pmem.h:79:9: error: implicit declaration of function 
'arch_memcpy_from_pmem' [-Werror=implicit-function-declaration]
  return arch_memcpy_from_pmem(dst, src, size);
 ^

Caused by commit

  a2b056ea291d ("x86, pmem: use memcpy_mcsafe() for memcpy_from_pmem()")

I used the nvdimm tree from next-20160324 for today.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Dan,

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

In file included from /home/sfr/next/next/fs/dax.c:28:0:
include/linux/pmem.h: In function 'memcpy_from_pmem':
include/linux/pmem.h:79:9: error: implicit declaration of function 
'arch_memcpy_from_pmem' [-Werror=implicit-function-declaration]
  return arch_memcpy_from_pmem(dst, src, size);
 ^

Caused by commit

  a2b056ea291d ("x86, pmem: use memcpy_mcsafe() for memcpy_from_pmem()")

I used the nvdimm tree from next-20160324 for today.

-- 
Cheers,
Stephen Rothwell