On Wed, Dec 14, 2011 at 3:34 PM, Jesse Gross <je...@nicira.com> wrote:
> On Wed, Dec 14, 2011 at 3:07 PM, Pravin Shelar <pshe...@nicira.com> wrote:
>> On Wed, Dec 14, 2011 at 2:47 PM, Ansis Atteka <aatt...@nicira.com> wrote:
>>> On Wed, Dec 14, 2011 at 2:08 PM, Pravin B Shelar <pshe...@nicira.com> wrote:
>>>> +int genl_exec(genl_exec_func_t func, void *data)
>>>> +{
>>>> + struct sk_buff *skb;
>>>> +
>>>> + skb = genlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
>>>> + if (!skb)
>>>> + return -ENOMEM;
>>>> +
>>>> + genlmsg_put(skb, 0, 0, &genl_exec_family, NLM_F_REQUEST,
>>>> GENL_EXEC_RUN);
>>>> +
>>>> + mutex_lock(&genl_exec_lock);
>>>> + genl_exec_function = func;
>>>> + genl_exec_data = data;
>>>> + init_completion(&done);
>>>> + genlmsg_unicast(&init_net, skb, 0);
>>>> + wait_for_completion(&done);
>>>> + genl_exec_function = NULL;
>>>
>>> Shouldn't you prepare here a copy of genl_exec_function_ret before actually
>>> returning it? I sense a small-probability of a race condition here.
>>>>
>> right, I need to do it inside lock. Even with lock it is not
>> completely safe as callback is not taking any lock. But I think that
>> is not issue for now.
>
> Isn't all of this executing synchronously anyways, so the callback
> actually is protected by genl_exec_lock and the completion stuff isn't
> necessary?
Its not same across kernel that we care.
callbacks are executed synchronously from 2.6.24 onward.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
