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: linkBe 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).