lkml.org 
[lkml]   [2019]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] libnvdimm: Clarify nd_pfn_init() flow
On Fri, Jan 18, 2019 at 04:47:23PM -0800, Dan Williams wrote:
>In recent days, 2 engineers, including the original author of
>nd_pfn_init(), overlooked the internal call to nd_pfn_validate() and the
>implications to memory allocation.
>
>Clarify this situation to help anyone that reads through this code in
>the future.
>
>Reported-by: Wei Yang <richardw.yang@linux.intel.com>
>Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>---
> drivers/nvdimm/btt_devs.c | 5 +++++
> drivers/nvdimm/dax_devs.c | 5 +++++
> drivers/nvdimm/pfn_devs.c | 21 +++++++++++++++++++++
> 3 files changed, 31 insertions(+)
>
>diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
>index 795ad4ff35ca..e0a6f2491e57 100644
>--- a/drivers/nvdimm/btt_devs.c
>+++ b/drivers/nvdimm/btt_devs.c
>@@ -354,6 +354,11 @@ int nd_btt_probe(struct device *dev, struct nd_namespace_common *ndns)
> put_device(btt_dev);
> }
>
>+ /*
>+ * Successful probe indicates to the caller that an nd_btt
>+ * personality device has been registered and the caller can
>+ * fail the probe of the baseline namespace device.
>+ */
> return rc;
> }
> EXPORT_SYMBOL(nd_btt_probe);
>diff --git a/drivers/nvdimm/dax_devs.c b/drivers/nvdimm/dax_devs.c
>index 0453f49dc708..65010d955fa7 100644
>--- a/drivers/nvdimm/dax_devs.c
>+++ b/drivers/nvdimm/dax_devs.c
>@@ -136,6 +136,11 @@ int nd_dax_probe(struct device *dev, struct nd_namespace_common *ndns)
> } else
> __nd_device_register(dax_dev);
>
>+ /*
>+ * Successful probe indicates to the caller that a device-dax
>+ * personality device has been registered and the caller can
>+ * fail the probe of the baseline namespace device.
>+ */
> return rc;
> }
> EXPORT_SYMBOL(nd_dax_probe);
>diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
>index 6f22272e8d80..a8783b5a76ba 100644
>--- a/drivers/nvdimm/pfn_devs.c
>+++ b/drivers/nvdimm/pfn_devs.c
>@@ -576,6 +576,11 @@ int nd_pfn_probe(struct device *dev, struct nd_namespace_common *ndns)
> } else
> __nd_device_register(pfn_dev);
>
>+ /*
>+ * Successful probe indicates to the caller that an nd_pfn
>+ * personality device has been registered and the caller can
>+ * fail the probe of the baseline namespace device.
>+ */
> return rc;
> }
> EXPORT_SYMBOL(nd_pfn_probe);
>@@ -706,6 +711,22 @@ static int nd_pfn_init(struct nd_pfn *nd_pfn)
> sig = DAX_SIG;
> else
> sig = PFN_SIG;
>+
>+ /*
>+ * Check for an existing 'pfn' superblock before writing a new
>+ * one. The intended flow is that on the first probe of an
>+ * nd_{pfn,dax} device the superblock is calculated and written
>+ * to the namespace. In this case nd_pfn_validate() returns
>+ * -ENODEV because no valid superblock exists currently.
>+ *
>+ * On subsequent probes nd_pfn_validate() will find a valid
>+ * superblock and return 0.
>+ *
>+ * If an assumption of the superblock has been violated, like a
>+ * change to the physical alignment of the namespace,
>+ * nd_pfn_validate() will return an error other than -ENODEV to
>+ * fail probing.
>+ */

How about adjust this a little like:

Check for an existing 'pfn' superblock before writing a new one.

Return:

-ENODEV: no valid superblock exists
0 : valid superblock exists
other : superblock violation, e.g. physical alignment change

One superblock should be configured, before an nd_{pfn,dax} device be
used properly.

One newly create nd_{pfn,dax} device has no valid superblock. In this case
nd_pfn_validate() returns -ENODEV to make driver continue and write
configuration to superblock.

After proper configuration the first time, subsequent nd_pfn_validate()
will find a valid superblock and return 0. So that driver will return
immediately without configuring superblock again.

An error other than -ENODEV means superblock violation, which fail
probing.

> rc = nd_pfn_validate(nd_pfn, sig);
> if (rc != -ENODEV)
> return rc;

--
Wei Yang
Help you, Help me

\
 
 \ /
  Last update: 2019-01-22 04:37    [W:0.175 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site