[libvirt] [PATCH v3 3/6] virStream*All: Call virStreamAbort() more frequently

Michal Privoznik mprivozn at redhat.com
Tue Jun 13 11:31:31 UTC 2017


On 06/13/2017 12:45 AM, John Ferlan wrote:
> 
> 
> On 06/05/2017 04:22 AM, Michal Privoznik wrote:
>> Our documentation to all four virStreamRecvAll, virStreamSendAll,
> 
> s/all four/the/
> 
>> virStreamSparseRecvAll, virStreamSparseSendAll says that if these
> 
> s/RecvAll, virStream/RecvAll, and virStream/
> 
> s/says that if these functions fail,/functions indicates that on failure/
> 
>> functions fail, virStreamAbort() is called. But that is not
>> necessarily true. For instance all of these functions allocate a
>> buffer to work with. If the allocation fails, no virStreamAbort()
>> is called despite -1 being returned. It's the same story with
>> argument sanity checks and a lot of other checks.
>>
>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>> ---
>>  src/libvirt-stream.c | 49 ++++++++++++++++++++-----------------------------
>>  1 file changed, 20 insertions(+), 29 deletions(-)
>>
> 
> This patch particularly scares me because there are so many more paths
> that could now call virStreamAbort. Yes, I know that's the point

Exactly :-)

> , but
> nonetheless it's large leap of faith to only calling Abort as a result
> of some Send/Recv callback failure to calling Abort for the ancillary
> stuff surrounding or supporting those calls as well.

Why is that? The documentation to this function says that if this
function fails, virStreamAbort has been called. So in fact currently
this function might fail without calling virStreamAbort.

> 
> Would there be a chance of multiple callers to virStreamAbort?

Not over the same stream. The server side doesn't use these
SendAll/RecvAll wrappers. They are for client only. And as such client
is responsible for not calling them from two separate threads at the
same time.

> 
> It'd be nice if there were any other opinions on this. I'd lean towards
> saying looks good, but I'm also interested if there's any other opposing
> opinions or concerns.
> 
> John

Michal




More information about the libvir-list mailing list