search for: do_list_dm_devices

Displaying 9 results from an estimated 9 matches for "do_list_dm_devices".

2016 Jul 07
0
[PATCH 2/2] daemon: fix cleanup of stringsbuf usages
...p = out; while (p) { @@ -183,7 +183,7 @@ filter_convert_old_lvs_output (char *out) if (end_stringsbuf (&ret) == -1) return NULL; - return ret.argv; + return take_stringsbuf (&ret); } char ** @@ -889,7 +889,7 @@ do_lvm_canonical_lv_name (const char *device) char ** do_list_dm_devices (void) { - DECLARE_STRINGSBUF (ret); + CLEANUP_FREE_STRINGSBUF DECLARE_STRINGSBUF (ret); struct dirent *d; DIR *dir; int r; @@ -917,7 +917,6 @@ do_list_dm_devices (void) if (asprintf (&devname, "/dev/mapper/%s", d->d_name) == -1) { reply_with_perror (&quot...
2016 Jul 07
2
[PATCH 1/2] daemon: free the string on stringsbuf add failure
If add_string_nodup fails free the passed string instead of leaking it, as that string would have been owned by the stringbuf. Adapt few places to this behaviour. --- daemon/btrfs.c | 4 +--- daemon/devsparts.c | 8 ++++---- daemon/guestfsd.c | 1 + 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/daemon/btrfs.c b/daemon/btrfs.c index 9b52aa8..d70565a 100644 ---
2012 Mar 13
2
[PATCH 0/2] 'int' to 'size_t' changes
These two patches are probably not completely independent, but separating them is a lot of work. With *both* patches applied, all the tests and extra-tests pass. That's no guarantee however that there isn't a mistake, so I don't think this patch is a candidate for the 1.16 branch, until it's had a lot more testing in development. Rich.
2016 Mar 06
8
[PATCH 0/5] Use less stack.
Various changes/fixes to use smaller stack frames. Rich.
2016 Mar 07
2
[PATCH v2] Use less stack.
...ot;asprintf"); + return -1; + } if (access (devmapper, F_OK) == 0) { reply_with_error ("%s: device already exists", devmapper); return -1; diff --git a/daemon/lvm.c b/daemon/lvm.c index 529e20d..2b61357 100644 --- a/daemon/lvm.c +++ b/daemon/lvm.c @@ -901,6 +901,8 @@ do_list_dm_devices (void) } while (1) { + CLEANUP_FREE char *devname = NULL; + errno = 0; d = readdir (dir); if (d == NULL) break; @@ -913,10 +915,12 @@ do_list_dm_devices (void) if (STREQ (d->d_name, "control")) continue; - size_t len = strlen (d->d_name); -...
2012 Feb 01
1
[PATCH] Clarify the error message when unavailable functions are called (RHBZ#679737).
...753,7 +807,11 @@ char * do_lvm_canonical_lv_name (const char *device) { char *canonical; - int r = lv_canonical (device, &canonical); + int r; + + IF_NOT_AVAILABLE_ERROR (lvm2, NULL); + + r = lv_canonical (device, &canonical); if (r == -1) return NULL; @@ -775,6 +833,8 @@ do_list_dm_devices (void) DIR *dir; int r; + IF_NOT_AVAILABLE_ERROR (lvm2, NULL); + dir = opendir ("/dev/mapper"); if (!dir) { reply_with_perror ("opendir: /dev/mapper"); diff --git a/daemon/md.c b/daemon/md.c index 41e2c75..fb3a4a7 100644 --- a/daemon/md.c +++ b/daemon/md.c @@...
2020 Sep 07
9
[PATCH v2 0/7] Windows BitLocker support.
Original version linked from here: https://bugzilla.redhat.com/show_bug.cgi?id=1808977#c8 There is no change in the code in this series, but feedback from the original series was we shouldn't lose the error message in patch 7. When I tested this just now in fact we don't lose the error if debugging is enabled, but I have updated the commit message to note what the error message is in the
2020 Mar 30
9
[PATCH 0/7] Support Windows BitLocker (RHBZ#1808977).
These commits, along with the associated changes to common: https://www.redhat.com/archives/libguestfs/2020-March/msg00286.html support the transparent decryption and inspection of Windows guests encrypted with BitLocker encryption. To do the BitLocker decryption requires cryptsetup 2.3.0 (although cryptsetup 2.3 is not required for existing LUKS use). It also requires a new-ish Linux kernel, I
2020 Sep 17
13
[PATCH v3 0/8] Windows BitLocker support.
As discussed in the emails today, this is the third version addressing most points from the v1/v2 review. You will need to pair this with the changes in libguestfs-common from this series: https://www.redhat.com/archives/libguestfs/2020-September/msg00050.html Rich.