| Message ID | jpg8sxpypx2.fsf_-_@linux.bootlegged.copy |
|---|---|
| State | New |
| Headers | show |
| Series | usb-mtp: fix return status of delete | expand |
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
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
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
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
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
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
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
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
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
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
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,
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(-)