From: Mike Snitzer <snitzer@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: dm-devel@redhat.com, Alasdair Kergon <agk@redhat.com>,
Zdenek Kabelac <zkabelac@redhat.com>
Subject: Re: [dm-devel] [PATCH v2] dm-ioctl: return UUID in DM_LIST_DEVICES_CMD result
Date: Thu, 11 Mar 2021 13:41:16 -0500 [thread overview]
Message-ID: <20210311184116.GB28637@redhat.com> (raw)
In-Reply-To: <alpine.LRH.2.02.2103111326050.28706@file01.intranet.prod.int.rdu2.redhat.com>
On Thu, Mar 11 2021 at 1:26pm -0500,
Mikulas Patocka <mpatocka@redhat.com> wrote:
> When LVM needs to find a device with a particular UUID it needs to ask for
> UUID for each device. This patch returns UUID directly in the list of
> devices, so that LVM doesn't have to query all the devices with an ioctl.
> The UUID is returned if the flag DM_UUID_FLAG is set in the parameters.
>
> Returning UUID is done in backward-compatible way. There's one unused
> 32-bit word value after the event number. This patch sets the bit
> DM_NAME_LIST_FLAG_HAS_UUID if UUID is present and
> DM_NAME_LIST_FLAG_DOESNT_HAVE_UUID if it isn't (if none of these bits is
> set, then we have an old kernel that doesn't support returning UUIDs). The
> UUID is stored after this word. The 'next' value is updated to point after
> the UUID, so that old version of libdevmapper will skip the UUID without
> attempting to interpret it.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>
> ---
> drivers/md/dm-ioctl.c | 20 +++++++++++++++++---
> include/uapi/linux/dm-ioctl.h | 7 +++++++
> 2 files changed, 24 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/drivers/md/dm-ioctl.c
> ===================================================================
> --- linux-2.6.orig/drivers/md/dm-ioctl.c 2021-03-09 21:04:07.000000000 +0100
> +++ linux-2.6/drivers/md/dm-ioctl.c 2021-03-11 18:53:58.000000000 +0100
> @@ -558,7 +558,9 @@ static int list_devices(struct file *fil
> for (n = rb_first(&name_rb_tree); n; n = rb_next(n)) {
> hc = container_of(n, struct hash_cell, name_node);
> needed += align_val(offsetof(struct dm_name_list, name) + strlen(hc->name) + 1);
> - needed += align_val(sizeof(uint32_t));
> + needed += align_val(sizeof(uint32_t) * 2);
> + if (param->flags & DM_UUID_FLAG && hc->uuid)
> + needed += align_val(strlen(hc->uuid) + 1);
> }
>
> /*
> @@ -577,6 +579,7 @@ static int list_devices(struct file *fil
> * Now loop through filling out the names.
> */
> for (n = rb_first(&name_rb_tree); n; n = rb_next(n)) {
> + void *uuid_ptr;
> hc = container_of(n, struct hash_cell, name_node);
> if (old_nl)
> old_nl->next = (uint32_t) ((void *) nl -
> @@ -588,8 +591,19 @@ static int list_devices(struct file *fil
>
> old_nl = nl;
> event_nr = align_ptr(nl->name + strlen(hc->name) + 1);
> - *event_nr = dm_get_event_nr(hc->md);
> - nl = align_ptr(event_nr + 1);
> + event_nr[0] = dm_get_event_nr(hc->md);
> + event_nr[1] = 0;
> + uuid_ptr = align_ptr(event_nr + 2);
> + if (param->flags & DM_UUID_FLAG) {
> + if (hc->uuid) {
> + event_nr[1] |= DM_NAME_LIST_FLAG_HAS_UUID;
> + strcpy(uuid_ptr, hc->uuid);
> + uuid_ptr = align_ptr(uuid_ptr + strlen(hc->uuid) + 1);
> + } else {
> + event_nr[1] |= DM_NAME_LIST_FLAG_DOESNT_HAVE_UUID;
> + }
> + }
> + nl = uuid_ptr;
> }
> /*
> * If mismatch happens, security may be compromised due to buffer
> Index: linux-2.6/include/uapi/linux/dm-ioctl.h
> ===================================================================
> --- linux-2.6.orig/include/uapi/linux/dm-ioctl.h 2021-03-09 12:20:23.000000000 +0100
> +++ linux-2.6/include/uapi/linux/dm-ioctl.h 2021-03-11 18:42:14.000000000 +0100
> @@ -193,8 +193,15 @@ struct dm_name_list {
> __u32 next; /* offset to the next record from
> the _start_ of this */
> char name[0];
> +
> + /* uint32_t event_nr; */
> + /* uint32_t flags; */
> + /* char uuid[0]; */
> };
If extra padding is being leveraged here (from the __u32 next), why not
at least explicitly add the members and then pad out the balance of that
__u32? I'm not liking the usage of phantom struct members.. e.g.
the games played with accessing them.
Mike
>
> +#define DM_NAME_LIST_FLAG_HAS_UUID 1
> +#define DM_NAME_LIST_FLAG_DOESNT_HAVE_UUID 2
> +
> /*
> * Used to retrieve the target versions
> */
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-03-11 18:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-11 18:26 [dm-devel] [PATCH v2] dm-ioctl: return UUID in DM_LIST_DEVICES_CMD result Mikulas Patocka
2021-03-11 18:41 ` Mike Snitzer [this message]
2021-03-11 19:43 ` Mikulas Patocka
2021-03-11 20:07 ` Mike Snitzer
2021-03-12 14:07 ` [dm-devel] [PATCH v3] " Mikulas Patocka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210311184116.GB28637@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=mpatocka@redhat.com \
--cc=zkabelac@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.