"Serge E. Hallyn" <serge@xxxxxxxxxx> writes:
> Quoting Nathan Lynch (ntl@xxxxxxxxx):
>> "Serge E. Hallyn" <serue@xxxxxxxxxx> writes:
>> > + cnt = ref->users + 1;
>> > + switch (ref->type) {
>> > + case CR_OBJ_UTSNS:
>> > + utsns = ref->ptr;
>> > + cnt2 = (unsigned long) atomic_read(&utsns->kref.refcount);
>> > + if (cnt != cnt2) {
>> > + cr_debug("uts namespace leak\n");
>>
>> I'm struggling to understand what guarantee a check such as this is
>> supposed to be making. I see that it will catch *some* undesirable
>> cases. But "current refcount equals old refcount" does not imply that
>> "refcount has not changed in the meantime".
>
> It's got nothing to do with the refcounts changing.
>
> It ensures that, at the end of the checkpoint, the resources (utsns
> in this case) had no users not accounted for by a checkpointed task.
> In other words, there was no information leak.
Okay, I had mistakenly believed this code was running in the
subtree/non-container case. I reread your patch description and it
indicates that these checks are made only in the case of container
checkpoint. If I'm (finally) understanding the patch correctly, my
concern is lessened. Comparing refcounts is still... unconventional.
> Now it's possible that at the *start* of the checkpoint there was
> another task, not being checkpointed and not frozen, in the utsns,
> and it exited before the leaks check took place.
[Please excuse the obtuse queries below]
In which case the check would fail, yes? Can this scenario actually
occur? I'm of the understanding that a container must be frozen before
proceeding with checkpoint. If that's correct, how could a task in the
container exit in the meantime?
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
