Serge E. Hallyn wrote:
> Quoting Oren Laadan (or...@cs.columbia.edu):
>>
>> Serge E. Hallyn wrote:
>>> Quoting Oren Laadan (or...@cs.columbia.edu):
>>>> --- a/checkpoint/Makefile
>>>> +++ b/checkpoint/Makefile
>>>> @@ -2,8 +2,8 @@
>>>> # Makefile for linux checkpoint/restart.
>>>> #
>>>>
>>>> -obj-$(CONFIG_CHECKPOINT) += sys.o objhash.o \
>>>> +obj-$(CONFIG_CHECKPOINT) += sys.o objhash.o deferqueue.o \
>>>> checkpoint.o restart.o \
>>>> ckpt_task.o rstr_task.o \
>>>> ckpt_mem.o rstr_mem.o \
>>>> - ckpt_file.o rstr_file.o
>>>> + ckpt_file.o rstr_file.o \
>>> ?
>>>
>>>> +int cr_deferqueue_add(struct cr_ctx *ctx, cr_deferqueue_func_t function,
>>>> + unsigned int flags, void *data, int size)
>>>> +{
>>>> + struct cr_deferqueue *wq;
>>>> +
>>>> + wq = kmalloc(sizeof(wq) + size, GFP_KERNEL);
>>>> + if (!wq)
>>>> + return -ENOMEM;
>>>> +
>>>> + wq->function = function;
>>>> + wq->flags = flags;
>>>> + memcpy(wq->data, data, size);
>>>> +
>>>> + cr_debug("adding work %p function %p\n", wq, wq->function);
>>>> + list_add_tail(&ctx->deferqueue, &wq->list);
>>>> + return 0;
>>>> +}
>>> Shouldn't the deferqueue be protected by a spinlock here?
>> Not until we implement concurrent checkpoint/restart. At the moment
>> it's one task at a time the can access it.
>
> That's too bad. I think this woudl be better done as a single
> simple patch addin ga new generic deferqueue mechanism for all
> to use, with a per-queue spinlock protecting both _add and
> _run
Fair enough. Would you like to take a stab at it ?
Oren.
_______________________________________________
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
