public inbox for lvm2-cvs@sourceware.org
help / color / mirror / Atom feed
From: prajnoha@sourceware.org
To: lvm-devel@redhat.com, lvm2-cvs@sourceware.org
Subject: LVM2 ./WHATS_NEW_DM libdm/ioctl/libdm-iface.c ...
Date: Tue, 23 Mar 2010 14:38:00 -0000 [thread overview]
Message-ID: <20100323143838.1204.qmail@sourceware.org> (raw)
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: prajnoha@sourceware.org 2010-03-23 14:38:38
Modified files:
. : WHATS_NEW_DM
libdm/ioctl : libdm-iface.c
libdm/misc : dm-ioctl.h
Log message:
Add support for ioctl's DM_UEVENT_GENERATED_FLAG.
We need to know whether we should wait for any uevent or not when
using udev_sync. A kernel patch was posted recently that changed the
way uevents are sent on dm device resume - it is sent only if the
device has been suspended before. There's also a new DM_UEVENT_GENERATED_FLAG
in the ioctl to notify userspace whether the event was generated.
If the uevent was not generated (e.g. the situation where the device is
*not* suspended and we call a resume), we just call dm_udev_complete
explicitly from within libdevmapper itself to prevent infinite waiting
while trying to synchronise with udev processing.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW_DM.diff?cvsroot=lvm2&r1=1.350&r2=1.351
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/libdm/ioctl/libdm-iface.c.diff?cvsroot=lvm2&r1=1.67&r2=1.68
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/libdm/misc/dm-ioctl.h.diff?cvsroot=lvm2&r1=1.3&r2=1.4
--- LVM2/WHATS_NEW_DM 2010/03/09 14:01:47 1.350
+++ LVM2/WHATS_NEW_DM 2010/03/23 14:38:37 1.351
@@ -1,5 +1,6 @@
Version 1.02.46 -
================================
+ Add support for ioctl's DM_UEVENT_GENERATED_FLAG.
Version 1.02.45 - 9th March 2010
================================
--- LVM2/libdm/ioctl/libdm-iface.c 2010/02/15 16:21:34 1.67
+++ LVM2/libdm/ioctl/libdm-iface.c 2010/03/23 14:38:37 1.68
@@ -1505,18 +1505,28 @@
*/
static int _udev_complete(struct dm_task *dmt)
{
- uint32_t cookie;
+ uint16_t base;
- if (dmt->cookie_set) {
+ if (dmt->cookie_set &&
+ (base = dmt->event_nr & ~DM_UDEV_FLAGS_MASK))
/* strip flags from the cookie and use cookie magic instead */
- cookie = (dmt->event_nr & ~DM_UDEV_FLAGS_MASK) |
- (DM_COOKIE_MAGIC << DM_UDEV_FLAGS_SHIFT);
- return dm_udev_complete(cookie);
- }
+ return dm_udev_complete(base | (DM_COOKIE_MAGIC <<
+ DM_UDEV_FLAGS_SHIFT));
return 1;
}
+static int _check_uevent_generated(struct dm_ioctl *dmi)
+{
+ if (!dm_check_version() ||
+ _dm_version < 4 ||
+ _dm_version_minor < 17)
+ /* can't check, assume uevent is generated */
+ return 1;
+
+ return dmi->flags & DM_UEVENT_GENERATED_FLAG;
+}
+
static int _create_and_load_v4(struct dm_task *dmt)
{
struct dm_task *task;
@@ -1691,6 +1701,7 @@
unsigned repeat_count)
{
struct dm_ioctl *dmi;
+ int ioctl_with_uevent;
dmi = _flatten(dmt, repeat_count);
if (!dmi) {
@@ -1706,6 +1717,10 @@
if (dmt->no_open_count)
dmi->flags |= DM_SKIP_BDGET_FLAG;
+ ioctl_with_uevent = dmt->type == DM_DEVICE_RESUME ||
+ dmt->type == DM_DEVICE_REMOVE ||
+ dmt->type == DM_DEVICE_RENAME;
+
/*
* Prevent udev vs. libdevmapper race when processing nodes and
* symlinks. This can happen when the udev rules are installed and
@@ -1715,10 +1730,7 @@
* to be applied at all in this situation so we can gracefully fallback
* to libdevmapper's node and symlink creation code.
*/
- if (dm_udev_get_sync_support() && !dmt->cookie_set &&
- (dmt->type == DM_DEVICE_RESUME ||
- dmt->type == DM_DEVICE_REMOVE ||
- dmt->type == DM_DEVICE_RENAME)) {
+ if (dm_udev_get_sync_support() && !dmt->cookie_set && ioctl_with_uevent) {
log_debug("Cookie value is not set while trying to call "
"DM_DEVICE_RESUME, DM_DEVICE_REMOVE or DM_DEVICE_RENAME "
"ioctl. Please, consider using libdevmapper's udev "
@@ -1774,6 +1786,10 @@
return NULL;
}
}
+
+ if (ioctl_with_uevent && !_check_uevent_generated(dmi))
+ _udev_complete(dmt);
+
#else /* Userspace alternative for testing */
#endif
return dmi;
--- LVM2/libdm/misc/dm-ioctl.h 2009/11/06 00:43:09 1.3
+++ LVM2/libdm/misc/dm-ioctl.h 2010/03/23 14:38:38 1.4
@@ -268,9 +268,9 @@
#define DM_DEV_SET_GEOMETRY _IOWR(DM_IOCTL, DM_DEV_SET_GEOMETRY_CMD, struct dm_ioctl)
#define DM_VERSION_MAJOR 4
-#define DM_VERSION_MINOR 16
+#define DM_VERSION_MINOR 17
#define DM_VERSION_PATCHLEVEL 0
-#define DM_VERSION_EXTRA "-ioctl (2009-11-05)"
+#define DM_VERSION_EXTRA "-ioctl (2010-03-05)"
/* Status bits */
#define DM_READONLY_FLAG (1 << 0) /* In/Out */
@@ -318,4 +318,9 @@
*/
#define DM_QUERY_INACTIVE_TABLE_FLAG (1 << 12) /* In */
+/*
+ * If set, a uevent was generated for which the caller may need to wait.
+ */
+#define DM_UEVENT_GENERATED_FLAG (1 << 13) /* Out */
+
#endif /* _LINUX_DM_IOCTL_H */
next reply other threads:[~2010-03-23 14:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-23 14:38 prajnoha [this message]
2010-04-07 15:57 mbroz
2010-06-01 16:08 prajnoha
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=20100323143838.1204.qmail@sourceware.org \
--to=prajnoha@sourceware.org \
--cc=lvm-devel@redhat.com \
--cc=lvm2-cvs@sourceware.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).