> On May 25, 2015, at 11:50 PM, Nithin Raju <nit...@vmware.com> wrote: > > > hi Sorin, > This patch looks much better. Like I mentioned the review to the previous > revision, a duplicate vport delete request for the same VXLAN port can mess > things up, including accessing a freed up ‘vport’ structure. But, that is a > corner case, and we can address it later. > > I just found a new issue in OvsTunnelVportPendingUninit() where you are not > taking the vport lock (switchContext->dispatchLock). Looks good otherwise. > >> +static VOID >> +OvsTunnelVportPendingUninit(PVOID context, >> + NTSTATUS status, >> + UINT32 *replyLen) > > You are not taking the switchContext->dispatchLock while deleting from the > hash tables. > > I should be able to ACK the next revision.
BTW, please test the whole patch out by adding some artificial delays (upto 5s) in the WFP worker process to make sure that race conditions are simulated. I believe that the previous issues we identified with accessing a stale vport structure were not hit in your testing because the WFP thread was so fast, and it finished before the OVS thread could go int waiting state. -- Nithin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
