[ovs-dev] [PATCH v2 5/6] datapath-windows: Refactor CreateQueue function to handle vport pid.

[Eitan Eliahu]

We must always grab the lock in the same order.
Thanks,
Eitan

-----Original Message-----
From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Nithin Raju
Sent: Wednesday, October 22, 2014 5:21 PM
To: Ankur Sharma
Cc: <dev at openvswitch.org>
Subject: Re: [ovs-dev] [PATCH v2 5/6] datapath-windows: Refactor CreateQueue function to handle vport pid.

On Oct 21, 2014, at 5:24 PM, Ankur Sharma <ankursharma at vmware.com> wrote:

> Refactored CreateQueue function so that packets are enqueued to correct corresponding queue.
> 
> Signed-off-by: Ankur Sharma <ankursharma at vmware.com>

Looks good mostly. One comment I had was if it was the right thing to use gOvsControlLock. This can lead to a deadlock.

Consider the following sequence:
Context #1 executing OvsDeviceControl() code to do vport add:
1. Acquires gOvsControlLock
2. Acquires dispatch lock

Context #2 executing packet processing code:
1. Acquires dispatch lock
2. Acquires gOvsControlLock for enqueueing packets

We should add a separate lock for PID, and not use the gOvsControlLock.

> @@ -932,6 +943,10 @@ OvsGetPid(POVS_VPORT_ENTRY vport, PNET_BUFFER nb, 
> UINT32 *pid) {
>     UNREFERENCED_PARAMETER(nb);
> 
> +    if (!vport) {
> +        return STATUS_INVALID_PARAMETER;
> +    }

The existing code already checks for vport == NULL before calling OvsGetPid(). We can just ASSERT() here.

thanks,
-- Nithin
_______________________________________________
dev mailing list
dev at openvswitch.org
https://urldefense.proofpoint.com/v1/url?u=http://openvswitch.org/mailman/listinfo/dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yTvML8OxA42Jb6ViHe7fUXbvPVOYDPVq87w43doxtlY%3D%0A&m=kQB9d9OV%2F1d0VQLP1uGwpcGjMNXh1OQMGiUOSMzDekg%3D%0A&s=458415d86f1f9aac09c2b999d37409a88c5c5d467ace09aa25aa31c0c629fc17