[Qemu-devel] [PULL 0/4] Usb 20190307 patches

[Qemu-devel] [PULL 0/4] Usb 20190307 patches

[Gerd Hoffmann]

The following changes since commit 32694e98b8d7a246345448a8f707d2e11d6c65e2:

  Merge remote-tracking branch 'remotes/ehabkost/tags/machine-next-pull-request' into staging (2019-03-06 18:52:19 +0000)

are available in the Git repository at:

  git://git.kraxel.org/qemu tags/usb-20190307-pull-request

for you to fetch changes up to ba4c735b4fc74e309ce4b2551d258e442ef513a5:

  Introduce new "no_guest_reset" parameter for usb-host device (2019-03-07 10:03:54 +0100)

----------------------------------------------------------------
usb: mtp fixes, guest-reset switch for usb-host.

----------------------------------------------------------------

Alexander Kappner (1):
  Introduce new "no_guest_reset" parameter for usb-host device

Bandan Das (3):
  usb-mtp: return incomplete transfer on a lstat failure
  usb-mtp: fix some usb_mtp_write_data return paths
  usb-mtp: prevent null dereference while deleting objects

 hw/usb/dev-mtp.c     | 41 +++++++++++++++++++++++++----------------
 hw/usb/host-libusb.c |  7 ++++++-
 2 files changed, 31 insertions(+), 17 deletions(-)

-- 
2.18.1

[Qemu-devel] [PULL 1/4] usb-mtp: return incomplete transfer on a lstat failure

[Gerd Hoffmann]

From: Bandan Das <bsd@redhat.com>

MTP writes objects in small chunks and at the end gets the
real file size to update the object metadata. If this fails for
any reason, return an INCOMPLETE_TRANSFER to the initiator

Spotted by Coverity: CID 1398651

Signed-off-by: Bandan Das <bsd@redhat.com>
Message-id: 20190306210409.14842-2-bsd@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/usb/dev-mtp.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 4ee4fc5a893a..4dde14fc7887 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -1591,14 +1591,18 @@ done:
         return ret;
 }
 
-static void usb_mtp_update_object(MTPObject *parent, char *name)
+static int usb_mtp_update_object(MTPObject *parent, char *name)
 {
+    int ret = -1;
+
     MTPObject *o =
         usb_mtp_object_lookup_name(parent, name, strlen(name));
 
     if (o) {
-        lstat(o->path, &o->stat);
+        ret = lstat(o->path, &o->stat);
     }
+
+    return ret;
 }
 
 static void usb_mtp_write_data(MTPState *s)
@@ -1655,13 +1659,18 @@ static void usb_mtp_write_data(MTPState *s)
         if (d->write_status != WRITE_END) {
             return;
         } else {
-            /* Only for < 4G file sizes */
-            if (s->dataset.size != 0xFFFFFFFF && d->offset != s->dataset.size) {
+            /*
+             * Return an incomplete transfer if file size doesn't match
+             * for < 4G file or if lstat fails which will result in an incorrect
+             * file size
+             */
+            if ((s->dataset.size != 0xFFFFFFFF &&
+                 d->offset != s->dataset.size) ||
+                usb_mtp_update_object(parent, s->dataset.filename)) {
                 usb_mtp_queue_result(s, RES_INCOMPLETE_TRANSFER, d->trans,
                                      0, 0, 0, 0);
                 goto done;
             }
-            usb_mtp_update_object(parent, s->dataset.filename);
         }
     }
 
-- 
2.18.1

[Qemu-devel] [PULL 2/4] usb-mtp: fix some usb_mtp_write_data return paths

[Gerd Hoffmann]

From: Bandan Das <bsd@redhat.com>

During a write, free up the "path" before getting more data.
Also, while we at it, remove the confusing usage of d->fd for
storing mkdir status

Spotted by Coverity: CID 1398642

Signed-off-by: Bandan Das <bsd@redhat.com>
Message-id: 20190306210409.14842-3-bsd@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/usb/dev-mtp.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 4dde14fc7887..1f22284949df 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -1605,7 +1605,7 @@ static int usb_mtp_update_object(MTPObject *parent, char *name)
     return ret;
 }
 
-static void usb_mtp_write_data(MTPState *s)
+static int usb_mtp_write_data(MTPState *s)
 {
     MTPData *d = s->data_out;
     MTPObject *parent =
@@ -1613,6 +1613,7 @@ static void usb_mtp_write_data(MTPState *s)
     char *path = NULL;
     uint64_t rc;
     mode_t mask = 0644;
+    int ret = 0;
 
     assert(d != NULL);
 
@@ -1621,13 +1622,13 @@ static void usb_mtp_write_data(MTPState *s)
         if (!parent || !s->write_pending) {
             usb_mtp_queue_result(s, RES_INVALID_OBJECTINFO, d->trans,
                 0, 0, 0, 0);
-        return;
+        return 1;
         }
 
         if (s->dataset.filename) {
             path = g_strdup_printf("%s/%s", parent->path, s->dataset.filename);
             if (s->dataset.format == FMT_ASSOCIATION) {
-                d->fd = mkdir(path, mask);
+                ret = mkdir(path, mask);
                 goto free;
             }
             d->fd = open(path, O_CREAT | O_WRONLY |
@@ -1657,7 +1658,8 @@ static void usb_mtp_write_data(MTPState *s)
             goto done;
         }
         if (d->write_status != WRITE_END) {
-            return;
+            g_free(path);
+            return ret;
         } else {
             /*
              * Return an incomplete transfer if file size doesn't match
@@ -1685,12 +1687,14 @@ done:
      */
     if (d->fd != -1) {
         close(d->fd);
+        d->fd = -1;
     }
 free:
     g_free(s->dataset.filename);
     s->dataset.size = 0;
     g_free(path);
     s->write_pending = false;
+    return ret;
 }
 
 static void usb_mtp_write_metadata(MTPState *s, uint64_t dlen)
@@ -1727,14 +1731,12 @@ static void usb_mtp_write_metadata(MTPState *s, uint64_t dlen)
     s->write_pending = true;
 
     if (s->dataset.format == FMT_ASSOCIATION) {
-        usb_mtp_write_data(s);
-        /* next_handle will be allocated to the newly created dir */
-        if (d->fd == -1) {
+        if (usb_mtp_write_data(s)) {
+            /* next_handle will be allocated to the newly created dir */
             usb_mtp_queue_result(s, RES_STORE_FULL, d->trans,
                                  0, 0, 0, 0);
             return;
         }
-        d->fd = -1;
     }
 
     usb_mtp_queue_result(s, RES_OK, d->trans, 3, QEMU_STORAGE_ID,
-- 
2.18.1

[Qemu-devel] [PULL 3/4] usb-mtp: prevent null dereference while deleting objects

[Gerd Hoffmann]

From: Bandan Das <bsd@redhat.com>

Spotted by Coverity: CID 1399144

Signed-off-by: Bandan Das <bsd@redhat.com>
Message-id: 20190306210409.14842-4-bsd@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/usb/dev-mtp.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 1f22284949df..06e376bcd211 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -1177,9 +1177,7 @@ static int usb_mtp_deletefn(MTPState *s, MTPObject *o, uint32_t trans)
             usb_mtp_object_free_one(s, o);
             success = true;
         }
-    }
-
-    if (o->format == FMT_ASSOCIATION) {
+    } else if (o->format == FMT_ASSOCIATION) {
         if (rmdir(o->path)) {
             partial_delete = true;
         } else {
-- 
2.18.1

[Qemu-devel] [PULL 4/4] Introduce new "no_guest_reset" parameter for usb-host device

[Gerd Hoffmann]

From: Alexander Kappner <agk@godking.net>

With certain USB devices passed through via usb-host, a guest attempting to
reset a usb-host device can trigger a reset loop that renders the USB device
unusable. In my use case, the device was an iPhone XR that was passed through to
a Mac OS X Mojave guest. Upon connecting the device, the following happens:

1) Guest recognizes new device, sends reset to emulated USB host
2) QEMU's USB host sends reset to host kernel
3) Host kernel resets device
4) After reset, host kernel determines that some part of the device descriptor
has changed ("device firmware changed" in dmesg), so host kernel decides to
re-enumerate the device.
5) Re-enumeration causes QEMU to disconnect and reconnect the device in the
guest.
6) goto 1)

Here's from the host kernel (note the "device firmware changed" lines")

[3677704.473050] usb 1-1.3: new high-speed USB device number 53 using ehci-pci
[3677704.555594] usb 1-1.3: New USB device found, idVendor=05ac, idProduct=12a8, bcdDevice=11.08
[3677704.555599] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[3677704.555602] usb 1-1.3: Product: iPhone
[3677704.555605] usb 1-1.3: Manufacturer: Apple Inc.
[3677704.555607] usb 1-1.3: SerialNumber: [[removed]]
[3677709.401040] usb 1-1.3: reset high-speed USB device number 53 using ehci-pci
[3677709.479486] usb 1-1.3: device firmware changed
[3677709.479842] usb 1-1.3: USB disconnect, device number 53
[3677709.546039] usb 1-1.3: new high-speed USB device number 54 using ehci-pci
[3677709.627471] usb 1-1.3: New USB device found, idVendor=05ac, idProduct=12a8, bcdDevice=11.08
[3677709.627476] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[3677709.627479] usb 1-1.3: Product: iPhone
[3677709.627481] usb 1-1.3: Manufacturer: Apple Inc.
[3677709.627483] usb 1-1.3: SerialNumber: [[removed]]
[3677762.320044] usb 1-1.3: reset high-speed USB device number 54 using ehci-pci
[3677762.615630] usb 1-1.3: USB disconnect, device number 54
[3677762.787043] usb 1-1.3: new high-speed USB device number 55 using ehci-pci
[3677762.869016] usb 1-1.3: New USB device found, idVendor=05ac, idProduct=12a8, bcdDevice=11.08
[3677762.869024] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[3677762.869028] usb 1-1.3: Product: iPhone
[3677762.869032] usb 1-1.3: Manufacturer: Apple Inc.
[3677762.869035] usb 1-1.3: SerialNumber: [[removed]]
[3677815.662036] usb 1-1.3: reset high-speed USB device number 55 using ehci-pci

Here's from QEMU:

libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/005/022: No such file or directory
libusb: error [udev_hotplug_event] ignoring udev action bind
libusb: error [udev_hotplug_event] ignoring udev action bind
libusb: error [_open_sysfs_attr] open /sys/bus/usb/devices/5-1/bConfigurationValue failed ret=-1 errno=2
libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again

libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/005/024: No such file or directory
libusb: error [udev_hotplug_event] ignoring udev action bind
libusb: error [udev_hotplug_event] ignoring udev action bind
libusb: error [_open_sysfs_attr] open /sys/bus/usb/devices/5-1/bConfigurationValue failed ret=-1 errno=2
libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again

libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/005/026: No such file or directory

The result of this is that the device remains permanently unusable in the guest.
The same problem has been previously reported for an iPad:
https://stackoverflow.com/questions/52617634/how-do-i-get-qemu-usb-passthrough-to-work-for-ipad-iphone

This problem can be elegantly solved by interrupting step 2) above. Instead of
passing through the reset, QEMU simply ignores it. To allow this to be
configured on a per-device level,  a new parameter "no_guest_reset" is
introduced for the usb-host device. I can confirm that the configuration
described above (iPhone XS + Mojave guest) works flawlessly with
no_guest_reset=True specified.

Working command line for my scenario:
device_add usb-host,vendorid=0x05ac,productid=0x12a8,no_guest_reset=True,id=iphone

Best regards
Alexander

Signed-off-by: Alexander Kappner <agk@godking.net>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 20190128140027.9448-1-kraxel@redhat.com

[ kraxel: rename parameter to "guest-reset" ]

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/usb/host-libusb.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index 833250a886af..67b7465915f5 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -82,7 +82,7 @@ struct USBHostDevice {
     uint32_t                         options;
     uint32_t                         loglevel;
     bool                             needs_autoscan;
-
+    bool                             allow_guest_reset;
     /* state */
     QTAILQ_ENTRY(USBHostDevice)      next;
     int                              seen, errcount;
@@ -1456,6 +1456,10 @@ static void usb_host_handle_reset(USBDevice *udev)
     USBHostDevice *s = USB_HOST_DEVICE(udev);
     int rc;
 
+    if (!s->allow_guest_reset) {
+        return;
+    }
+
     trace_usb_host_reset(s->bus_num, s->addr);
 
     rc = libusb_reset_device(s->dh);
@@ -1573,6 +1577,7 @@ static Property usb_host_dev_properties[] = {
     DEFINE_PROP_UINT32("productid", USBHostDevice, match.product_id, 0),
     DEFINE_PROP_UINT32("isobufs",  USBHostDevice, iso_urb_count,    4),
     DEFINE_PROP_UINT32("isobsize", USBHostDevice, iso_urb_frames,   32),
+    DEFINE_PROP_BOOL("guest-reset", USBHostDevice, allow_guest_reset, true),
     DEFINE_PROP_UINT32("loglevel",  USBHostDevice, loglevel,
                        LIBUSB_LOG_LEVEL_WARNING),
     DEFINE_PROP_BIT("pipeline",    USBHostDevice, options,
-- 
2.18.1

Re: [Qemu-devel] [PULL 0/4] Usb 20190307 patches

[Peter Maydell]

On Thu, 7 Mar 2019 at 09:56, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> The following changes since commit 32694e98b8d7a246345448a8f707d2e11d6c65e2:
>
>   Merge remote-tracking branch 'remotes/ehabkost/tags/machine-next-pull-request' into staging (2019-03-06 18:52:19 +0000)
>
> are available in the Git repository at:
>
>   git://git.kraxel.org/qemu tags/usb-20190307-pull-request
>
> for you to fetch changes up to ba4c735b4fc74e309ce4b2551d258e442ef513a5:
>
>   Introduce new "no_guest_reset" parameter for usb-host device (2019-03-07 10:03:54 +0100)
>
> ----------------------------------------------------------------
> usb: mtp fixes, guest-reset switch for usb-host.
>
> ----------------------------------------------------------------

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

-- PMM

Re: [Qemu-devel] [PULL 3/4] usb-mtp: prevent null dereference while deleting objects

[Peter Maydell]

On Thu, 7 Mar 2019 at 09:56, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> From: Bandan Das <bsd@redhat.com>
>
> Spotted by Coverity: CID 1399144
>
> Signed-off-by: Bandan Das <bsd@redhat.com>
> Message-id: 20190306210409.14842-4-bsd@redhat.com
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hw/usb/dev-mtp.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
> index 1f22284949df..06e376bcd211 100644
> --- a/hw/usb/dev-mtp.c
> +++ b/hw/usb/dev-mtp.c
> @@ -1177,9 +1177,7 @@ static int usb_mtp_deletefn(MTPState *s, MTPObject *o, uint32_t trans)
>              usb_mtp_object_free_one(s, o);
>              success = true;
>          }
> -    }
> -
> -    if (o->format == FMT_ASSOCIATION) {
> +    } else if (o->format == FMT_ASSOCIATION) {
>          if (rmdir(o->path)) {
>              partial_delete = true;
>          } else {
> --

Hi; following this change Coverity now complains (CID 1399414)
about dead code later in the file:

In this set of if/else clauses, either we
set partial_delete to true, or we set success to
true, but never both:

    if (o->format == FMT_UNDEFINED_OBJECT) {
        if (remove(o->path)) {
            partial_delete = true;
        } else {
            usb_mtp_object_free_one(s, o);
            success = true;
        }
    } else if (o->format == FMT_ASSOCIATION) {
        if (rmdir(o->path)) {
            partial_delete = true;
        } else {
            usb_mtp_object_free_one(s, o);
            success = true;
        }
    }

and so here:

    if (success && partial_delete) {
        return PARTIAL_DELETE;
    }

the condition can never be true and the code inside
the if () {} is dead.

When is the routine intended to return the PARTIAL_DELETE
return value ?

thanks
-- PMM

Re: [Qemu-devel] [PULL 2/4] usb-mtp: fix some usb_mtp_write_data return paths

[Peter Maydell]

On Thu, 7 Mar 2019 at 09:58, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> From: Bandan Das <bsd@redhat.com>
>
> During a write, free up the "path" before getting more data.
> Also, while we at it, remove the confusing usage of d->fd for
> storing mkdir status
>
> Spotted by Coverity: CID 1398642
>
> Signed-off-by: Bandan Das <bsd@redhat.com>
> Message-id: 20190306210409.14842-3-bsd@redhat.com
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

Hi; Coverity found an issue with the code change here
(CID 1399415):

> index 4dde14fc7887..1f22284949df 100644
> --- a/hw/usb/dev-mtp.c
> +++ b/hw/usb/dev-mtp.c
> @@ -1605,7 +1605,7 @@ static int usb_mtp_update_object(MTPObject *parent, char *name)
>      return ret;
>  }
>
> -static void usb_mtp_write_data(MTPState *s)
> +static int usb_mtp_write_data(MTPState *s)

Here we change usb_mtp_write_data() to return an error code...

>  {
>      MTPData *d = s->data_out;
>      MTPObject *parent =

> @@ -1727,14 +1731,12 @@ static void usb_mtp_write_metadata(MTPState *s, uint64_t dlen)
>      s->write_pending = true;
>
>      if (s->dataset.format == FMT_ASSOCIATION) {
> -        usb_mtp_write_data(s);
> -        /* next_handle will be allocated to the newly created dir */
> -        if (d->fd == -1) {
> +        if (usb_mtp_write_data(s)) {
> +            /* next_handle will be allocated to the newly created dir */
>              usb_mtp_queue_result(s, RES_STORE_FULL, d->trans,
>                                   0, 0, 0, 0);
>              return;

...and we updated this callsite to check the error return value.

But the two places in usb_mtp_get_data() that call
usb_mtp_write_metadata() still don't check its return
value: don't they need to handle failure too?

thanks
-- PMM

Re: [Qemu-devel] [PULL 2/4] usb-mtp: fix some usb_mtp_write_data return paths

[Bandan Das]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Thu, 7 Mar 2019 at 09:58, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>
>> From: Bandan Das <bsd@redhat.com>
>>
>> During a write, free up the "path" before getting more data.
>> Also, while we at it, remove the confusing usage of d->fd for
>> storing mkdir status
>>
>> Spotted by Coverity: CID 1398642
>>
>> Signed-off-by: Bandan Das <bsd@redhat.com>
>> Message-id: 20190306210409.14842-3-bsd@redhat.com
>> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>
> Hi; Coverity found an issue with the code change here
> (CID 1399415):
>
>> index 4dde14fc7887..1f22284949df 100644
>> --- a/hw/usb/dev-mtp.c
>> +++ b/hw/usb/dev-mtp.c
>> @@ -1605,7 +1605,7 @@ static int usb_mtp_update_object(MTPObject *parent, char *name)
>>      return ret;
>>  }
>>
>> -static void usb_mtp_write_data(MTPState *s)
>> +static int usb_mtp_write_data(MTPState *s)
>
> Here we change usb_mtp_write_data() to return an error code...
>
>>  {
>>      MTPData *d = s->data_out;
>>      MTPObject *parent =
>
>> @@ -1727,14 +1731,12 @@ static void usb_mtp_write_metadata(MTPState *s, uint64_t dlen)
>>      s->write_pending = true;
>>
>>      if (s->dataset.format == FMT_ASSOCIATION) {
>> -        usb_mtp_write_data(s);
>> -        /* next_handle will be allocated to the newly created dir */
>> -        if (d->fd == -1) {
>> +        if (usb_mtp_write_data(s)) {
>> +            /* next_handle will be allocated to the newly created dir */
>>              usb_mtp_queue_result(s, RES_STORE_FULL, d->trans,
>>                                   0, 0, 0, 0);
>>              return;
>
> ...and we updated this callsite to check the error return value.
>
> But the two places in usb_mtp_get_data() that call
> usb_mtp_write_metadata() still don't check its return
> value: don't they need to handle failure too?
>
I believe this is ok because:
The return value of usb_mtp_write_data is only used to check if mkdir
failed and update s->result in usb_mtp_write_metadata().
The next time usb_mtp_handle_data is called, it will process s->result. 

Bandan

> thanks
> -- PMM

Re: [Qemu-devel] [PULL 3/4] usb-mtp: prevent null dereference while deleting objects

[Bandan Das]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Thu, 7 Mar 2019 at 09:56, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>
>> From: Bandan Das <bsd@redhat.com>
>>
>> Spotted by Coverity: CID 1399144
>>
>> Signed-off-by: Bandan Das <bsd@redhat.com>
>> Message-id: 20190306210409.14842-4-bsd@redhat.com
>> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>> ---
>>  hw/usb/dev-mtp.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
>> index 1f22284949df..06e376bcd211 100644
>> --- a/hw/usb/dev-mtp.c
>> +++ b/hw/usb/dev-mtp.c
>> @@ -1177,9 +1177,7 @@ static int usb_mtp_deletefn(MTPState *s, MTPObject *o, uint32_t trans)
>>              usb_mtp_object_free_one(s, o);
>>              success = true;
>>          }
>> -    }
>> -
>> -    if (o->format == FMT_ASSOCIATION) {
>> +    } else if (o->format == FMT_ASSOCIATION) {
>>          if (rmdir(o->path)) {
>>              partial_delete = true;
>>          } else {
>> --
>
> Hi; following this change Coverity now complains (CID 1399414)
> about dead code later in the file:
>
> In this set of if/else clauses, either we
> set partial_delete to true, or we set success to
> true, but never both:
>
>     if (o->format == FMT_UNDEFINED_OBJECT) {
>         if (remove(o->path)) {
>             partial_delete = true;
>         } else {
>             usb_mtp_object_free_one(s, o);
>             success = true;
>         }
>     } else if (o->format == FMT_ASSOCIATION) {
>         if (rmdir(o->path)) {
>             partial_delete = true;
>         } else {
>             usb_mtp_object_free_one(s, o);
>             success = true;
>         }
>     }
>
> and so here:
>
>     if (success && partial_delete) {
>         return PARTIAL_DELETE;
>     }
>
> the condition can never be true and the code inside
> the if () {} is dead.
>
> When is the routine intended to return the PARTIAL_DELETE
> return value ?
>

This is very broken! I think something like this should work:
diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 06e376bcd2..87a4bfb415 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -1138,8 +1138,8 @@ static MTPData *usb_mtp_get_object_prop_value(MTPState *s, MTPControl *c,
 /* Return correct return code for a delete event */
 enum {
     ALL_DELETE,
-    PARTIAL_DELETE,
     READ_ONLY,
+    PARTIAL_DELETE,
 };
 
 /* Assumes that children, if any, have been already freed */
@@ -1155,8 +1155,7 @@ static void usb_mtp_object_free_one(MTPState *s, MTPObject *o)
 static int usb_mtp_deletefn(MTPState *s, MTPObject *o, uint32_t trans)
 {
     MTPObject *iter, *iter2;
-    bool partial_delete = false;
-    bool success = false;
+    int ret = 0;
 
     /*
      * TODO: Add support for Protection Status
@@ -1165,34 +1164,28 @@ static int usb_mtp_deletefn(MTPState *s, MTPObject *o, uint32_t trans)
     QLIST_FOREACH(iter, &o->children, list) {
         if (iter->format == FMT_ASSOCIATION) {
             QLIST_FOREACH(iter2, &iter->children, list) {
-                usb_mtp_deletefn(s, iter2, trans);
+                ret |= usb_mtp_deletefn(s, iter2, trans);
             }
         }
     }
 
     if (o->format == FMT_UNDEFINED_OBJECT) {
         if (remove(o->path)) {
-            partial_delete = true;
+            ret |= READ_ONLY;
         } else {
             usb_mtp_object_free_one(s, o);
-            success = true;
+            ret |= ALL_DELETE;
         }
     } else if (o->format == FMT_ASSOCIATION) {
         if (rmdir(o->path)) {
-            partial_delete = true;
+            ret |= READ_ONLY;
         } else {
             usb_mtp_object_free_one(s, o);
-            success = true;
+            ret |= ALL_DELETE;
         }
     }
 
-    if (success && partial_delete) {
-        return PARTIAL_DELETE;
-    }
-    if (!success && partial_delete) {
-        return READ_ONLY;
-    }
-    return ALL_DELETE;
+    return ret;
 }
 
 static void usb_mtp_object_delete(MTPState *s, uint32_t handle,

I will test this and send a patch...

Bandan

> thanks
> -- PMM

[Qemu-devel] [PATCH] usb-mtp: fix return status of delete

[Bandan Das]

Spotted by Coverity: CID 1399414

mtp delete allows the a return status of delete succeeded,
partial_delete or readonly - when none of the objects could be
deleted.

Some initiators recurse over the objects themselves. In that case,
only READ_ONLY can be returned.

Signed-off-by: Bandan Das <bsd@redhat.com>
---
 hw/usb/dev-mtp.c | 25 +++++++++----------------
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 06e376bcd2..e3401aad75 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -1137,9 +1137,9 @@ static MTPData *usb_mtp_get_object_prop_value(MTPState *s, MTPControl *c,
 
 /* Return correct return code for a delete event */
 enum {
-    ALL_DELETE,
-    PARTIAL_DELETE,
+    ALL_DELETE = 1,
     READ_ONLY,
+    PARTIAL_DELETE,
 };
 
 /* Assumes that children, if any, have been already freed */
@@ -1155,8 +1155,7 @@ static void usb_mtp_object_free_one(MTPState *s, MTPObject *o)
 static int usb_mtp_deletefn(MTPState *s, MTPObject *o, uint32_t trans)
 {
     MTPObject *iter, *iter2;
-    bool partial_delete = false;
-    bool success = false;
+    int ret = 0;
 
     /*
      * TODO: Add support for Protection Status
@@ -1165,34 +1164,28 @@ static int usb_mtp_deletefn(MTPState *s, MTPObject *o, uint32_t trans)
     QLIST_FOREACH(iter, &o->children, list) {
         if (iter->format == FMT_ASSOCIATION) {
             QLIST_FOREACH(iter2, &iter->children, list) {
-                usb_mtp_deletefn(s, iter2, trans);
+                ret |= usb_mtp_deletefn(s, iter2, trans);
             }
         }
     }
 
     if (o->format == FMT_UNDEFINED_OBJECT) {
         if (remove(o->path)) {
-            partial_delete = true;
+            ret |= READ_ONLY;
         } else {
             usb_mtp_object_free_one(s, o);
-            success = true;
+            ret |= ALL_DELETE;
         }
     } else if (o->format == FMT_ASSOCIATION) {
         if (rmdir(o->path)) {
-            partial_delete = true;
+            ret |= READ_ONLY;
         } else {
             usb_mtp_object_free_one(s, o);
-            success = true;
+            ret |= ALL_DELETE;
         }
     }
 
-    if (success && partial_delete) {
-        return PARTIAL_DELETE;
-    }
-    if (!success && partial_delete) {
-        return READ_ONLY;
-    }
-    return ALL_DELETE;
+    return ret;
 }
 
 static void usb_mtp_object_delete(MTPState *s, uint32_t handle,
-- 
2.19.2

Re: [Qemu-devel] [PULL 3/4] usb-mtp: prevent null dereference while deleting objects

[Peter Maydell]

On Fri, 8 Mar 2019 at 19:46, Bandan Das <bsd@redhat.com> wrote:
> This is very broken! I think something like this should work:
> diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
> index 06e376bcd2..87a4bfb415 100644
> --- a/hw/usb/dev-mtp.c
> +++ b/hw/usb/dev-mtp.c
> @@ -1138,8 +1138,8 @@ static MTPData *usb_mtp_get_object_prop_value(MTPState *s, MTPControl *c,
>  /* Return correct return code for a delete event */
>  enum {
>      ALL_DELETE,
> -    PARTIAL_DELETE,
>      READ_ONLY,
> +    PARTIAL_DELETE,
>  };

This is defining these values as an incrementing series...


>      if (o->format == FMT_UNDEFINED_OBJECT) {
>          if (remove(o->path)) {
> -            partial_delete = true;
> +            ret |= READ_ONLY;
>          } else {
>              usb_mtp_object_free_one(s, o);
> -            success = true;
> +            ret |= ALL_DELETE;

...but here we're using them as bits which we OR together.
In particular ALL_DELETE is 0, so ORing it in will
do nothing.

thanks
-- PMM

Re: [Qemu-devel] [PATCH] usb-mtp: fix return status of delete

[Peter Maydell]

On Fri, 8 Mar 2019 at 22:14, Bandan Das <bsd@redhat.com> wrote:
>
>
> Spotted by Coverity: CID 1399414
>
> mtp delete allows the a return status of delete succeeded,
> partial_delete or readonly - when none of the objects could be
> deleted.
>
> Some initiators recurse over the objects themselves. In that case,
> only READ_ONLY can be returned.
>
> Signed-off-by: Bandan Das <bsd@redhat.com>
> ---
>  hw/usb/dev-mtp.c | 25 +++++++++----------------
>  1 file changed, 9 insertions(+), 16 deletions(-)
>
> diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
> index 06e376bcd2..e3401aad75 100644
> --- a/hw/usb/dev-mtp.c
> +++ b/hw/usb/dev-mtp.c
> @@ -1137,9 +1137,9 @@ static MTPData *usb_mtp_get_object_prop_value(MTPState *s, MTPControl *c,
>
>  /* Return correct return code for a delete event */
>  enum {
> -    ALL_DELETE,
> -    PARTIAL_DELETE,
> +    ALL_DELETE = 1,
>      READ_ONLY,
> +    PARTIAL_DELETE,

This is an enum, ie a set of incrementing values, but you're
using them as bit positions you're ORing together. If they're
really bit flags you should define them properly that way,
so it's clear what you're doing.

At the moment PARTIAL_DELETE is "ALL_DELETE | READ_ONLY", which
doesn't seem like it makes much sense.

thanks
-- PMM

Re: [Qemu-devel] [PATCH] usb-mtp: fix return status of delete

[Bandan Das]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 8 Mar 2019 at 22:14, Bandan Das <bsd@redhat.com> wrote:
>>
>>
>> Spotted by Coverity: CID 1399414
>>
>> mtp delete allows the a return status of delete succeeded,
>> partial_delete or readonly - when none of the objects could be
>> deleted.
>>
>> Some initiators recurse over the objects themselves. In that case,
>> only READ_ONLY can be returned.
>>
>> Signed-off-by: Bandan Das <bsd@redhat.com>
>> ---
>>  hw/usb/dev-mtp.c | 25 +++++++++----------------
>>  1 file changed, 9 insertions(+), 16 deletions(-)
>>
>> diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
>> index 06e376bcd2..e3401aad75 100644
>> --- a/hw/usb/dev-mtp.c
>> +++ b/hw/usb/dev-mtp.c
>> @@ -1137,9 +1137,9 @@ static MTPData *usb_mtp_get_object_prop_value(MTPState *s, MTPControl *c,
>>
>>  /* Return correct return code for a delete event */
>>  enum {
>> -    ALL_DELETE,
>> -    PARTIAL_DELETE,
>> +    ALL_DELETE = 1,
>>      READ_ONLY,
>> +    PARTIAL_DELETE,
>
> This is an enum, ie a set of incrementing values, but you're
> using them as bit positions you're ORing together. If they're
> really bit flags you should define them properly that way,
> so it's clear what you're doing.
>
Sure, no problem

> At the moment PARTIAL_DELETE is "ALL_DELETE | READ_ONLY", which
> doesn't seem like it makes much sense.
>

Sorry, can you please clarify what doesn't make sense ?

> thanks
> -- PMM

Re: [Qemu-devel] [PATCH] usb-mtp: fix return status of delete

[Peter Maydell]

On Mon, 11 Mar 2019 at 16:14, Bandan Das <bsd@redhat.com> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
> > At the moment PARTIAL_DELETE is "ALL_DELETE | READ_ONLY", which
> > doesn't seem like it makes much sense.
> >
>
> Sorry, can you please clarify what doesn't make sense ?

Generally, if you have multiple bits X, Y in a return
value, they should be independent. Sometimes we define
a convenience value Z that's X | Y, but then Z should
have a name that indicates that it's really doing both
X and Y (for instance often a READWRITE constant will
be READ | WRITE). In this case, I don't see why
PARTIAL_DELETE would be a sensible name to indicate
"both ALL_DELETE and also READ_ONLY" -- if we only
partially did a delete why do we set the ALL_DELETE bit ?

It might be useful to take a step back -- what are
the different possible outcomes from this function that
we need to distinguish, and when should we be returning
which outcome?

thanks
-- PMM

Re: [Qemu-devel] [PATCH] usb-mtp: fix return status of delete

[Bandan Das]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Mon, 11 Mar 2019 at 16:14, Bandan Das <bsd@redhat.com> wrote:
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>> > At the moment PARTIAL_DELETE is "ALL_DELETE | READ_ONLY", which
>> > doesn't seem like it makes much sense.
>> >
>>
>> Sorry, can you please clarify what doesn't make sense ?
>
> Generally, if you have multiple bits X, Y in a return
> value, they should be independent. Sometimes we define
> a convenience value Z that's X | Y, but then Z should
> have a name that indicates that it's really doing both
> X and Y (for instance often a READWRITE constant will
> be READ | WRITE). In this case, I don't see why
> PARTIAL_DELETE would be a sensible name to indicate
> "both ALL_DELETE and also READ_ONLY" -- if we only
> partially did a delete why do we set the ALL_DELETE bit ?
>

Because during a recursive call, we were able to successfully
delete objects(s) for the previous call but for "this"
set of objects, it failed which is supposed to return a
partial_delete back.

Does simply "DELETE" instead of "ALL_DELETE" seem less
confusing ? I definitely want to keep PARTIAL_DELETE the
way it is simply because it's easier to refer back
to the spec that way.

> It might be useful to take a step back -- what are
> the different possible outcomes from this function that
> we need to distinguish, and when should we be returning
> which outcome?
>
> thanks
> -- PMM

Re: [Qemu-devel] [PATCH] usb-mtp: fix return status of delete

[Peter Maydell]

On Mon, 11 Mar 2019 at 16:43, Bandan Das <bsd@redhat.com> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> > On Mon, 11 Mar 2019 at 16:14, Bandan Das <bsd@redhat.com> wrote:
> > Generally, if you have multiple bits X, Y in a return
> > value, they should be independent. Sometimes we define
> > a convenience value Z that's X | Y, but then Z should
> > have a name that indicates that it's really doing both
> > X and Y (for instance often a READWRITE constant will
> > be READ | WRITE). In this case, I don't see why
> > PARTIAL_DELETE would be a sensible name to indicate
> > "both ALL_DELETE and also READ_ONLY" -- if we only
> > partially did a delete why do we set the ALL_DELETE bit ?
> >
>
> Because during a recursive call, we were able to successfully
> delete objects(s) for the previous call but for "this"
> set of objects, it failed which is supposed to return a
> partial_delete back.
>
> Does simply "DELETE" instead of "ALL_DELETE" seem less
> confusing ? I definitely want to keep PARTIAL_DELETE the
> way it is simply because it's easier to refer back
> to the spec that way.

I think this would be easier to answer if you answered
this question:

> > It might be useful to take a step back -- what are
> > the different possible outcomes from this function that
> > we need to distinguish, and when should we be returning
> > which outcome?

thanks
-- PMM

Re: [Qemu-devel] [PATCH] usb-mtp: fix return status of delete

[Bandan Das]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Mon, 11 Mar 2019 at 16:43, Bandan Das <bsd@redhat.com> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>> > On Mon, 11 Mar 2019 at 16:14, Bandan Das <bsd@redhat.com> wrote:
>> > Generally, if you have multiple bits X, Y in a return
>> > value, they should be independent. Sometimes we define
>> > a convenience value Z that's X | Y, but then Z should
>> > have a name that indicates that it's really doing both
>> > X and Y (for instance often a READWRITE constant will
>> > be READ | WRITE). In this case, I don't see why
>> > PARTIAL_DELETE would be a sensible name to indicate
>> > "both ALL_DELETE and also READ_ONLY" -- if we only
>> > partially did a delete why do we set the ALL_DELETE bit ?
>> >
>>
>> Because during a recursive call, we were able to successfully
>> delete objects(s) for the previous call but for "this"
>> set of objects, it failed which is supposed to return a
>> partial_delete back.
>>
>> Does simply "DELETE" instead of "ALL_DELETE" seem less
>> confusing ? I definitely want to keep PARTIAL_DELETE the
>> way it is simply because it's easier to refer back
>> to the spec that way.
>
> I think this would be easier to answer if you answered
> this question:
>
>> > It might be useful to take a step back -- what are
>> > the different possible outcomes from this function that
>> > we need to distinguish, and when should we be returning
>> > which outcome?
>
They are what the variable names signify.

> thanks
> -- PMM

Re: [Qemu-devel] [PATCH] usb-mtp: fix return status of delete

[Peter Maydell]

On Mon, 11 Mar 2019 at 17:39, Bandan Das <bsd@redhat.com> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Mon, 11 Mar 2019 at 16:43, Bandan Das <bsd@redhat.com> wrote:
> >> Peter Maydell <peter.maydell@linaro.org> writes:
> >> > On Mon, 11 Mar 2019 at 16:14, Bandan Das <bsd@redhat.com> wrote:
> >> > Generally, if you have multiple bits X, Y in a return
> >> > value, they should be independent. Sometimes we define
> >> > a convenience value Z that's X | Y, but then Z should
> >> > have a name that indicates that it's really doing both
> >> > X and Y (for instance often a READWRITE constant will
> >> > be READ | WRITE). In this case, I don't see why
> >> > PARTIAL_DELETE would be a sensible name to indicate
> >> > "both ALL_DELETE and also READ_ONLY" -- if we only
> >> > partially did a delete why do we set the ALL_DELETE bit ?
> >> >
> >>
> >> Because during a recursive call, we were able to successfully
> >> delete objects(s) for the previous call but for "this"
> >> set of objects, it failed which is supposed to return a
> >> partial_delete back.
> >>
> >> Does simply "DELETE" instead of "ALL_DELETE" seem less
> >> confusing ? I definitely want to keep PARTIAL_DELETE the
> >> way it is simply because it's easier to refer back
> >> to the spec that way.
> >
> > I think this would be easier to answer if you answered
> > this question:
> >
> >> > It might be useful to take a step back -- what are
> >> > the different possible outcomes from this function that
> >> > we need to distinguish, and when should we be returning
> >> > which outcome?
> >
> They are what the variable names signify.

That doesn't get me any further forward, I'm afraid.

Looking at the code, we seem to have:
 * for any particular node, either we can delete it
   or we can't
 * we also iterate through each child node recursively

So we have to combine together the "deleted this"
and "failed to delete this" information for the whole tree.
In which conditions should we end up with which RES_*
result code? It seems plausible that we want RES_OK
only if every deletion attempt in the tree succeeded.
But what about the others? Is it supposed to be
RES_PARTIAL_DELETE if some deletions succeeded and
some failed, and RES_STORE_READ_ONLY if every single
deletion failed ?

thanks
-- PMM

Re: [Qemu-devel] [PATCH] usb-mtp: fix return status of delete

[Bandan Das]

Peter Maydell <peter.maydell@linaro.org> writes:
...
>> >
>> >> > It might be useful to take a step back -- what are
>> >> > the different possible outcomes from this function that
>> >> > we need to distinguish, and when should we be returning
>> >> > which outcome?
>> >
>> They are what the variable names signify.
>
> That doesn't get me any further forward, I'm afraid.
>
> Looking at the code, we seem to have:
>  * for any particular node, either we can delete it
>    or we can't
>  * we also iterate through each child node recursively
>
> So we have to combine together the "deleted this"
> and "failed to delete this" information for the whole tree.
> In which conditions should we end up with which RES_*
> result code? It seems plausible that we want RES_OK
> only if every deletion attempt in the tree succeeded.
> But what about the others? Is it supposed to be
> RES_PARTIAL_DELETE if some deletions succeeded and
> some failed, and RES_STORE_READ_ONLY if every single
> deletion failed ?
>
Ok, this is easier. Now, I know what you are referring to
instead of guessing what and how I should be explainng.

What you said is essentially correct. When deleting a
single object that's a file, the return value would either
be OK or STORE_READ_ONLY.

When deleting an object which is a folder, Qemu goes through
its contents. If it succeeds in deleting all the content objects,
the result is success. If one or some objects couldn't be deleted for
whatever reason, the result is RES_PARTIAL_DELETE and if none
of the objects could be deleted, Qemu returns a READ_ONLY.

In usb_mtp_object_delete(), based on the return value of this
function, we set s->result appropriately.

> thanks
> -- PMM

Re: [Qemu-devel] [PATCH] usb-mtp: fix return status of delete

[Peter Maydell]

On Mon, 11 Mar 2019 at 18:11, Bandan Das <bsd@redhat.com> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
> > Looking at the code, we seem to have:
> >  * for any particular node, either we can delete it
> >    or we can't
> >  * we also iterate through each child node recursively
> >
> > So we have to combine together the "deleted this"
> > and "failed to delete this" information for the whole tree.
> > In which conditions should we end up with which RES_*
> > result code? It seems plausible that we want RES_OK
> > only if every deletion attempt in the tree succeeded.
> > But what about the others? Is it supposed to be
> > RES_PARTIAL_DELETE if some deletions succeeded and
> > some failed, and RES_STORE_READ_ONLY if every single
> > deletion failed ?
> >
> Ok, this is easier. Now, I know what you are referring to
> instead of guessing what and how I should be explainng.
>
> What you said is essentially correct. When deleting a
> single object that's a file, the return value would either
> be OK or STORE_READ_ONLY.
>
> When deleting an object which is a folder, Qemu goes through
> its contents. If it succeeds in deleting all the content objects,
> the result is success. If one or some objects couldn't be deleted for
> whatever reason, the result is RES_PARTIAL_DELETE and if none
> of the objects could be deleted, Qemu returns a READ_ONLY.
>
> In usb_mtp_object_delete(), based on the return value of this
> function, we set s->result appropriately.

OK. So we can do this with a return value where the
two relevant bits indicate:
 * bit 0: We had at least one successful deletion
 * bit 1: We had at least one failed deletion

and then the correct RES value is:
 * only bit 0 set: READ_ONLY
 * only bit 1 set: OK
 * both bits set: PARTIAL_DELETE
 * neither bit set: can't happen

This is what your patch does, I think, but you've named
the "at least one deletion succeeded" bit "ALL_DELETE"
(even though it can be set in a return value where not
all of the deletions succeeded) and the "at least one
deletion failed" bit "READ_ONLY" (even though it can
be set in a return value where some deletions succeeded),
which is what I found confusing.

I think the code would be easier to understand if we:
 * picked clearer names for the bits, like
   DELETE_SUCCESS and DELETE_FAILURE
 * had a comment explaining what the return value
   of the function means, something like:

/*
 * Delete the object @o and all its children. In the
 * return value, the DELETE_SUCCESS bit is set if at
 * least one of the deletions succeeded, and the
 * DELETE_FAILURE bit is set if at least one of the
 * deletions failed. If the tree of objects was only
 * partially deleted then both bits will be set.
 */

But really the second of these is the more important:
slightly confusing naming is OK if there is a good
comment explaining what is going on (and my suggested
bit flag names don't really stand on their own without
any explanation either). So if you strongly prefer your names
for the bits that's ok, but please do add a comment,
either at the top of the function or documenting
the meaning of the enum values.

thanks
-- PMM

Re: [Qemu-devel] [PATCH] usb-mtp: fix return status of delete

[Bandan Das]

Peter Maydell <peter.maydell@linaro.org> writes:
...
>> Ok, this is easier. Now, I know what you are referring to
>> instead of guessing what and how I should be explainng.
>>
>> What you said is essentially correct. When deleting a
>> single object that's a file, the return value would either
>> be OK or STORE_READ_ONLY.
>>
>> When deleting an object which is a folder, Qemu goes through
>> its contents. If it succeeds in deleting all the content objects,
>> the result is success. If one or some objects couldn't be deleted for
>> whatever reason, the result is RES_PARTIAL_DELETE and if none
>> of the objects could be deleted, Qemu returns a READ_ONLY.
>>
>> In usb_mtp_object_delete(), based on the return value of this
>> function, we set s->result appropriately.
>
> OK. So we can do this with a return value where the
> two relevant bits indicate:
>  * bit 0: We had at least one successful deletion
>  * bit 1: We had at least one failed deletion
>
> and then the correct RES value is:
>  * only bit 0 set: READ_ONLY
>  * only bit 1 set: OK
>  * both bits set: PARTIAL_DELETE
>  * neither bit set: can't happen
>
> This is what your patch does, I think, but you've named
> the "at least one deletion succeeded" bit "ALL_DELETE"
> (even though it can be set in a return value where not
> all of the deletions succeeded) and the "at least one
> deletion failed" bit "READ_ONLY" (even though it can
> be set in a return value where some deletions succeeded),
> which is what I found confusing.
>
> I think the code would be easier to understand if we:
>  * picked clearer names for the bits, like
>    DELETE_SUCCESS and DELETE_FAILURE
>  * had a comment explaining what the return value
>    of the function means, something like:
>
> /*
>  * Delete the object @o and all its children. In the
>  * return value, the DELETE_SUCCESS bit is set if at
>  * least one of the deletions succeeded, and the
>  * DELETE_FAILURE bit is set if at least one of the
>  * deletions failed. If the tree of objects was only
>  * partially deleted then both bits will be set.
>  */
>
> But really the second of these is the more important:
> slightly confusing naming is OK if there is a good
> comment explaining what is going on (and my suggested
> bit flag names don't really stand on their own without
> any explanation either). So if you strongly prefer your names
> for the bits that's ok, but please do add a comment,
> either at the top of the function or documenting
> the meaning of the enum values.
>
Peter, thank you for the thorough review, I really appreciate it.
I definitely want to make this code less confusing to the next
potential reviewer. I will address all your suggestions in the
next version of the patch.

Bandan

> thanks
> -- PMM