From: Dave Wysochanski <dwysocha@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH] Add possibility to exclude internal VG names and uuids in lists returned from liblvm (and lvmcache)
Date: Tue, 26 Jan 2010 15:57:20 -0500 [thread overview]
Message-ID: <1264539440.2459.1.camel@f10-node1> (raw)
In-Reply-To: <4B5EF8E3.5040401@redhat.com>
On Tue, 2010-01-26 at 15:14 +0100, Peter Rajnoha wrote:
> This is related to liblvm and its lvm_list_vg_names() and lvm_list_vg_uuids() functions
> where we should not expose internal VG names/uuids (the ones with "#" prefix )through the
> interface. Otherwise, we could end up with library users opening internal VGs which will
> initiate locking mechanism that won't be cleaned up properly.
>
> "#orphans_{lvm1, lvm2, pool}" names are treated in a special way, they are truncated first
> to "orphans" and this is used as a part of the lock name then (e.g. while calling lvm_vg_open()).
> When library user calls lvm_vg_close(), the original name "orphans_{lvm1, lvm2, pool}"
> is used directly and therefore no unlock occurs.
>
> This simple patch adds possibility to exclude those internal VG names and ids in the
> lists provided by lvmcache: lvmcache_get_vgids() and lvmcache_get_vgnames().
>
> (The actual problem we can observe now occurs while using udisks-lvm-pv-export that is
> called from udisks udev rule. This reserves the lock and prevents, for example, vgcreate
> to succeed...)
>
> Peter
>
Looks good Peter. Reviewed line by line and tested.
Ack.
prev parent reply other threads:[~2010-01-26 20:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-26 14:14 [PATCH] Add possibility to exclude internal VG names and uuids in lists returned from liblvm (and lvmcache) Peter Rajnoha
2010-01-26 20:57 ` Dave Wysochanski [this message]
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=1264539440.2459.1.camel@f10-node1 \
--to=dwysocha@redhat.com \
--cc=lvm-devel@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.