Re: [Xen-devel] [PATCH v4 00/12] xenstore: support reading directory with many children

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 06/12/16 06:30, Juergen Gross wrote:
> On 05/12/16 19:19, Andrew Cooper wrote:
>> On 05/12/16 12:05, Wei Liu wrote:
>>> On Mon, Dec 05, 2016 at 08:48:41AM +0100, Juergen Gross wrote:
>>> [...]
>>>> Juergen Gross (12):
>>>>   xenstore: modify add_change_node() parameter types
>>>>   xenstore: call add_change_node() directly when writing node
>>>>   xenstore: use common tdb record header in xenstore
>>>>   xenstore: add per-node generation counter
>>>>   xenstore: add support for reading directory with many children
>>>>   xenstore: support XS_DIRECTORY_PART in libxenstore
>>>>   xenstore: use array for xenstore wire command handling
>>>>   xenstore: let command functions return error or success
>>>>   xenstore: make functions static
>>>>   xenstore: add helper functions for wire argument parsing
>>>>   xenstore: add small default data buffer to internal struct
>>>>   xenstore: handle memory allocation failures in xenstored
>>>>
>>> Applied to staging.
>> XenServer's Coverity has run, and has a few things to say.  Its not
>> obvious (i.e. I can't trivially identify) if these are preexisting bugs
>> which your code has brought to light, or introduced by your series.
>>
>> Both do_rm() and do_mkdir() suffer from the same problem.
>>
>> onearg(in) may return NULL, which results in get_node_canonicalized()
>> setting name to NULL and returning NULL.  name is then dereferenced in
>> the error path by get_parent()/create_node() respectively.
> No. errno will be EINVAL and this will prohibit to enter the said paths
> guarded by errno == ENOENT.

It looks like Coverity is finding reason to presume that errno == ENOENT
on the bad path.

I think this is because it cant conclude whether setting name to NULL is
strictly equivalent to setting errno to ENOENT or not, and errs on the
side of assuming not.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel