[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply()



On 07/07/16 13:23, Jan Beulich wrote:
>>>> On 07.07.16 at 14:17, <david.vrabel@xxxxxxxxxx> wrote:
>> On 07/07/16 13:09, Jan Beulich wrote:
>>>>>> On 07.07.16 at 13:36, <david.vrabel@xxxxxxxxxx> wrote:
>>>> On 07/07/16 08:32, Jan Beulich wrote:
>>>>> We must not skip the transaction_end() call for a failed
>>>>> XS_TRANSACTION_START. The removed code fragment got introduced by
>>>>> commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus
>>>>> stalling shutdown/restart") without its description really indicating
>>>>> why it was added (and hence I can't identify whether a more complex
>>>>> change might be needed here).
>>>>
>>>> If sending the XS_TRANSACTION_END message failed, then the transaction
>>>> is still open and transaction_end() should not be called.
>>>>
>>>> However, if sending an XS_TRANSACTION_START failed, then
>>>> transaction_end() should be called.
>>>>
>>>> So, yes a more complex fix is needed here.
>>>
>>> Well, both of the things you name are what happens with the patch
>>> in place. So if those two conditions are all that needs to be satisfied,
>>> then no more complex change is needed afaict (and was the behavior
>>> before the cross referenced commit) - the question really is whether
>>> that other commit meant to deal with something _beyond_ those two
>>> things.
>>
>> You call transaction_end() if msg->type == XS_TRANSACTION_END, even if
>> xb_write() returned an error.
> 
> When xb_write() returns an error, msg->type gets set to XS_ERROR.

So?

        if ((msg->type == XS_TRANSACTION_END) ||
            (...))
                transaction_end();

We don't check msg->type for XS_TRANSACTION_END messages.

David

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.