> -----Original Message----- > From: Dexuan Cui > Sent: Thursday, January 29, 2015 8:21 PM > To: Jason Wang > Cc: Vitaly Kuznetsov; KY Srinivasan; devel@xxxxxxxxxxxxxxxxxxxxxx; Haiyang > Zhang; linux-kernel@xxxxxxxxxxxxxxx; Radim Krčmář; Dan Carpenter > Subject: RE: [PATCH v3 3/3] Drivers: hv: vmbus: serialize Offer and Rescind > offer > > > -----Original Message----- > > From: Jason Wang [mailto:jasowang@xxxxxxxxxx] > > Sent: Thursday, January 29, 2015 18:09 PM > > To: Dexuan Cui > > Cc: Vitaly Kuznetsov; KY Srinivasan; devel@xxxxxxxxxxxxxxxxxxxxxx; > > Haiyang Zhang; linux-kernel@xxxxxxxxxxxxxxx; Radim Krčmář; Dan > > Carpenter > > Subject: RE: [PATCH v3 3/3] Drivers: hv: vmbus: serialize Offer and > > Rescind offer > > > > > > > > On Wed, Jan 28, 2015 at 8:51 PM, Dexuan Cui <decui@xxxxxxxxxxxxx> > wrote: > > >> -----Original Message----- > > >> From: Vitaly Kuznetsov [mailto:vkuznets@xxxxxxxxxx] > > >> Sent: Wednesday, January 28, 2015 20:09 PM > > >> To: Dexuan Cui > > >> Cc: KY Srinivasan; devel@xxxxxxxxxxxxxxxxxxxxxx; Haiyang Zhang; > > >> linux- > > >> kernel@xxxxxxxxxxxxxxx; Jason Wang; Radim Krčmář; Dan Carpenter > > >> Subject: Re: [PATCH v3 3/3] Drivers: hv: vmbus: serialize Offer > > >> and Rescind offer > > >> > > >> Dexuan Cui <decui@xxxxxxxxxxxxx> writes: > > >> > > >> >> -----Original Message----- > > >> >> From: Vitaly Kuznetsov [mailto:vkuznets@xxxxxxxxxx] >> Sent: > > >> Tuesday, January 20, 2015 23:45 PM >> To: KY Srinivasan; > > >> devel@xxxxxxxxxxxxxxxxxxxxxx >> Cc: Haiyang Zhang; > > >> linux-kernel@xxxxxxxxxxxxxxx; Dexuan Cui; Jason Wang; >> Radim > > >> Krčmář; Dan Carpenter >> Subject: [PATCH v3 3/3] Drivers: hv: > > >> vmbus: serialize Offer and Rescind offer ... > > >> > > > >> > Hi Vitaly and all, > > >> > I have 2 questions: > > >> > In vmbus_process_offer(), in the cases of "goto err_free_chan", > > >> > should we consider the possibility a rescind message could be > > >> pending for > the new channel? > > >> > In the cases, because we don't run > > > >> "INIT_WORK(&newchannel->work, vmbus_process_rescind_offer); ", > > > > >> vmbus_onoffer_rescind() will do nothing and as a result, > > > >> vmbus_process_rescind_offer() won't be invoked. > > >> > > >> Yes, but processing the rescind offer results in freeing the > > >> channel (and this processing supposes the channel wasn't freed > > >> before) so there is no difference... or is it? > > >> > > >> > > > >> > Question 2: in vmbus_process_offer(), in the case > > > >> vmbus_device_register() fails, we'll run > > > >> "list_del(&newchannel->listentry);" -- just after this line, > > > >> what will happen at this time if relid2channel() returns NULL > in > > >> vmbus_onoffer_rescind()? > > >> > > > >> > I think we'll lose the rescind message. > > >> > > > >> > > >> Yes, but same logic applies - we already freed the channes so no > > >> rescind proccessing required. > > > free_channel() and vmbus_process_rescind_offer() are different, > > > because the latter does more work, e.g., sending the host a message > > > CHANNELMSG_RELID_RELEASED. > > > > > > In the cases of "goto err_free_chan" + "a pending rescind message", > > > the host may expect the message CHANNELMSG_RELID_RELEASED and > could > > > reoffer the channel once the message is received. > > > > > > It would be better if the VM doesn't lose the rescind message here. > > > :-) > > > > It's interesting that rescind needs a ack from guest. But looks like > > the offer does not need it? Is there a spec for this for us for > > reference? > > My understanding is: > The host may reuse the same relid after the VM acks the rescind message. > > I don't have a VMBus spec either. That is correct. This change was I think introduced recently (requiring the guest to release the RelID). K. Y > > > > > > > > > >> If we still need to do something we need to add support for > > >> already freed channel to the rescind offer processing path. > > >> > This sounds reasonable to me. > Error handling is always full of various corner cases... > > Thanks, > -- Dexuan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
