人工成本不断上升而生产能未能最大化

2017-11-15 Thread 傅�O会 

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [v6,2/8] dmaengine: Add DMA_MEMCPY_SG transaction op

2017-11-15 Thread Vinod Koul 
On Mon, Nov 13, 2017 at 09:28:46AM +0100, Stefan Roese wrote:
> Hi Vinod,
> 
> On 31.08.2017 12:57, Robin Murphy wrote:
> >On 30/08/17 19:25, Dave Jiang wrote:
> >>On 08/30/2017 11:18 AM, Robin Murphy wrote:
> >>>On 25/08/17 21:59, Dave Jiang wrote:
> Adding a dmaengine transaction operation that allows copy to/from a
> scatterlist and a flat buffer.
> >>>
> >>>Apologies if I'm late to the party, but doesn't DMA_SG already cover
> >>>this use-case? As far as I can see, all this does is save the caller
> >>>from setting up a single-entry scatterlist to describe the buffer - even
> >>>if such a simplified interface is justified it seems like something that
> >>>could be implemented as a wrapper around dmaengine_prep_dma_sg() rather
> >>>than the providers having to implement a whole extra callback.
> >>>
> >>
> >>DMA_SG is queued to be removed in 4.14. There is no in kernel consumer
> >>for the code.
> >
> >Ah, I see, that's what I was missing. So we're effectively just
> >replacing that interface with a more pragmatic alternative - that makes
> >sense.
> 
> What are the plans with this new DMA_MEMCPY_SG interface? When will it
> hit mainline or is something missing?

The old one was removed in 4.14 so if you have a usage feel free to send a
patch to add this with usage.

Thanks
-- 
~Vinod
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [v6,2/8] dmaengine: Add DMA_MEMCPY_SG transaction op

2017-11-15 Thread Stefan Roese 

Hi Vinod,

On 15.11.2017 16:52, Vinod Koul wrote:

On Mon, Nov 13, 2017 at 09:28:46AM +0100, Stefan Roese wrote:

Hi Vinod,

On 31.08.2017 12:57, Robin Murphy wrote:

On 30/08/17 19:25, Dave Jiang wrote:

On 08/30/2017 11:18 AM, Robin Murphy wrote:

On 25/08/17 21:59, Dave Jiang wrote:

Adding a dmaengine transaction operation that allows copy to/from a
scatterlist and a flat buffer.


Apologies if I'm late to the party, but doesn't DMA_SG already cover
this use-case? As far as I can see, all this does is save the caller

>from setting up a single-entry scatterlist to describe the buffer - even

if such a simplified interface is justified it seems like something that
could be implemented as a wrapper around dmaengine_prep_dma_sg() rather
than the providers having to implement a whole extra callback.



DMA_SG is queued to be removed in 4.14. There is no in kernel consumer
for the code.


Ah, I see, that's what I was missing. So we're effectively just
replacing that interface with a more pragmatic alternative - that makes
sense.


What are the plans with this new DMA_MEMCPY_SG interface? When will it
hit mainline or is something missing?


The old one was removed in 4.14 so if you have a usage feel free to send a
patch to add this with usage.


No, its not the "old one" (DMA_SG) but the "new one" (DMA_MEMCPY_SG)
I'm referring to (this email thread). My impression was, that this
new interface has (or will get) in-kernel users and will be pulled at
some time.

Thanks,
Stefan
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [v6,2/8] dmaengine: Add DMA_MEMCPY_SG transaction op

2017-11-15 Thread Dave Jiang 


On 11/15/2017 09:13 AM, Stefan Roese wrote:
> Hi Vinod,
> 
> On 15.11.2017 16:52, Vinod Koul wrote:
>> On Mon, Nov 13, 2017 at 09:28:46AM +0100, Stefan Roese wrote:
>>> Hi Vinod,
>>>
>>> On 31.08.2017 12:57, Robin Murphy wrote:
 On 30/08/17 19:25, Dave Jiang wrote:
> On 08/30/2017 11:18 AM, Robin Murphy wrote:
>> On 25/08/17 21:59, Dave Jiang wrote:
>>> Adding a dmaengine transaction operation that allows copy to/from a
>>> scatterlist and a flat buffer.
>>
>> Apologies if I'm late to the party, but doesn't DMA_SG already cover
>> this use-case? As far as I can see, all this does is save the caller
> >from setting up a single-entry scatterlist to describe the buffer - even
>> if such a simplified interface is justified it seems like something that
>> could be implemented as a wrapper around dmaengine_prep_dma_sg() rather
>> than the providers having to implement a whole extra callback.
>>
>
> DMA_SG is queued to be removed in 4.14. There is no in kernel consumer
> for the code.

 Ah, I see, that's what I was missing. So we're effectively just
 replacing that interface with a more pragmatic alternative - that makes
 sense.
>>>
>>> What are the plans with this new DMA_MEMCPY_SG interface? When will it
>>> hit mainline or is something missing?
>>
>> The old one was removed in 4.14 so if you have a usage feel free to send a
>> patch to add this with usage.
> 
> No, its not the "old one" (DMA_SG) but the "new one" (DMA_MEMCPY_SG)
> I'm referring to (this email thread). My impression was, that this
> new interface has (or will get) in-kernel users and will be pulled at
> some time.
> 

Decided to hold off on the submission for now. If you need it and have
an upstream consumer for it, feel free to push the change.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[PATCH 1/3] libnvdimm: Add of_node to region and bus descriptors

2017-11-15 Thread Oliver O'Halloran 
We want to be able to cross reference the region and bus devices
with the device tree node that they were spawned from. libNVDIMM
handles creating the actual devices for these internally, so we
need to pass in a pointer to the relevant node in the descriptor.

Signed-off-by: Oliver O'Halloran 
---
 drivers/nvdimm/bus.c | 1 +
 drivers/nvdimm/region_devs.c | 1 +
 include/linux/libnvdimm.h| 3 +++
 3 files changed, 5 insertions(+)

diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index 0a5e6cd758fe..d6f94303ae44 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -358,6 +358,7 @@ struct nvdimm_bus *nvdimm_bus_register(struct device 
*parent,
nvdimm_bus->dev.release = nvdimm_bus_release;
nvdimm_bus->dev.groups = nd_desc->attr_groups;
nvdimm_bus->dev.bus = &nvdimm_bus_type;
+   nvdimm_bus->dev.of_node = nd_desc->of_node;
dev_set_name(&nvdimm_bus->dev, "ndbus%d", nvdimm_bus->id);
rc = device_register(&nvdimm_bus->dev);
if (rc) {
diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
index abaf38c61220..4d756d8c8386 100644
--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -992,6 +992,7 @@ static struct nd_region *nd_region_create(struct nvdimm_bus 
*nvdimm_bus,
dev->parent = &nvdimm_bus->dev;
dev->type = dev_type;
dev->groups = ndr_desc->attr_groups;
+   dev->of_node = ndr_desc->of_node;
nd_region->ndr_size = resource_size(ndr_desc->res);
nd_region->ndr_start = ndr_desc->res->start;
nd_device_register(dev);
diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
index f8109ddb5ef1..fcd9f521e481 100644
--- a/include/linux/libnvdimm.h
+++ b/include/linux/libnvdimm.h
@@ -65,12 +65,14 @@ typedef int (*ndctl_fn)(struct nvdimm_bus_descriptor 
*nd_desc,
struct nvdimm *nvdimm, unsigned int cmd, void *buf,
unsigned int buf_len, int *cmd_rc);
 
+struct device_node;
 struct nvdimm_bus_descriptor {
const struct attribute_group **attr_groups;
unsigned long bus_dsm_mask;
unsigned long cmd_mask;
struct module *module;
char *provider_name;
+   struct device_node *of_node;
ndctl_fn ndctl;
int (*flush_probe)(struct nvdimm_bus_descriptor *nd_desc);
int (*clear_to_send)(struct nvdimm_bus_descriptor *nd_desc,
@@ -112,6 +114,7 @@ struct nd_region_desc {
int num_lanes;
int numa_node;
unsigned long flags;
+   struct device_node *of_node;
 };
 
 struct device;
-- 
2.9.5

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[PATCH 3/3] powerpc/powernv: Create platform devs for nvdimm buses

2017-11-15 Thread Oliver O'Halloran 
Scan the devicetree for an nvdimm-bus compatible and create
a platform device for them.

Signed-off-by: Oliver O'Halloran 
---
 arch/powerpc/platforms/powernv/opal.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 65c79ecf5a4d..32df0d44f086 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -831,6 +831,9 @@ static int __init opal_init(void)
/* Create i2c platform devices */
opal_pdev_init("ibm,opal-i2c");
 
+   /* Handle non-volatile memory devices */
+   opal_pdev_init("nvdimm-bus");
+
/* Setup a heatbeat thread if requested by OPAL */
opal_init_heartbeat();
 
-- 
2.9.5

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[PATCH 2/3] libnvdimm: Add a device-tree interface

2017-11-15 Thread Oliver O'Halloran 
A fairly bare-bones set of device-tree bindings so libnvdimm can be used
on powerpc and other device-tree based platforms.

Cc: devicet...@vger.kernel.org
Signed-off-by: Oliver O'Halloran 
---
 .../devicetree/bindings/nvdimm/nvdimm-bus.txt  |  69 +++
 MAINTAINERS|   8 +
 drivers/nvdimm/Kconfig |  10 +
 drivers/nvdimm/Makefile|   1 +
 drivers/nvdimm/of_nvdimm.c | 202 +
 5 files changed, 290 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvdimm/nvdimm-bus.txt
 create mode 100644 drivers/nvdimm/of_nvdimm.c

diff --git a/Documentation/devicetree/bindings/nvdimm/nvdimm-bus.txt 
b/Documentation/devicetree/bindings/nvdimm/nvdimm-bus.txt
new file mode 100644
index ..491e7c4900ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvdimm/nvdimm-bus.txt
@@ -0,0 +1,69 @@
+Device-tree bindings for nonvolatile-memory / NVDIMMs
+-
+
+Non-volatile DIMMs are memory modules used to provide (cacheable) main memory 
that
+retains its contents across power cycles. In more practical terms, they are 
kind
+of storage device where the contents can be accessed by the CPU directly,
+rather than indirectly via a storage controller or similar. This can provide
+substantial performance improvements for applications designed to take
+advantage of in-memory storage.
+
+This binding provides a way to describe memory regions that should be managed
+by an NVDIMM storage driver (libNVDIMM in Linux) and some of the associated
+metadata. The binding itself is split into two main parts: A container bus and
+its sub-nodes which describe which memory address ranges corresponding to
+NVDIMM backed memory.
+
+Bindings for the container bus:
+--
+
+Required properties:
+ - compatible = "nvdimm-bus";
+ - ranges;
+   A blank ranges property is required because the sub-nodes have
+   addresses in the system's physical address space.
+
+The use of a container bus is mainly to handle future expansion of the 
binding. For
+comparison the ACPI equivalent of this binding (NFIT) describes: Memory 
regions, DIMM
+control structures, Block mode DIMM control structures, interleave sets, and 
more. Some
+of these structures cross reference each other so everyone should be happier 
if we keep
+it relatively self contained.
+
+Bindings for the region nodes:
+-
+
+Required properties:
+   - compatible = "nvdimm-persistent" or "nvdimm-volatile"
+
+   The "nvdimm-persistent" region type indicates that this memory 
region
+   is actually a persistent region. The volatile type is mainly 
useful
+   for testing and RAM disks that can persist across kexec.
+
+   - reg = ;
+   The reg property should only contain one address range.
+
+Optional properties:
+   - Any relevant NUMA assocativity properties for the target platform.
+
+A complete example:
+
+
+/ {
+   #size-cells = <1>;
+   #address-cells = <1>;
+
+   nonvolatile-memory {
+   compatible = "nonvolatile-memory";
+   ranges;
+
+   region@5000 {
+   compatible = "nvdimm-persistent";
+   reg = <0x5000 0x1000>;
+   };
+
+   region@6000 {
+   compatible = "nvdimm-volatile";
+   reg = <0x6000 0x1000>;
+   };
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 65eff7857ec3..0350bf5a94d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7875,6 +7875,14 @@ Q:   
https://patchwork.kernel.org/project/linux-nvdimm/list/
 S: Supported
 F: drivers/nvdimm/pmem*
 
+LIBNVDIMM: DEVICETREE BINDINGS
+M: Oliver O'Halloran 
+L: linux-nvdimm@lists.01.org
+Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
+S: Supported
+F: drivers/nvdimm/of_nvdimm.c
+F: Documentation/devicetree/bindings/nvdimm/nvdimm-bus.txt
+
 LIBNVDIMM: NON-VOLATILE MEMORY DEVICE SUBSYSTEM
 M: Dan Williams 
 L: linux-nvdimm@lists.01.org
diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig
index 5bdd499b5f4f..72d147b55596 100644
--- a/drivers/nvdimm/Kconfig
+++ b/drivers/nvdimm/Kconfig
@@ -102,4 +102,14 @@ config NVDIMM_DAX
 
  Select Y if unsure
 
+config OF_NVDIMM
+   tristate "Device-tree support for NVDIMMs"
+   depends on OF
+   default LIBNVDIMM
+   help
+ Allows byte addressable persistent memory regions to be described in 
the
+ device-tree.
+
+ Select Y if unsure.
+
 endif
diff --git a/drivers/nvdimm/Makefile b/drivers/nvdimm/Makefile
index ca6d325438a3..9029511a8486 100644
--- a/drivers/nvdimm/Makefile
+++ b/drivers/nvdimm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_BLK_DEV_PMEM) += nd_pmem.o
 obj-$(CONFIG_ND_BTT) += n

Re: [PATCH 1/3] libnvdimm: Add of_node to region and bus descriptors

2017-11-15 Thread Dan Williams 
On Wed, Nov 15, 2017 at 9:51 AM, Oliver O'Halloran  wrote:
> We want to be able to cross reference the region and bus devices
> with the device tree node that they were spawned from. libNVDIMM
> handles creating the actual devices for these internally, so we
> need to pass in a pointer to the relevant node in the descriptor.
>
> Signed-off-by: Oliver O'Halloran 

Looks ok to me,

Acked-by: Dan Williams 

...this is late if you were expecting a 4.15 merge.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [patch] dax: fix PMD faults on zero-length files

2017-11-15 Thread Ross Zwisler 
On Tue, Nov 14, 2017 at 05:47:51PM -0800, Dan Williams wrote:
> On Tue, Nov 14, 2017 at 5:37 PM, Jeff Moyer  wrote:
> > PMD faults on a zero length file on a file system mounted with -o dax
> > will not generate SIGBUS as expected.
> >
> > fd = open(...O_TRUNC);
> > addr = mmap(NULL, 2*1024*1024, PROT_READ|PROT_WRITE, MAP_SHARED, 
> > fd, 0);
> > *addr = 'a';
> > 
> >
> > The problem is this code in dax_iomap_pmd_fault:
> >
> > max_pgoff = (i_size_read(inode) - 1) >> PAGE_SHIFT;
> >
> > If the inode size is zero, we end up with a max_pgoff that is way larger
> > than 0.  :)  Fix it by using DIV_ROUND_UP, as is done elsewhere in the
> > kernel.
> >
> > I tested this with some simple test code that ensured that SIGBUS was
> > received where expected.
> >
> 
> I assume this needs:
> 
>Fixes: 642261ac995e ("dax: add struct iomap based DAX PMD support")
>Cc: 
> 
> ...otherwise looks good to me.

Yep, this fix looks good, thanks.  You can add:

Reviewed-by: Ross Zwisler 
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH 1/3] libnvdimm: Add of_node to region and bus descriptors

2017-11-15 Thread Oliver 
On Thu, Nov 16, 2017 at 5:05 AM, Dan Williams  wrote:
> On Wed, Nov 15, 2017 at 9:51 AM, Oliver O'Halloran  wrote:
>> We want to be able to cross reference the region and bus devices
>> with the device tree node that they were spawned from. libNVDIMM
>> handles creating the actual devices for these internally, so we
>> need to pass in a pointer to the relevant node in the descriptor.
>>
>> Signed-off-by: Oliver O'Halloran 
>
> Looks ok to me,
>
> Acked-by: Dan Williams 
>
> ...this is late if you were expecting a 4.15 merge.

I'm not that optimistic, but I wouldn't complain.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[ndctl PATCH 2/4] ndctl, create-namespace: catch attempts to set device-dax for blk namespaces

2017-11-15 Thread Dan Williams 
Similar to the filesytem-dax case blk type namespaces do not support
device-dax operation.

Fixes: 3139dfda1158 ("ndctl: create namespace")
Signed-off-by: Dan Williams 
---
 ndctl/namespace.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ndctl/namespace.c b/ndctl/namespace.c
index 0020be354670..970515570ce9 100644
--- a/ndctl/namespace.c
+++ b/ndctl/namespace.c
@@ -208,8 +208,9 @@ static int set_defaults(enum device_action mode)
 
/* check for incompatible mode and type combinations */
if (param.type && param.mode && strcmp(param.type, "blk") == 0
-   && strcmp(param.mode, "memory") == 0) {
-   error("only 'pmem' namespaces can be placed into 'memory' 
mode\n");
+   && (strcmp(param.mode, "memory") == 0
+   || strcmp(param.mode, "dax") == 0)) {
+   error("only 'pmem' namespaces support dax operation\n");
rc = -ENXIO;
}
 

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[ndctl PATCH 3/4] ndctl, create-namespace: introduce "fsdax" and "devdax" modes

2017-11-15 Thread Dan Williams 
In hindsight "memory" was terrible name for the mode that supports a
'struct page' allocation/reservation to support filesystem-dax
operation. Now that the kernel is moving to disable "page-less" dax we
can just name this mode "fsdax" directly. The "dax" mode name is also
ambiguous so we rename it to "devdax".

The old names are still accepted as options and "ndctl listr" will only use
the new names when the --human option is specified so that scripts that
have learned the original names do not break.

The man page is refreshed to address user questions around what the
modes imply for system operation.

Reported-by: Kelly Couch 
Signed-off-by: Dan Williams 
---
 Documentation/ndctl/ndctl-create-namespace.txt |   98 ++--
 contrib/ndctl  |2 
 ndctl/libndctl.h.in|2 
 ndctl/namespace.c  |8 +-
 util/json.c|   10 ++
 5 files changed, 75 insertions(+), 45 deletions(-)

diff --git a/Documentation/ndctl/ndctl-create-namespace.txt 
b/Documentation/ndctl/ndctl-create-namespace.txt
index 4f1f9849207f..0910edd753ab 100644
--- a/Documentation/ndctl/ndctl-create-namespace.txt
+++ b/Documentation/ndctl/ndctl-create-namespace.txt
@@ -15,7 +15,8 @@ include::namespace-description.txt[]
 EXAMPLES
 
 
-Create a maximally sized pmem namespace in 'memory' mode
+Create a maximally sized pmem namespace in 'fsdax' mode (the
+default)
 [verse]
 ndctl create-namespace
 
@@ -28,24 +29,26 @@ OPTIONS
 -t::
 --type=::
Create a 'pmem' or 'blk' namespace (subject to available
-   capacity).  A pmem namespace supports the DAX (direct access)
+   capacity).  A pmem namespace supports the dax (direct access)
capability to linkndctl:mmap[2] persistent memory directly into
a process address space.  A blk namespace access persistent
memory through a block-window-aperture.  Compared to pmem it
supports a traditional storage error model (EIO on error rather
than a cpu exception on a bad memory access), but it does not
-   support DAX.
+   support dax.
 
 -m::
 --mode=::
-   - "raw": expose the namespace capacity directly with some
- limitations.  Neither a raw pmem namepace nor raw blk namespace
- support sector atomicity by default (see "sector" mode below).  A
- raw pmem namespace may have limited support for passing a DAX
- mapping to other syscalls.  I.e. direct-I/O to/from a DAX buffer
- may fail for a pmem namespace in raw mode.
-
-   - "sector" or "safe": persistent memory, given that it is byte
+   - "raw": expose the namespace capacity directly with
+ limitations.  Neither a raw pmem namepace nor raw blk
+ namespace support sector atomicity by default (see "sector"
+ mode below).  A raw pmem namespace may have limited to no dax
+ support depending the kernel. In other words operations like
+ direct-I/O targeting a dax buffer may fail for a pmem
+ namespace in raw mode or indirect through a page-cache buffer.
+ See "fsdax" and "devdax" mode for dax operation.
+
+   - "sector": persistent memory, given that it is byte
  addressable, does not support sector atomicity.  The
  problematic aspect of sector tearing is that most applications
  do not know they have a atomic sector update dependency.  At
@@ -54,27 +57,34 @@ OPTIONS
  Persistent memory devices will always tear and always
  silently.  Until an application is audited to be robust in the
  presence of sector-tearing "safe" mode is recommended.  This
- imposes some performance overhead and disables the DAX
- capability.
-
-   - "memory": A pmem namespace in this mode supports direct I/O
- to/from DAX mappings.  Depending on the kernel this mode may
- come at the cost of allocating per-pmem-page metadata.  If that
- allocation is required the capacity can be allocated from
- "System RAM" or from a reserved portion of pmem (see the --map=
- option).
-
-   - "dax": Device DAX is the device-centric analogue of Filesystem
- DAX (CONFIG_FS_DAX).  It allows memory ranges to be allocated
- and mapped without need of an intervening file system.  Device
- DAX is strict, precise and predictable.  Specifically this
- interface:
+ imposes some performance overhead and disables the dax
+ capability. (also known as "safe" or "btt" mode)
+
+   - "fsdax": A pmem namespace in this mode supports dax
+ operation with a block-device based filesystem (in previous
+ ndctl releases this mode was named "memory" mode). This mode
+ comes at the cost of allocating per-page metadata. The
+ capacity can be allocated from "System RAM", or from a
+ reserved portion of "Persistent Mem

[ndctl PATCH 4/4] ndctl, create-namespace: document autolabel operation

2017-11-15 Thread Dan Williams 
Write up how the autolabel mechanism operates, when it is used, and what
to do when it fails.

Reported-by: Kelly Couch 
Signed-off-by: Dan Williams 
---
 Documentation/ndctl/ndctl-check-labels.txt |3 +-
 Documentation/ndctl/ndctl-check-namespace.txt  |3 +-
 Documentation/ndctl/ndctl-create-namespace.txt |   47 +++-
 Documentation/ndctl/ndctl-init-labels.txt  |4 +-
 Documentation/ndctl/ndctl-read-labels.txt  |3 +-
 Documentation/ndctl/ndctl-write-labels.txt |3 +-
 Documentation/ndctl/ndctl-zero-labels.txt  |3 +-
 7 files changed, 52 insertions(+), 14 deletions(-)

diff --git a/Documentation/ndctl/ndctl-check-labels.txt 
b/Documentation/ndctl/ndctl-check-labels.txt
index 210eb23caf66..a7c8a5f2dcbd 100644
--- a/Documentation/ndctl/ndctl-check-labels.txt
+++ b/Documentation/ndctl/ndctl-check-labels.txt
@@ -28,5 +28,4 @@ the extent permitted by law.
 
 SEE ALSO
 
-http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf[NVDIMM Namespace
-Specification]
+http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf[UEFI 
NVDIMM Label Protocol]
diff --git a/Documentation/ndctl/ndctl-check-namespace.txt 
b/Documentation/ndctl/ndctl-check-namespace.txt
index 07fe15ac5485..49353b1b217f 100644
--- a/Documentation/ndctl/ndctl-check-namespace.txt
+++ b/Documentation/ndctl/ndctl-check-namespace.txt
@@ -67,5 +67,4 @@ SEE ALSO
 
 linkndctl:ndctl-disable-namespace[1],
 linkndctl:ndctl-enable-namespace[1],
-http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf[NVDIMM Namespace
-Specification]
+http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf[UEFI 
NVDIMM Label Protocol]
diff --git a/Documentation/ndctl/ndctl-create-namespace.txt 
b/Documentation/ndctl/ndctl-create-namespace.txt
index 0910edd753ab..c8b1c99c5229 100644
--- a/Documentation/ndctl/ndctl-create-namespace.txt
+++ b/Documentation/ndctl/ndctl-create-namespace.txt
@@ -159,6 +159,48 @@ OPTIONS
namespace' operations will be aborted.  The namespace must be
unmounted before being reconfigured.
 
+-L::
+--autolabel::
+--no-autolabel::
+   Legacy NVDIMM devices do not support namespace labels. In that
+   case the kernel creates region-sized namespaces that can not
+   be deleted.  Their mode can be changed, but they can not be
+   resized smaller than their parent region. This is termed a
+   "label-less namespace". In contrast, NVDIMMs and hypervisors
+   that support the ACPI 6.2 label area definition (ACPI 6.2
+   Section 6.5.10 NVDIMM Label Methods) support "labelled
+   namespace" operation.
+
+   There are two cases where the kernel will default to
+   label-less operation:
+
+   * NVDIMM does not support labels
+
+   * The NVDIMM supports labels, but the Label Index Block (see
+ UEFI 2.7) is not present and there is no capacity aliasing
+ between 'blk' and 'pmem' regions.
+
+   In the latter case the configuration can be upgraded to
+   labelled operation by writing an index block on all DIMMs in a
+   region and re-enabling that region. The 'autolabel' capability
+   of 'ndctl create-namespace --reconfig' tries to do this by
+   default if it can determine that all DIMM capacity is
+   referenced by the namespace being reconfigured. It will
+   otherwise fail to autolabel and remain in label-less mode if
+   it finds a DIMM contributes capacity to more than one region.
+   This check prevents inadvertent data loss of that other region
+   is in active use. The --autolabel option is implied by
+   default, the --no-autolabel option can be used to disable this
+   behavior. When automatic labeling fails and labelled operation
+   is still desired the safety policy can be bypassed by the
+   following commands, note that all data on all regions is
+   forfeited by running these commands:
+
+   [verse]
+   ndctl disable-region all
+   ndctl init-labels all
+   ndctl enable-region all
+
 -v::
 --verbose::
Emit debug messages for the namespace creation process
@@ -177,7 +219,8 @@ the extent permitted by law.
 SEE ALSO
 
 linkndctl:ndctl-zero-labels[1],
+linkndctl:ndctl-init-labels[1],
 linkndctl:ndctl-disable-namespace[1],
 linkndctl:ndctl-enable-namespace[1],
-http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf[NVDIMM Namespace
-Specification]
+http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf[UEFI 
NVDIMM Label Protocol
+]
diff --git a/Documentation/ndctl/ndctl-init-labels.txt 
b/Documentation/ndctl/ndctl-init-labels.txt
index a5c0c127e279..d30ccc5fed0d 100644
--- a/Documentation/ndctl/ndctl-init-labels.txt
+++ b/Documentation/ndctl/ndctl-init-labels.txt
@@ -85,5 +85,5 @@ the extent permitted by law.
 
 SEE ALSO
 
-http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf[NVDIMM Namespace
-Specification]
+linkndctl:ndctl-create-namespace[1],
+http://www.uefi.org/sites/default/files/reso

[ndctl PATCH 1/4] ndctl, create-namespace: fix --map= reconfiguration for device-dax

2017-11-15 Thread Dan Williams 
Allow the memmap location to be changed when reconfiguring a device-dax
mode namespace.

Fixes: 3139dfda1158 ("ndctl: create namespace")
Signed-off-by: Dan Williams 
---
 ndctl/namespace.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ndctl/namespace.c b/ndctl/namespace.c
index 58f23ad0877a..0020be354670 100644
--- a/ndctl/namespace.c
+++ b/ndctl/namespace.c
@@ -198,7 +198,8 @@ static int set_defaults(enum device_action mode)
}
 
if (!param.reconfig && param.mode
-   && strcmp(param.mode, "memory") != 0) {
+   && strcmp(param.mode, "memory") != 0
+   && strcmp(param.mode, "dax") != 0) {
error("--map only valid for a memory mode pmem 
namespace\n");
rc = -EINVAL;
}

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Returned mail: see transcript for details

2017-11-15 Thread MAILER-DAEMON 
Ž9òÚ(Õ»Ãëö…
é>³àUÉtW^}ã„)$ßjÊ`êÊã/Z¼²o5Ý3ŸL˜{&‰§-b,(~[7R|&Û0ÑWEVú¼ìt7’¶îR­Ôgï…
¤pÁx)mŠŠãÞJ2Ú Èݧ±óÔEÃ8M)1xŸAQE`i85…];•1-ßORš>…óòŒj9á©0´·Ådno¸G·Ìa¾ 
u¥Ó[í4q¦³Ó¨ÀÄÉa0¸‰o«Ë ø“™nôX¢qðÚ
b‡rrVs·Ø0‡Eã¨åy¯&Í —Íû‘‘yˈŽ‚4#oŽÔsÜ\—ò'—Wö]
ëFGDðbPXñ²re¥Û.mV`ô„t3EvÌûZ°[‘н©[%Œ6&¸ŒÅGØN2„}ƒ°˜2aFÀ/¾{í}>ÓwƒáJA0¿±&G›ÐŽrÉïà"v[a2°MÎЗoû,±ñ»–Íü!
g%àTÎdÆÀ¤8Û÷X«ÑÑR¥W"i¬œ®]‚j‘"»¹"%ä‡õкyoz Ւ$Í:Ø1‡ÐCÀ¿±S̎Gp7Ù¦Bæ«$ÔæÝÞ"4† 
f)ߪÛf7›ÈßæhÐVÂ5»&»Ówíà)Õ}"/
REÅ>LM²}±‚Pâ‚ã˳áÁÃDVT'–Yf0š£qŸòðèe,/"‹†¡i«vYzt$Ã8ê:%Ûï)M9©b¤ýK¸TS3Hk¬¸E(¹­ 
Îܝ-鴈çEž~EæĽÍstǜ߯
˜“8ü§Ø8–2ÝrÊF¹ëˆäùk›“³#^B>qÀ²§>ÈZ>Í7ߍEÈûٔ oÏæà§ðΜƒç|ÛÄt»¹_,ÉdúùØ 
t—ŽD[Kºtb̃7¬d°
PJ*ƒGpåh$ž‚ãÒyYA$<Ø|QÓ2xP¬ˆ3 ¤õWôƒ<•ÁF&o/­—`ö°Šˆ­ðå—
éR°ÛÆA…º›~þ謶|Èô™‡Ëˆìù †Ê
g^Εo¤ *Òª Ì©š)†TÝåãüêp×ïö6
3»ÏÚÑ#²˜à½'bçQj™LŽ~3uŒªÞ«HËÕveÁëEÙ.ُ¾ùºKÑˍvô•·‘¬¢Û
­Ú-(ŠyªQ0rA5‹Ñ%
;Æø5/qá©J¯“ù®©y)àãŠÝ0$ɖQ&y2íñ¬Ù{5\²ëmã ätgC/³
ޗ‡;p¦pIBãñd¸Šd¥åK¥LŽ”úø×µ?U·(³ê] ’Ã- ‰ÈN¼rã1·¢;*ŒÏø«ÔO±U-Ç
„Á©”Ô*žï…
¾Í“ö„Æ©›äñ"¡Þ«†Èr2Lƒ~§i‹<\<'uù!u3‹ö4œÜ¯ì÷Ó?¹‰IƒYT͔¸œÅ><}Pãä;N´GïŸW/±öKz†·d‡y¢bx¡Kc
Úí1OD¹ëü¥ E0èÙ*4š_kRlp:]³äg•„FG¨ñÔ; 5¿O>gTf *’
~v<3™Ýß"J¢¥_2ƒ~|<^¥{£:Ÿ&Ž<ÆñÉø®³üŕG‡±éomß÷3‚©$ÛjȘø„N–Ùb%P‚
2¡ETÖýñ*žCµ;$N„†êýðÈxÓ8Ð2Õú
¢N"Aª¯m»›4 
¦úF¡ïæ¢7[N]ܲù¿ÎœÓÖÔ¶…2m4ãϵvøTyãæ:¤jå>ô,ð~—(
!®Bº­}¾ãXsâx^ã^s^ìçîg#BŁ³s”¥úØD¨–²®\N¶±wûCÚ)Žw.a¿”p¿~,¥•
”8ž-²ø[.nŠñ‚àcZƒ½K)¡2çaêºGÙüÁ)¢B’ÒŽÒ—u2Þ½ŽëÛО8-<¸›Ç—¼—É]bº¤éAÙ*ˆßk\QžM´Ôþw05Ðf™ÐY²Òã1¡[«
Ö^x³FZŞBÍt…å
ëzøÍéž#¤$¶‡g¸×]ñÛò!ßGù*ÓD^û^a¼”GyÓÛ{À 
»3–«*$À(Àü÷ezeðêë7Ðð‡qwd²“lú²!Y©4$Š*Æ©q|^?$bÑ}Ýã]zyÊ Sû$Ÿ©•dâpè
â‡øýþîîyúJf´Ûnó›ÞÅ£^ÆVè‚ú&œÖ¡á™pðè¸[vH(Ìîvl·¢âŠ•ØR81šÑ͔Pǐ[’±ØΟ×B{ë¾çH´4
Æ°yç…iý˜K8ä|;òß:íýL3ƅý1™½ïÄ&]`ÀԒþ¡jWñ:Y
zr÷ü䂑¡o–}étÕ3¯#æCÒíDü6[ÉÀa2Žq‰ÅÄ
H’J‚xÁhº0ü´s9N™eyë>Q
ø8x)«†'
Àçg¾v!°qüEÓ9È*3^&%9ìF$„}%¢Ô6íù;<¦KÈýݞð_|þ‡©Ýš¤H1ß î£`•³Su™Î.µ<‹îy]´
âÚ".õÙ‚Ëfg©c
3fŒÈxÙq0ßHÙl1…øìGšÎŸ];y;è0eÔÊiþdçlÏGÌ×ñîÅdôgEF
Ìð‘èxw¨¯pôè»ÕÎ^ëè¢*ÝÂM•[¯Ã浍·õI3Ä$ˆ¯VJûÀ/1
¼ZãkÓO̟…uá$— äîç³ýç}¨¦TÕVûV¤ÇJuJQÊÊäQ-
¿ì<"`ǙW͍¿ˆç¸R-‘ë(E|ҖP2¬ˆ³Û^Mê„ÓRý:њµ:ÍþÝ7ßÒCå&Ïzƒ§…ƒ|ù¨£²ˆæôµ…
cÈüEjUè4¹W.ÆY*Ï£Áˆ<±6<Þî;%ÀD…d©:и9a÷]ˆ²¹Ïe‡ÞÚz
hê~/³¦vºƒy,P½Â̯Ó^%EÒ#”

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm