Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1663358 > unrolled thread

[PATCH v2] nvme: use uuid_t in nvme_ns

Back to article view | Back to linux.kernel

Contents

  [PATCH v2] nvme: use uuid_t in nvme_ns Johannes Thumshirn <jthumshirn@suse.de> - 2017-06-12 11:20 +0200
    Re: [PATCH v2] nvme: use uuid_t in nvme_ns Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-06-12 12:00 +0200
      Re: [PATCH v2] nvme: use uuid_t in nvme_ns Johannes Thumshirn <jthumshirn@suse.de> - 2017-06-12 12:10 +0200
        Re: [PATCH v2] nvme: use uuid_t in nvme_ns Christoph Hellwig <hch@lst.de> - 2017-06-12 13:10 +0200
          Re: [PATCH v2] nvme: use uuid_t in nvme_ns Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-06-12 15:20 +0200
    Re: [PATCH v2] nvme: use uuid_t in nvme_ns Christoph Hellwig <hch@lst.de> - 2017-06-12 18:10 +0200
    Re: [PATCH v2] nvme: use uuid_t in nvme_ns Sagi Grimberg <sagi@grimberg.me> - 2017-06-15 11:00 +0200

#1663358 — [PATCH v2] nvme: use uuid_t in nvme_ns

struct nvme_ns still uses u u8 uuid[16], change it to using uuid_t and
use the UUID API.

Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
---
 drivers/nvme/host/core.c | 8 ++++----
 drivers/nvme/host/nvme.h | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index c427a7fc31ae..838523441bdb 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -699,7 +699,7 @@ static int nvme_identify_ns_descs(struct nvme_ns *ns, unsigned nsid)
 				goto free_data;
 			}
 			len = NVME_NIDT_UUID_LEN;
-			memcpy(ns->uuid, data + pos + sizeof(*cur), len);
+			uuid_copy(&ns->uuid, data + pos + sizeof(*cur));
 			break;
 		default:
 			/* Skip unnkown types */
@@ -1895,12 +1895,12 @@ static ssize_t uuid_show(struct device *dev, struct device_attribute *attr,
 	/* For backward compatibility expose the NGUID to userspace if
 	 * we have no UUID set
 	 */
-	if (!memchr_inv(ns->uuid, 0, sizeof(ns->uuid))) {
+	if (uuid_is_null(&ns->uuid)) {
 		printk_ratelimited(KERN_WARNING
 				   "No UUID available providing old NGUID\n");
 		return sprintf(buf, "%pU\n", ns->nguid);
 	}
-	return sprintf(buf, "%pU\n", ns->uuid);
+	return sprintf(buf, "%pU\n", &ns->uuid);
 }
 static DEVICE_ATTR(uuid, S_IRUGO, uuid_show, NULL);
 
@@ -1936,7 +1936,7 @@ static umode_t nvme_ns_attrs_are_visible(struct kobject *kobj,
 	struct nvme_ns *ns = nvme_get_ns_from_dev(dev);
 
 	if (a == &dev_attr_uuid.attr) {
-		if (!memchr_inv(ns->uuid, 0, sizeof(ns->uuid)) ||
+		if (uuid_is_null(&ns->uuid) ||
 		    !memchr_inv(ns->nguid, 0, sizeof(ns->nguid)))
 			return 0;
 	}
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 7007521e8194..8ac225882097 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -190,7 +190,7 @@ struct nvme_ns {
 
 	u8 eui[8];
 	u8 nguid[16];
-	u8 uuid[16];
+	uuid_t uuid;
 
 	unsigned ns_id;
 	int lba_shift;
-- 
2.12.3

[toc] | [next] | [standalone]

#1663388

On Mon, Jun 12, 2017 at 12:12 PM, Johannes Thumshirn <jthumshirn@suse.de> wrote:
> struct nvme_ns still uses u u8 uuid[16], change it to using uuid_t and
> use the UUID API.

Thanks for an update.

See my further comments below.

>                         len = NVME_NIDT_UUID_LEN;
> -                       memcpy(ns->uuid, data + pos + sizeof(*cur), len);
> +                       uuid_copy(&ns->uuid, data + pos + sizeof(*cur));

So, this reveals two thins:
1) shall we define NVME_NIDT_UUID_LEN to be UUID_LEN or substitute it
completely with the latter?
2) Is the len variable used later in the function?

> -               if (!memchr_inv(ns->uuid, 0, sizeof(ns->uuid)) ||
> +               if (uuid_is_null(&ns->uuid) ||
>                     !memchr_inv(ns->nguid, 0, sizeof(ns->nguid)))

>         u8 nguid[16];
> -       u8 uuid[16];
> +       uuid_t uuid;

Do you plan to switch nguid to be guid_t / uuid_t ?

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1663392

On 06/12/2017 11:50 AM, Andy Shevchenko wrote:
>>                         len = NVME_NIDT_UUID_LEN;
>> -                       memcpy(ns->uuid, data + pos + sizeof(*cur), len);
>> +                       uuid_copy(&ns->uuid, data + pos + sizeof(*cur));
> 
> So, this reveals two thins:
> 1) shall we define NVME_NIDT_UUID_LEN to be UUID_LEN or substitute it
> completely with the latter?

No, we have NVME_NIDT_UUID_LEN but also NVME_NIDT_NGUID_LEN and
NVME_NIDT_EUI64_LEN.

> 2) Is the len variable used later in the function?

Yes, we have to iterate the buffer by len, which can (currently) be
either 8 or 16 bytes. New types which may emerge someday in the future
might have a different length.

> 
>> -               if (!memchr_inv(ns->uuid, 0, sizeof(ns->uuid)) ||
>> +               if (uuid_is_null(&ns->uuid) ||
>>                     !memchr_inv(ns->nguid, 0, sizeof(ns->nguid)))
> 
>>         u8 nguid[16];
>> -       u8 uuid[16];
>> +       uuid_t uuid;
> 
> Do you plan to switch nguid to be guid_t / uuid_t ?
> 

I'm not sure the NVMe NGUID is the same as a GUID (a.k.a little endian
UUID). Quoting from the spec:

"This field uses the EUI-64 based 16-byte designator format. Bytes
114:112 contain the 24-bit Organizationally Unique Identifier (OUI)
value assigned by the IEEE Registration Authority. Bytes 119:115 contain
an extension identifer assigned by the corresponding organization. Bytes
111:104 contain the vendor specific extension identifier assigned by the
corresponding organization. See the IEEE EUI-64 guidelines for more
information."

But maybe Christoph can clarify it.

Byte,
	Johannes
-- 
Johannes Thumshirn                                          Storage
jthumshirn@suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

[toc] | [prev] | [next] | [standalone]

#1663427

On Mon, Jun 12, 2017 at 12:04:18PM +0200, Johannes Thumshirn wrote:
> > So, this reveals two thins:
> > 1) shall we define NVME_NIDT_UUID_LEN to be UUID_LEN or substitute it
> > completely with the latter?
> 
> No, we have NVME_NIDT_UUID_LEN but also NVME_NIDT_NGUID_LEN and
> NVME_NIDT_EUI64_LEN.

Yeah, and I'd rather keep the defines for fields defined in the spec
in nvme.h

> I'm not sure the NVMe NGUID is the same as a GUID (a.k.a little endian
> UUID). Quoting from the spec:

It's not at all, the field just has a very unfortunate name in the
spec.

[toc] | [prev] | [next] | [standalone]

#1663500

On Mon, Jun 12, 2017 at 2:03 PM, Christoph Hellwig <hch@lst.de> wrote:
> On Mon, Jun 12, 2017 at 12:04:18PM +0200, Johannes Thumshirn wrote:
>> > So, this reveals two thins:
>> > 1) shall we define NVME_NIDT_UUID_LEN to be UUID_LEN or substitute it
>> > completely with the latter?
>>
>> No, we have NVME_NIDT_UUID_LEN but also NVME_NIDT_NGUID_LEN and
>> NVME_NIDT_EUI64_LEN.
>
> Yeah, and I'd rather keep the defines for fields defined in the spec
> in nvme.h
>
>> I'm not sure the NVMe NGUID is the same as a GUID (a.k.a little endian
>> UUID). Quoting from the spec:
>
> It's not at all, the field just has a very unfortunate name in the
> spec.

Thanks for explanations.

So, wrt that
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1663822

On Mon, Jun 12, 2017 at 11:12:40AM +0200, Johannes Thumshirn wrote:
> struct nvme_ns still uses u u8 uuid[16], change it to using uuid_t and
> use the UUID API.
> 
> Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>

Thanks, folded into the two patches originall introducing the code.

[toc] | [prev] | [next] | [standalone]

#1666583

Reviewed-by: Sagi Grimberg <sagi@grimberg.me>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web