Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx):
>>> @@ -1246,9 +1244,7 @@ int restore_mm_obj(struct ckpt_ctx *ctx, int mm_objref)
>>> int ret;
>>>
>>> mm = ckpt_obj_fetch(ctx, mm_objref, CKPT_OBJ_MM);
>>> - if (!mm)
>>> - return -EINVAL;
>>> - else if (IS_ERR(mm))
>>> + if (IS_ERR(mm))
>>> return -EINVAL;
>> ^^^^^^
>> should be: PTR_ERR(mm);
>
> Oops, right.
>
>>> diff --git a/fs/pipe.c b/fs/pipe.c
>>> index ab2de3c..b284dcb 100644
>>> --- a/fs/pipe.c
>>> +++ b/fs/pipe.c
>>> @@ -982,14 +982,12 @@ struct file *pipe_file_restore(struct ckpt_ctx *ctx, struct ckpt_hdr_file *ptr)
>>> return ERR_PTR(-EINVAL);
>>>
>>> file = ckpt_obj_fetch(ctx, h->pipe_objref, CKPT_OBJ_FILE);
>>> - if (IS_ERR(file))
>>> - return file;
>>> /*
>>> - * If ckpt_obj_fetch() returned NULL, then this is the first
>>> + * If ckpt_obj_fetch() returned -EINVAL, then this is the first
>>> * time we see this pipe so need to restore the contents.
>>> * Otherwise, use the file pointer skip forward.
>>> */
>>> - if (!file) {
>>> + if (PTR_ERR(file) == -EINVAL) {
>> ckpt_obj_fetch() will also fail with -EINVAL if the type of the object
>> found doesn't match the type that was requested. Hence why originally
>> the two return values. So I changed that latter to report -ENOMSG (that
>> is: /* No message of desired type */)
>
> Hmm, yes I was thinking of the checkpoint case where mismatched types
> would be strictly an objhash bug. You're right, this case can just
> be a bad checkpoint image!
Actually, there was also a bit of logic change required for uts_ns
and ipc_ns. Fixed that too.
Oren.
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
