> -----Original Message----- > From: Olaf Hering [mailto:olaf@xxxxxxxxx] > Sent: Monday, September 21, 2015 5:17 AM > To: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> > Cc: KY Srinivasan <kys@xxxxxxxxxxxxx>; Greg KH > <gregkh@xxxxxxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; > devel@xxxxxxxxxxxxxxxxxxxxxx; apw@xxxxxxxxxxxxx; jasowang@xxxxxxxxxx > Subject: Re: [PATCH 2/5] hv: add helpers to handle hv_util device state > > On Mon, Sep 21, Vitaly Kuznetsov wrote: > > > I'd like to see a trace from the hang, it is not obvious to me how it > > happened and what caused it. (or if you have such hang scenario in your > > head, can you please reveal it?) > > There is no trace. I think fcopy_respond_to_host notifies the host, > which in turn triggers an interrupt right away which is processed while > fcopy_on_msg is executing somewhere between the return from > fcopy_respond_to_host and the call into hv_fcopy_onchannelcallback. > > > AFAICS barriers you introduced don't give you guarantees in an SMP > environment. > > Happens to work on x86, and for this purpose. I will see how to add > locking around access to state and context. All activity starts with the interrupt handler - this is the start of each new transaction. Given that we have only one outstanding transaction at a time we have naturally serialized the operations. If we force all activity onto the correct CPU (the CPU the channel is bound to) (currently we force polling to occur on the correct CPU) we should be fine. Regards, K. Y > > Olaf _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
